When I got a comment on my last post, I realised that I had to make myself more clear on some assumptions. Some of them were made on things that I have been thinking about lately, but not discussed with very many people. And I havent blogged about it.
In any project, there are things you need to get done for the project to succeed. In software projects in particular, my view on success is when the software developed brings value to someone of importance. Projects have a budget, usually in money, time or labour of some sort. These have to be distributed among people/equipment to achieve a set of tasks until value is brought by the system.
Software development is a huge domain with lots and lots of different people that are concerned by the software that is developed. We usually call them stakeholders, direct or indirect stakekholders. Indirect stakeholders is pretty much any person on the planet since we are living in our small ecosystem called earth. In software projects we usually only refer to the closest indirect stakeholders and the direct ones. All stakeholders usually have roles within or around the software project.
Human beings need to have labels/folders in our brain to function in a normal way. Otherwise we would be overwhelmed by information if for example every person we meet required its own folder since we are unique. In software development we have a whole lot of roles. Usually everyone can envision people with specific roles doing certain things within a project. Some examples of roles would be (in no special order):
Programmer, Usability expert, Line manager, Architect, Tester, Third party vendor, Configuration manager, Project manager, Scrum master, QA, Customer, Product owner, Business analyst, Test manager, Developer, Requirements analyst, End-user, Designer, Test automation expert, DBA, HR, Project funder
As you can see, from the top of my head I got a good amount of software development roles that are involved in or surrounding projects. I also assume that no project have all of these roles defined.
What is really important in a project is the tasks that need to be done for the software to deliver value. There are many ways to organize, visualize and manage task flow in a project. Usually certain roles or people are tied or expected to do to certain types of tasks. But in the agile context, anyone within a team should be able to do any task. That includes all types of people that are on the team. But is this the best thing to do? Should a usability expert write database queries? The product owner develops the back-end API? The tester helps the customer to write down user stories or acceptance tests?
Which tasks are included in a role definition?
Context, context, context! Of course the tasks that need to be done for a software system to start delivering value varies for every project. The people included in a team also vary, which means that knowledge and skills are different in all contexts as well.
The tester role
When I talk about the tester role in a project team, I usually refer to a person that fulfills and executes the tasks needed to achieve quality of delivered software. Those tasks are usually a good blend of tasks associated with QA, test automation, BA, testing, configuration management etc. But what tasks are expected from a tester like that? That question needs a context.
This is my question to you, please take this one as a challenge!
The project is a member and event registration system with backend, customised member browsing that relies on login privilegies, data uploading, invoicing interfaces towards economy system, customisable registration forms that deliver data separately towards the main system, email template creation and sending etc. You got the point.
Project team consists of 6 people for 20 weeks, in 2 week iterations. One of these is a dedicated tester. The customer is an organisation that has regular members and every now and then organises these events. There is a dedicated person within this organisation that is responsible for this project investment.
What should a developer in this project expect from the tester?
What do you think a developer usually expects from the tester?
What kind of skills are required by the tester?
What kind of tasks will the tester do? Start/mid/end of the project?
As a somewhat inspiration to your answers, take a look at this post by Michael Alexander, where he brings up what testers should be good at, but how should the skill set be used in this project?
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