Tagged: Context Driven Testing

QA: The Misnomer That Never Dies

Quality AssuranceOver the span of my testing career I don’t know how many times I’ve had this conversation, in its many forms and permutations. The good old conversation about testing vs. quality assurance. The conversation we (software testers) have about not being ‘quality assurance’ professionals. That we cannot assure anything, least of all quality. Testers can assure quality as much as a doctor can assure health. Imagine the conversation:

[Patient] So doc, now that I’ve done my yearly checkup, can you guarantee I am entirely healthy?
[Doctor] Well, you are healthy, and we checked for all of the most common sicknesses and diseases for someone your age, gender, background. However I cannot guarantee there is nothing else wrong somewhere we didn’t check.
[Patient] But you said you were doing a thorough checkup.
[Doctor] And I did.

You get the idea. The doctor takes what we testers may call a ‘risk-based’ approach to our yearly checkups. He takes into account our family history, background, gender, age, habits and makes a decision on which exams we need, as he couldn’t possibly ask us to do all the available medical exams out there. That could be seen as a waste of time and money.

The same goes for testing. Only that the conversation happens between the Software Tester and the Project Manager, or the Product Owner, or the Dev Lead, or whomever else. I believe that one reason that this still happens is because some testers still insist in calling themselves ‘Quality Assurance’ professionals. How can we possibly not assure quality if that is precisely what our job titles say? I’ve had this conversation countless times with ‘QA’ people everywhere. There is a feeling that being called a ‘tester’ is demeaning, or less important than a QA. A Quality Assurance Engineer once told me ‘but I do so much more than just test’. That may be true, but you still do NOT ensure quality. You just can’t. This is not a new topic, Michael Bolton wrote his popular blog post Testers Get Out of the Quality Assurance Business* over 5 years ago, and it was not a new topic then.

The fact that we, as a community, are still talking about this has to mean something. I’m not sure what yet, but it has to. It could mean that we are talking about this to the same people over and over, or if we are talking to new people about it, the message must not be getting across because by now we’d have made an impact. Maybe we have made an impact, but I just don’t feel it. Confirmation bias? Maybe.

So what can we do? How can we move on to bigger and better conversations? How can we impact the still large part of our industry that believes they can, and do ensure quality? How can we kill and bury this misnomer once and for all? I wish I had the answer to that, but I don’t. I do, however have some suggestions and some things I have been trying:

Keep talking about it

We need to continue talking about the foolishness of the term Quality Assurance when referring to Software Testers. It is not only inaccurate, it is irresponsible. A physician would never call themselves a ‘Health Assurance Professional’. One dictionary definition of ‘doctor’ is a qualified practitioner of medicine. As we are qualified practitioners of software testing, investigation, reporting and communication.

Understand what software testing is [and is not]

There are still so many testers out there that are unable to articulate what they do. I interview a lot of testers, and the answers to questions such as: ‘what is testing?’ or ‘what is the most important skill a tester can have?’ or ‘what does a tester do?’ range from unsatisfactory to completely pitiful. There are a sea of free information about testing out there, read it. And I’m not talking about LinkedIn forums, don’t go there. I’m talking about blogs such as Satisfice and Developsense. Start with this post, and beware, you will need to read it more than once. Read it until you understand it, until you internalize it. Then move on to read as many other blog posts on those sites as you can.

Talk to other Software Testing professionals

When I started to really understand what testers are supposed to do, when I began learning about the craft of software testing, I was all but confused. I was told by the courses and certifications I had done that I was put in a team to assure quality. One way to better understand and clarify such doubts is by having a conversation with experienced practitioners. Do your research first, then approach one of them. They have helped me [and still do to this day] to grow in understanding of our profession, helped me to be better at articulating concepts, theories and how to practice software testing as a professional. If you don’t know how or who to reach out to, contact me.

Do you find yourself having this conversation too? How to you tackle it? Any suggestions on how to stop this madness once and for all?

*BTW, if you haven’t read this post yet, drop everything you are doing and read it. Now. 

Challenges of a Sapient Tester in a Factory Environment

