SAST and Tester as business analyst
I was at a SAST Öresund meeting last thursday. It was time again to hear a little more about the knowledge of agile within the testing community in the south of Sweden. I am sorry to say that other times I have gotten somewhat disappointed, but this time I felt that people are actually starting to get it.
The first presentation, I am not going to say so much about. It was about using Scrum in an outsourced test project. The number of questions that were thrown at the end of the session showed that there was a big number of uncertainty and inconsistency for the presentation to gain acceptance in the audience of testers. It also proves my point on the agile maturity at SAST. In my point, and probably more with me when thinking of all the questions, I am not so sure the project was very agile at all actually with its surrounding managemental and additional processes used to achieve the goals for the poor Scrum team.
Then there was Thomas Stjern from Inceptive, that presented the view on requirements management in the agile context. When listening to Thomas, it struck me that he was almost exactly describing some things that are in the book that I am reading at the moment, Bridging the communication gap by Gojko Adzic, about having User stories on a really high level. Then they become business rules for development and then Fitness tables for acceptance testing during development. I will cover more on this in future posts.
What was more exciting for me about the presentation, was the view of the roles of the requirements/business analyst and the tester. As Thomas referred to scrum teams of size 4-6 people, the role of business analyst and tester could obviously and preferably be the same person. By doing that, you will never have knowledge/information drop when creating tests from requirements. Going back to Gojkos book, it makes even more sense to do this, as he talks about the requirements written as acceptance tests in the first place.
In some projects I have been in, the business analyst tasks have been carried out by the product owner or scrum master person. This has always created a gap in knowledge about the domain and the customers true wishes between this person and me as a tester. In my current project though, I have actually grown the amount of trust from my project stakeholders, that I was a part of the requirements discussions before any of the features in a the new release were started to be developed. Compared to the other projects I have been involved in at the same client, I have always gotten involved sometime during development before a release. As this is my 6th product release of a product here, I have every time gotten closer and closer to the initial meeting of the release. Now I have caught up and I see this as a big difference to the first release I had. This time, I have the overall understanding of the design and am able to focus more on the actual testing and quality of the developed product, during development. In contrast to when I need to gather fragments of old discussions together and then analyse what is actually wanted from the product by the customer, and do this maybe after everything has been developed.
Somehow, this also relates to my post on Dare (not) putting your product in a testers hands?. Will you invite your tester to the next design/requirements/scope workshop or meeting? I can assure you that a good tester in that position will find the bugs in the discussions. See my post on that here
Leave a Reply
Speaker at Lets Test Oz 2014
Speaker at CAST 2012
Speaker at Agile 2012
Speaker at Agile Testing Days 2012
Program committee member at Öredev
Happytesting 
Sigge – some interesting thoughts in your post. I completely agree with the point of having testers involved in the product right from spec review and having them find issues from the start to prevent bugs coming up later. We do that as a rule at Microsoft.
However, asking the tester and BA to double up and justifying it saying “knowledge wont be lost” is not very convincing. Just extrapolate that a bit. Having the dev and BA double up will ensure no wrong scenarios get implemented. Having one person do the whole thing or rotating roles will probably achieve similar results.
I agree that on small teams, there may not be a need for a whole BA role. I also agree that BAs writing acceptance tests make sense. But that’s not all the tester does. Other than acceptance tests, testers do a whole lot of other testing while exploring the app. I would strongly recommend that either a dedicated tester remains on the team or devs double up as testers based on phase as long as they are not the ones testing their own code. Is that fair? 🙂
Hi Anu,
I am sorry for the assumptions that I am doing, that I might not have written about. Just as Thomas in his presentation, I am assuming agile teams of size 4-6 people including a person that is dedicated to see to that quality software is delivered. I usually refer to this person as a tester. I also assume this person to be allocated to the project at day one.
Another thing, something that I have plans on writing a blog post about, is the roles vs people vs tasks thing. Most reading on this is usually based on having one person in one role doing certain tasks of this role, ie. The tester does more than write acceptance tests, etc. In smaller teams this becomes a hard thing to talk about, since there are not enough people to fill every role, and some people are better than other doing certain tasks of a role that is not the appointed etc. This is why I really want to talk about tasks of roles, testing tasks, BA tasks, PM tasks and realise the vision of a successful software project. All projects have their different type of tasks that are needed for the project to be successful. What is really unimportant in this, is which person that executes which tasks. What is important is that the tasks are executed at the right time by the right person at that time.
This reasoning is something that I refer to when talking about the two scrum roles scrum master and product owner, and what problems this setting gives. Another example that goes in my reference to that is this blog post by Michael Feathers.
The tasks are divided in the best way possible between people, regarding to their contexts and which person that is best suited for it.
And this is actually what I mean by talking about the tester as BA. In the start of the project, the tester has to “prepare” for the testing that is done at later stages, and this could very well be writing acceptance tests and attend meetings as a BA. When in the end of development, tester might need to take on team coaching tasks like a scrum master role if facing a sprint of acceptance testing.
I think I am going to refine the tasks vs roles vs people thing in a blog post soon. If you have any questions on it as I described it please let me know. But do you see where I am getting? When I describe the tester doing BA tasks, and that this makes the communication gap disappear, if you compare to if the product owner or scrum master handle the BA tasks as I refer to in my other projects.