Link to QAshido – The path of the tester. Virtue #4: Personal management skills.
We might claim with a good certainty that attention to detail is pure QA skill. It is what defines us as professionals and it is probably that testing buzzword you will see in almost every job application you open.
So what’s attention to detail?
Well for some this might be the most annoying job at all, it includes a lot of arguing, a lot of research, a lot of repetition over and over on products specs and documentation, technology descriptions in order to get into the area you are researching and be able to analyze it and give your verdict on it.
Attention to detail is the skill which best describes that critical mindset that the perfect tester should have in order to be successful.
Which detail? What’s a detail anyway?
Well, I know such answer might seem kind of mind bending, but … anything is a detail. And that’s our job, to consider anything is a detail that is important for the overall quality of the product. Nothing is minor and of low importance until the whole team agrees with the project manager and the stakeholders that it is for sure of low importance. Here’s an example: I’ve once worked with a developer who was very passionate about creating an application from scratch, end to end. But doing this, he seemed to to neglect the user interface by just using default settings, not really paying attention on sequence of elements or how visible or reachable they are. He had his reasons to do that, but I had mine to fight against it. After all, UI is what users/clients use to approve if our application is “good to use”. It’s a whole lotta topic about usability and usability testing and I don’t want to dive into it now, but it’s important to show good looking and usable interfaces to our clients. Nobody gives a fuck about your logic if your application is practically unusable, or simply pain in the ass.
And having that said, I am not trying to imply that attention to detail is dealing with UI. Hell no! I hate arguments about UI. That was just a classic example of where attention to detail might be useful.
Start from the beginning.
With this post I really want to state that attention to detail isn’t simply something to be applied in the most literal way, looking at something and being picky about it. No! Attention to detail may be applied at much higher levels whan we are speaking about software development life cycle.
Let’s say we are new to a project. We are given time to read documentation, we are given some senior/team lead QA to bother to death in order to figure out “What the fuck am I supposed to do now?” :). So, what are our next steps? Some should say – go ahead and play with the product, run some tests, learn how it works … yada yada, no.
I very much enjoyed an interview in a podcast I am listening, called “Testing in the pub” and it was about hiring QAs. What really impressed me was a story of how easy it is to spot a good tester for mobile application by just bringing a mobile device to the interview, give some simple tasks and review the workflow that the interviewed person will follow. In many cases he or she would start to play with the application and try to find the issue or task you’ve given to him/her, but you know and I know, that testing isn’t just connecting the dots in the correct sequence. It’s about being able to see the bigger picture.
Experienced QA would know that before starting to do anything at all, it will be much more important to understand the details about the client, such as:
- business area
- current and eventual clients
- plans to scale (this is crucial for performance testing)
- level of technical understanding
An on, and on… You see that thinking about details is not just looking for simple defects in the UI, it might be deep and profound matter and many professionals in IT might decide to skip it, just because they decided this is not part of their responsibilities.
Asking questions which nobody dares/cares to ask.
Attention to detail might be thought in a more abstract way, not just by performing actions A, B, C and D, but by having specific behaviour in some situations. I always like to defend the position that a good tester should not trust the output from test cases and exploratory testing, but instead to push the system he/she is testing to the extreme. Believe me, the most ridiculous bugs I’ve ever caught were off the test cases written previously. And they were simply a product of my natural curiosity and my “what if I..” mindset.
And this has to do a lot with design, too. I don’t know why many devs tend to think that QAs are non-technical specialists or some non-intelligent form of life, but I always push fellow QAs and juniors I speak to , to ask about anything including design and implementation. Because if a developer can’t explain the logic of the application he wrote, then he probably messed up something or made it unintentionally overcomplicated.
Testing is not about trying to break an application or follow certain design notes, test scenarios or whatever it is. Testing is about craftsmanship – about picking all small details and make them perfect. That’s the QA way to do it, and as it seems it’s the only right way to do it.
Have any thoughts or objections on this. I would like to read it. 🙂