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.
Last weekend (5-6/07/13) I attended KSWT3, the third Kiwi Workshop in Software Testing. It was an amazing experience to have 19 talented and passionate testers CONFerring together. There were so many take aways from those two action packed days, I have material to write a few blogs (and I will). Somehow the Dice Game takeaways were at the forefront of my mind, so my first KSWT3 blog post will be about that.
This was my first time playing the Dice game. I had heard about it many times, so I was really glad when it was announced that after lunch we would have a chance to play it. Richard Robinson was the facilitator and I had two team mates sharing this momentous occasion with me: Jennifer Hurrell and Erin Donnell.
Games, puzzles and challenges are a staple in any good software testing conference, especially peer-conferences such as KWST. Maybe because it is such a great way to practice critical thinking skills, lateral thinking and (especially for me in this case) to get us out of our comfort zone – all very relevant testing skills.
I will not go into the detail about what the game is or how to play it, because if you are reading this blog chances are you are a tester, and if so you either know the dice game or, in the case you don’t, you should find someone that can play it with you. I’m not going to spoil the fun!
What I AM going talk about are the three life skills I learned from playing it, which relates to other games and challenges also. Overall, I learned much more than just to play the Dice Game during that session. I learned the power of harnessed frustration, the hinderance of perfectionism and the benefit of team work.
The Power of Harnessed Frustration
I can’t deny, the Dice Game frustrated me. I sat there trying to work it out, and tho in the begining it was fun, after some time trying to figure it out I was ready to throw that pile of dice as far as I could!
Frustration is an emotion us testers know well. It is a powerful emotion and we can let all that energy go to waste or we can let it be a trigger to do something about the situation. For example, when we feel frustrated it is a great time to defocus. I found out that I can focus really well, and sometimes when I focus too much I can get tunnel vision, so I’m now consciously defocusing especially at work, but also in other situation too. Next time frustration hits, I’ll remember it as a trigger to defocus, stand back and see the bigger picture.
Anne Marie Charrett has a great post about defocussing if you want to read more.
The Hinderance of Perfectionism
I am a competitive perfectionist, which at times can be a good thing, but sometimes it can also be a hindrance. In this case it was a hindrance because I wanted to crack the game, I wanted to beat it, I didn’t want to fail, and that added to the frustration. Soon this became a cycle, the more I wanted to crack the game the more frustrated I became, which made me want to crack the game more, which made me more frustrated… Well you get the picture.
Perfectionists know that tho it is often a good thing to want things done well, to want to excel in what you do, however we must also remember that to try to achieve perfection in any project (especially in testing) is not an achievable goal. A more achievable goal is to strive to be a skilled and professional tester instead, one who is always learning and becoming better.
The Benefit of Team Work
I had the benefit (and pleasure) to play the dice game in a team of three. We decided in the beginning that we were going to play together, instead of against each other. Hence we were ‘thinking out loud’ throughout the game and as we took turns rolling the dice we also explained why we were doing what we were doing.
I found that playing it in a team setting certainly made it more fun, and I have no doubt that we found the answer within 30 minutes only because we were sharing our thoughts and feeding off each other’s ideas. It was a true example of when 2+2=5.
That is also true in testing. I find that testing in a team where we are openly sharing ideas, collaborating and using team work doesn’t only make testing more fun, but it is also much more productive as we leverage of each other’s strengths. As Kaner and Bach stated in Testing in Pairs:
“Based on our (and others’) observations of effective testing workgroups at several companies. We noticed several instances of high productivity, high creativity work that involved testers grouping together to analyze a product or to scheme through a test or to run a series of tests. We also saw/used it as an effective training technique”
I am definitely adding more pair testing to my daily testing routine, be it testing with another tester or even pairing with a developer, creativity and ideas can flow more freely when we join together with other brilliant minds!
So all in all it was a great experience to play the dice game. I learned life skills that I have been using since and am looking forward to keep using them and getting better at them also.