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
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:
- Lack of freedom to implement change, as management and/or stakeholder buy in is slow.
- 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.
- 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.
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.
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.
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.
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.
2 thoughts on “Challenges of a Sapient Tester in a Factory Environment”
I have been on both sides of the fence here – as a tester pushing for the introduction of ET as part of a context driven approach, and also as a test manager of context driven exploratory testing teams.
I would add one more thing to your list, as an effective way of pushing for ET:
Focus on the problem. Whatever objections people have to ET, if they have any quality as a test manager or as a tester, once you get through their initial reaction (resistance to change / fear), you should have an opportunity to say “Yes, but what we are currently doing is failing in the following ways… We should at least consider that an alternative approach will help us to solve these problems”. As you say, much of the resistance to ET is fear based, people need to be encouraged to get past that fear, and focus on the problem that needs to be solved.