Senior Quality Engineer Chris Smith explains why test cases are not testing:
Like many people I learnt to play an instrument as a child. I chose to learn to play the piano as that seemed to make the most sense to my 7-year-old mind. I went to lessons every week and soon was able to memorise a few pieces. However I had only learnt to play these songs, I wasn’t taught how to play the piano.
I was a student of music until I was 18. As the years went by I would write up other people’s songs. Sure, I could read a score and then turn that score into a performance, but I couldn’t sit at a piano and come up with my own masterpiece. This made me realise that while I could play piano, I was not a pianist.
When I first started out in my career in testing, I had no real idea of what testing was. It’s just breaking things right? How naive that was!
I was soon running tests cases over and over. Whilst I was running them I was taken back to when I was seven. Here I was again learning to play someone else’s song. So I started writing test cases myself based upon the acceptance criteria found in the story I would soon be testing. After about six months of doing this I realised this wasn’t adding any value to the business. All I was doing was proving the functionality we had outlined was doing as the business demanded. Again I found myself just going over and over and over the same ground again.
Agile hadn’t been introduced into my career at this point. When I moved jobs to a company that had just started to adopt the agile model, I had the revelation that although I was a tester, I had yet to do any testing.
The revelation came to me while I sat in my first 3 Amigo session. I was sitting in a room with a developer and product manager and defining the story, but as the PM started listing out the business requirements I started asking questions: “What if?” “What happens when?” “Where does this fit within..?”
It was at this point I thought to myself ‘I’m testing! This is testing!’.
What I took out of that meeting was that I could apply these questions to how I test going forward. I would mind map out each story that was coming up in the sprint and then break down the story into journeys, always asking myself ‘What if?’, ‘What happens when?’ whilst mapping out the journeys. Here is where I found issues with the software. The issues may not have stopped a story going live to customers, but it would then raise questions on future development and planning. I was adding value to the business!
I was not only finding problems that were overlooked whilst defining the story but I was learning the software. I was able to say with confidence that something wouldn’t work or could work better. This, again, is testing.
I’m not saying that test cases are obsolete - far from it. It’s so important to absolutely nail your acceptance criteria, from here you will be able to use that acceptance criteria as your acceptance test. The acceptance test should be nothing more than a confirmation check that the functionality works.
After a fantastic couple of years, the company had to close due to a shrinking market. Instead of being afraid that I was about to be out of work I was excited to interview, excited to share my journey with other testers as I had worked as a lone tester in my previous two jobs.
The first interview came along. It was with a huge company with a large test team. During the interview the test manager introduced the practical part of the interview. He gave me a piece of paper with some details about a fake product and asked that I write a test plan and test cases in 30 minutes. I quickly started to map my way through the functionality of the product, raising questions against parts I wasn’t sure about. Thirty minutes passed and in came the test manager, he looked at my work and said: “What is this? I wanted a detailed test plan with test cases, this is a lot of rubbish.”
This is how the next six interviews went. Of course, after this amount of knock-backs I decided to just go back to basics and say what people wanted to hear. So I was back to playing someone else’s song again… until one day my manager left. I was able to slowly start to remove the running of test cases and going back to testing. Both the developers and tech leads were able to follow a mind map much easier than walls and walls of text.
Working at BGL has given me the chance to put this into practice within a large organisation. Having not worked in a large company for over a decade, I was a little unsure as to how I would be able to push the narrative that test cases are not tests, but being part of a community of testers (quality engineers) has been a revelation!
The community here has a huge range of experience from seasoned veterans to those starting out in their testing careers, all with their own takes on the craft of testing. Not only have I taken on some ways of working from them, but I have been able to give some confidence in others to move away from heavily scripting their test approach.
It’s not easy to move away from something you’ve spent years doing, however the community here has been incredible and responded fantastically to try new ways of testing. It’s not just the quality community that have responded well but the the department in general. Everyone here wants to deliver great quality and to do that they are trusting the ways the quality engineers are pushing testing. Where as before I have had to fight to get my views across, at BGL I am given the freedom to perform my testing as though I am performing my own piece of music.
For me starting a mind map, is like sitting at a piano with a blank sheet of paper. It’s now up to you to write your own music and then perform your testing like a pianist performing to an audience!
Originally published at https://medium.com.
