Putting the *Analyst* into Test Analyst
This content is syndicated from by Kelly Waters. To view the original post in full, click here.
For years, I've given Software Testers in my teams the official job title of Test Analyst, or something along those lines.
Yet (informally) I've always referred to them as Testers.
Only in more recent years - and especially since adopting Agile Software Development and User Stories - have I really discovered how to put the *Analyst* into Test Analyst.
I've written before about 'Why Agile Testers Should Be Involved From The Start'. It's obviously very important in agile development, and has a number of very good benefits.
With User Stories, we've gone a step further.
A Business Analyst, Product Manager, Product Owner and/or the Team should identify the relevant User Stories for the Product Backlog. From this feature list, for the selected items for the next Sprint, requirements need to be clarified and expanded on.
The requirements for each User Story should be discussed and clarified as a team. But, in my view, the Test Analyst is an ideal person to lead this discussion and write up the User Story cards.
Test Analysts tend to be very analytical in their nature. They tend to be good communicators. And, as we all know, they can think of scenarios that business people and developers never even dream of! :-)
Moreso, when it comes to writing test cases on the back of the User Story card, they are obviously the ideal person to do this. Writing these test cases up-front, when the feature is being defined, helps to improve quality from the outset, as developers are more likely to write their code to pass the tests (because they know what they are).
But also, it makes perfect sense to me, for the person that's going to test a User Story, to be the person that defined it.
Photo by p0psicle