Mnemonics and Heuristics

“A heuristic, is any approach to problem solving, learning, or discovery that employs a practical method not guaranteed to be optimal or perfect, but sufficient for the immediate goals.” Wikipedia

“A mnemonic device is a mind memory and/or learning aid. Mnemonics rely on associations between easy-to-remember constructs which can be related back to the data that is to be remembered.” Wikipedia.

Remember that all heuristics are fallible.

These are the mnemonics and heuristics I use the most:

RCRCRC

Regression Testing Heuristics by Karen N. Johnson
Recent, Core, Risk, Configuration, Repaired, Chronic

SFDIPOT (San Francisco Depot)

Test Strategy Heuristics by James Bach and Michael Bolton
Structure, Function, Data, Integrations, Platform, Operations, Time

CRUSSPIC STMPL Quality Characteristics Heuristics by James Bach

Capability, Reliability, Usability, Security, Scalability, Performance, Installability, Compatibility, Supportability, Testability, Maintainability, Portability, Localizability

A variation to these heuristics can be found here. I like the added Charisma-heuristic http://thetesteye.com/blog/2010/11/software-quality-characteristics-1-0/

FEW HICCUPS

Test Oracles by Michael Bolton

Familiarity, Explainability, World,  History, Image, Comparable Product, Claims, User Expectations, Product, Purpose, Standards and Statutes,

RIMGEA

Bug Advocacy Mnemonic by Cem Kaner

Replicate it, Isolate it, Maximize it, Generalize it, Externalize it, And Say it Clearly and Dispassionately

MOCHA

For asking questions in e.g an interview – by Maria Kedemo

Meta, Open, Closed, Hypothetical, Audit

 

 

Here are some more which you might find useful

 

The Speak Easy program, Part 1: Becoming a mentor

Speaking easy, really?

Speaking in larger groups or in front of people has never been easy for me. My heart starts pounding every time I’m in front of people. Some times I have to look down at my chest, certain you can see my heart pounding through my t-shirt, like in a cartoon.

I used to hate speaking in front of people. If I could avoid it I would happily do so. Ironically I’ve chosen a career where I need to speak in front of people; in project meetings, to my team and in all sorts of context at work. It is also quite funny that my new job will be teaching software testing in a vocational program. To hate is a very strong word and a very serious matter. I don’t hate speaking anymore. I don’t love it either. Yet I choose to do it! (I will get back to why I do it and when I actually felt comfortable in a new post)

In my career I have done very few official speaking events, such as speaking at conferences and meetups. Though the ones I’ve done have been a real challenge and a great experience.  Now a days the biggest reason for speaking very occasionally is the time it takes for me to prepare ( I will get back to this part too).

My reasons for becoming a mentor

Given the background it might seem strange that I volunteered to become a mentor for Speak Easy. But the program which Fiona Charles and Anne-Marie Charrett have started is something I am very passionate about and the main reasons for me are:

  • The possibility to influence bringing diversity to the arena, specifically tech conferences.
  • The possibility to support speakers or new speakers who might share my experiences.
  • The opportunity to give something back to the CDT community and people who have supported me and helped me throughout my career.

I will go deeper in to some of the reasons in a few upcoming posts.

Kudos to Eric Proegler for the idea of creating a series of posts!

This is the first of a few post in a series related to being a mentor for the Speak Easy program.

Let’s Test is on!

Rambling from an Introvert’s aspect of the conference

Well officially Let’s Test doesn’t start until tomorrow, Monday.
But informally the conference has already started and I am having a blast!

Reflecting

I am an introvert but I love conferring. So as an introvert I have now headed back to my small, but beautiful room with a fantastic view over the lake to do some reflecting.

One thing I have realized is how easy it is to for me to get caught up in all the discussions and wanting to meet new people and talk to people I’ve only “met” on Twitter. The thing is I really want to just suck in all of the things going on  but a lesson I made from conferences where conferring is the goal is that I need to listen to myself, take a beak, reflect and regather some energy. Normally I just tend to drift along with the flow.

This time I am trying something new. I will try without too much of structure to actually write down my reflections as the conference goes on.

Arrival

I arrived yesterday, Saturday to be able to mentally prepare for my session on Tuesday. I instantly met up with some dear old friends Louise, Carsten and Henrik with whom I shared a cab. That is when the conference actually started!

During the evening we were about 20 people, including Johan Jonassons little newborn Ingrid. The discussions were somewhat let’s say pending from very low to let’s say more intellectually stimulating subjects in the bar with the Eurovision song contest in the background. I had a great time but forced myself to hit the bed around midnight which I today think was a wise thing to do even though I wanted to stay up longer to chat with all the great people.