I attended the Kiwi Workshop on Software Testing (#KWST3) two weekends ago. This is my second KWST3 post, and there are more to come!

My KWST3 Experience Report (ER) was about my journey from being a factory tester to becoming a sapient tester. There is another blog post coming out soon which will detail this journey, however today’s post is about some of the challenges I have encountered on the way, after becoming a thinking tester in a factory environment. I will discuss the challenges and some of the solutions that helped me.

Since becoming a sapient tester, I haven’t been so lucky yet to work for a company (or department, or manager) that fosters context-driven testing, hence I have been on a mission to try to help decision makers understand what they stand to lose if they continue on the path of factory testing. But it is not always easy, actually I won’t lie to you, it has not been easy once.

Resisting Change is Natural

Changes Ahead

When trying to implement any type of change it is important to keep in mind that people resist change, it is natural. Even talking about change can trigger reactions in people that are irrational and even unpredictable. Resistance to change is often related to fear of the unknown. Change often means people will have to get out of their comfort zones, and not everyone enjoys that. Some people just like to do things the same familiar way day-in-and-day-out. And lastly people are not aways motivated to change, mostly because they don’t believe there is anything in it for them.

Managers are often the catalysts for change, and I have found the road to implementing change from bottom up a bumpy one indeed for three main reasons:

  1. Lack of freedom to implement change, as management and/or stakeholder buy in is slow.
  2. Managers can be reluctant to implement change that comes from the bottom as they feel there is too much at stake. Arguments such as ‘if its not broken, why fix it’ are examples of such behaviours.
  3. Managers and/or stakeholders do not fully understand what we do. Hence they are not in a position to make an informed decision about changes to testing processes, which brings trepidation and insecurity, and they are again reluctant to change – bringing us back to point two and getting into a vicious cycle.

Lessons Learned

I am no expert in change, however in trying to influence to think about their testing processes and methodologies I have come across a few ways to approach people to talk about change in less threatening ways. Unfortunately I haven’t found a magic formula that works every time, and some of these have failed miserably in the past, but I’m happy to share them and you can analyse if any of them will work in your context:

Don’t Call it ‘Change’

The word ‘change’ carries so much stigma that I’ve found it best to leave it out of the conversation all together. When you approach a decision maker, try using words such as ‘ideas’, ‘improvement’, ‘revision’, etc.

Be Prepared

Think ahead of time about what questions they might ask, try to put yourself on their shoes and imagine what sorts of questions would they have? Write them down and have answers ready.

Start Small

Small changes are less threatening and therefore more palatable to most people. If you are lucky enough to have a maverick manager, by all means go for the big-bang approach, however if your decision makers are of the more conservative type start small. If the change you are proposing is massive, break it down into chunks and find what the logical fist step is and go for that one. For example suggest doing exploratory testing once a week or half a day every day. This way they’ll still have the execution rate of the scripted test cases they crave and you will have the opportunity to explore and at the same time gather important evidence you will need in future conversations.


Starting small is a compromise. Be prepared to compromise even more, it may be the only way to go. The important thing is to take steps (as small as they are) in the right direction. The only thing that is not OK is to stay stuck in the same place. Try to understand the reason behind the other person’s reluctancy. Is it time? Are they worried your testing will get delayed? Then maybe offer to try it for one week and have daily checkpoints with them.

Maybe they don’t know exactly what ET is and are worried you will not really test anything because you are not following a script and that you won’t achieve anything.  Maybe invite them to sit with you for one hour every day so you can show and explain how you do exploration. The point here is to be more then a tester, be an investigator, a psychologist, a diplomat and answer like a lawyer! Be creative, try new things and do not take no for an answer.

Gather Accurate and Systematic Evidence

Once you start exploring, ensure you do it in an organised way. Gather information such as defects and issues found and how these wouldn’t be found by following a script. Capture evidence of your explorations such mindmaps, diagrams, videos, anything you can use in the future to back up your case for exploration. A lot of the insecurity around ET relates to the lack of knowledge of what it actually is. To many, ET is synonym with unstructured, free-format testing – and it is up to us to change that mentality by presenting accurate and systematic evidence. With enough data to substantiate your ideas you should be in a better position to influence and pioneer change.

Be Patient

Remember, changing processes and mindsets takes time. Be prepared to be in it for the long run.

Find a Support System

The test community worldwide is a tight-knit group of people who are always willing to help and lend a hand. There are times when fighting the good fight alone feels too hard, however with the support and guidance of others in the community it is much easier to keep going. I felt like giving up many times, but people in my community supported me all the way.

If you would like to find out more, to discuss anything mentioned above, or if you’d like to get connected with someone in the test community email me and we can explore these ideas together.