The Technical QA test
In many interviews for development roles in IT, it is popular to give a example coding test.
Being in QA, and going for interviews to do with QA automation, I’ve had to have a few technical tests that have involved either writing some pseudo code examples on a white board or actually going away and complete a coding test. But not very often have I been given a actual test during interviews for a Manual Tester role.
A lot of times in software development this will happen; a tester is given some part of an application and there are barely any requirements. How would you go about testing this?
I interviewed once for a startup. There were already a few testers working there and they needed a few more. During the interview, the Test Lead asked many questions about things that I had never experienced in QA interviews. It involved a few qualitative responses about finding bugs and testing and my responses revealed a lot of subtle and not so subtle aspects of my testing ability.
Then came the technical test. The Test Lead slid across a sheet of paper with a Windows XP dialog box on it. I was told that a lot of times in software development this will happen; a tester is given some part of an application and there are barely any requirements. How would you go about testing this? The fact that it is Windows XP does not matter, but what does is the fact that it contained around 10 or more bugs. These bugs ranged from simple alignment errors to spelling mistakes to subtle changes in the UI that could be potential bugs. The aim was to walk the interviewers through my method for testing this dialog box and not necessarily find all the bugs. As soon as I saw this test, I couldn’t contain my joy. This was going to be so much fun. I immediately started talking about any issue that I noticed on the page; highlighting the alignment, clicking boxes, changing file types, saving in different folders. I picked up spelling mistakes and more subtle details. Eventually, I had gotten nearly every bug on the page and given a thorough walk-through of what should be tested and what probably isn’t necessary.
A few weeks later after successfully getting the job, I was talking to some team mates who had undergone this test too — they had all done really well. We all had a lot of praise for this test. Ultimately this became one of the best test teams that I had worked in.
From the responses of the candidate, it is possible to see how much passion and understanding, they have for testing, their approach and their ability to articulate an issue.
Fast forward 6 years, I now work with another QA that I met at this startup, and he is leading a different project at the same company. One day he was in the position of conducting interviews for a new team member, and he suggested that to use the test. This was a fantastic idea I said. This was the first time I had actually used the test in interviews and it was a great addition to my growing interview technique. He then went one step further and created another a more modern version of the test — an iOS UI that was full of bugs. He did a really good job and there were lots of subtle and not so subtle bugs in the test. He actually developed a good interview routine — augmented by a few of my unconventional questions. It flows really well I think and nearly all of it is extremely relevant to finding out if someone has the right mindset to become a tester, rather than just finding out if the candidate memorise what EP and BVA is or when best to perform UAT or the ideal workflow of a defect management system.
From the responses of the candidate, it is possible to see how much passion they have for testing; finds out how much curiosity they have or if they are interested in learning more about something and so want to be able to Test in a better way; it is possible to see how focused their approach to testing is; it can test their understanding of software development; reveals if they know really why we need testing rather than just testing being an after thought; how they can explain a defect
I love this test as it is so unexpected. It is so close to being inappropriate for an interview because it just seems like a simple game but it’s got such a deeper meaning. Usually what happens is the interviewee will squirm, look uncomfortable and ask a lot of confused questions,. And that’s exactly the tow of Tester that that we don’t want.
After all, in interviews for my test team, we want a team member who knows intuitively how to test and who will naturally want to perform BVA. They’re also curious to know how changing the fields around on an ingested XML will affect the ESB that is ingesting the document. We want a tester that is always looking out for quality — one that will take 5 seconds to notice a tiny broken image amongst 30 other tiny broken images, rather than take 5 minutes. We shouldn’t have to train a fellow to take initiative for something. And this test helps to allow exactly that.