Sunday

So after breakfast it was time for facilitating training. The training was held by Ilari Aegerter and his Master Paul Holland (part of the Let’s Test Team). This is the second time I signed up for it and it is a very good thing to do to when it comes to learning how to facilitate a discussion. I was at one time regretting that I did sign up, since I came up early to mentally get prepared (but then I got this awesome Let’s Test jacket to wear when I’m facilitating, so it is totally worth it now ;)). The training was well performed and fun and then we actually got to practice real facilitating in the peer conference Lets Wet that was organized by Simon Morley and Jean Paul Varwijk.
It was great getting direct and constructive feedback on my facilitating. And to me it is not only about learning but also to challenge myself in areas I’m not very comfortable in. I got very good feedback.  These are the three main things I will take with me when facilitating.

1. Recap from the stack, so that the participants knows who’s on next and that I as a facilitator have noticed them
2. Scan the room, notice the participants when they want to talk
3. Find a good structure to keep track on your threads.

I am writing this in the context of me assuming that the reader is familiar with the concept of a peer conferences and facilitating. If you don’t know read Paul Hollands blog.

Now I’m going to rest for a while and get some energy and then head back to the conference again!

DSC_1401 DSC_1405 DSC_1406

I reclaimed the software testing flag!

A week ago one of the testers working for me sent me an invitation to connect on LinkedIn. After having accepted the invitation I had a look on the testers profile. I had an immediate reaction of horror when I saw the title the tester had come up with for the position followed by the name of our company; “Quality Assurance Tester at Made up Company”.
Oh no! I thought to myself. Now people will think we work in Quality Assurance. This is NOT a domain I want to be related to!

I immediately contacted the tester through IM:
Me: It’s great that you are testing Quality Assurance. It needs to be questioned. 🙂
Tester: Not sure what you mean…
Me: I’m referring to your title on LinkedIn
Tester: Yeah, that’s what I thought, but is it a good thing or not…?
Me: Well we don’t do Quality Assurance even though that is the name of our team. There is an old story behind that name. You are a software tester, and that is something you can be proud of. I’ll tell you the story later.
Tester: Ok, I understand. I’ll change my profile.

I am still a bit concerned that the tester did not really understand why…but that is another story.

The story behind the name
Before I started working with this compan  the developers did testing by putting on their testing hat every third month to do “testing” for two weeks. As a tester I continued doing testing. Our users were also doing testing and so were our business analysts. Testing as a word became very misused and was used for simple exploring and demonstrations and for checking. The word was used for various activities which I did not consider SW testing and the meaning of the word got sort of worn out. I wanted the word testing to be associated with a craftsmanship and not something anyone could do (Henrik Andersson wrote a great article on a similar topic: Don’t hustle my flag).

Even though we as testers made a difference it was difficult to gain credibility for what we did just due to the word testing. Before we showed up, testing was already something developers were doing. Testing was seen as something everyone could do and by wearing out the word/name it didn’t really have the meaning I wanted it to have.

So I decided to change our name to Software Quality Assurance from the most weird name ITS (which I have no memory of what it stands for) to make it sound more fancy to others. The name to me was not really important as long as my testers and I were left to do what we are good at, software testing. If you give something a fancy name, what others think is a fancy name, they might also think we did something that differed from what had been done before. I made the assumption that Software Quality Assurance was perceived as more serious than Software Testing by our stakeholders.

Back to reclaiming the software testing flag
For quite some time I’ve been wanting to change the name of our department since Software Testing has been established as well as the profession SW tester. I want us to be proud of what we do and that should be shown in the name of our team/department. But it took me more than a year from when I thought it was time to change the name until I actually did it.

Last Friday I had the opportunity to meet up with Michael Bolton, Henrik Andersson and Lars for a beer or two or three and some great discussions. Somewhere in between beer one and two I mentioned the episode with the tester and the title in LinkedIn. Michael immediately questioned my choice of name. I told the story and he said something like:
“If you name it Software Quality Assurance that is what people think you do!”  It was then so obvious to me, of course this is what people think we do especially people not knowing me or my testers or how we actually do software testing.
I realize that naming the team as I did was a bad move. I should not have hidden behind a “fancy name”. I should have worked more in proving our credibility and showing why our testing is different from a demo or checking by users or developers. I’ve actually assumed that people understand what we are doing as software testers and that is something I need to get better at explaining no matter what the name of what we are doing is.

On Monday morning when I came back to work I cleared out all administrative obstacles for changing the name of the department. Our department/team name is now Software Testing Team.

I have finally reclaimed the software testing flag!