Me developer, you tester

“The ratio of We’s to I’s is the best indicator of the development of a team.” (Lewis B. Ergen)

According to the Scrum Guide (see http://www.scrumguides.org/docs/scrumguide/v2016/2016-Scrum-Guide-US.pdf) all members of a Scrum Team are Developers:

  • Scrum recognizes no titles for Development Team members other than Developer, regardless of the work being performed by the person; there are no exceptions to this rule;
  • ...
  • Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole.

However, in reality, we come across teams which are split in two: developers and testers. Although it is completely valid to have people with different skills in a Scrum team, this sometimes leads to two separate teams in one team: with the “more important” developers, doing the actual work, and the “lowly” testers just tagging along. Developers often consider testing as inferior work and testers tend to support this view by acting humble because of not having the “magic” knowledge of a software developer.

This might have worked in the old waterfall days, where a tester just got a piece of finished software at the end of the project, accompanied by a book of requirement specifications, and had to figure out how the ideas of some genius developer’s mind and those requirements were connected. (And as we all know, this didn’t work back then either.)

So today, in the bright and shiny agile world everything is about teamwork and one team transforming requirements into working software. That’s the theory. But sometimes I wonder…

Planning II

I just recently heard, “It doesn’t make sense that the testers attend the Planning Meeting II. How can they provide valuable input to the technical implementation of a story? They do not have the expertise….”

Let’s just think for a minute about this statement. What skills are expected from a good test engineer nowadays? Of course, she should be tech-savvy, able to query the database with SQL statements and know at least one script language to automate some testing tasks. And above all, she is an expert in designing test cases and knows all the different kinds of test approaches. On the other hand, the developer has the knowledge about all the tricks and subtleties of the Java libraries, but nevertheless should have heard about test frameworks and unit tests.

The combination of both roles and skills is the perfect match. They complement each other in combining different aspects of the product development: How do I implement this feature? How do I test it? To consider automatic testing before starting with the implementation might have impacts on the architecture and design of the code. It will result in a more maintainable solution and will support the team in keeping the quality high because test automation is neither ignored nor postponed. In addition, the team will not only design the technical solution, but should also agree in Planning II on how to test the User Story and what kind of tests (unit tests and/or integration tests, for example) will be needed to verify all acceptance criteria of the story and to ensure the quality of the implementation.

Estimation

This week’s refinement meeting, the product owner explains the story on how to integrate a new card reader into the existing product. The developers are already deep into technical discussions, the two test engineers listen respectfully until the issue seems to be settled between the devs. When everybody shows his poker card the testers seem a little bit hesitant - their estimation turns out to be twice as high as the ones of the developers. Frowns on the development side, the testers are almost ready to withdraw their estimation and go with the lower one.

Now the Scrum Master steps in and asks one of the testers to explain the higher estimation. His answer reveals that the currently defined workflow for using the new card reader would expose several possibilities for misusing it - which should all be tested. A lively discussion follows, involving the whole team, on how to change the workflow to prevent this. After about 15 minutes the story is completely rewritten as a joint team effort resulting in a much lower estimate and a solution which is easier to implement and to maintain.

Was the input of the test engineers more valuable? Of course not. The benefit results from pooling the different views, experiences and backgrounds of all team members and hear everyone’s opinion. Testers often have a foot in each world, knowing the technical domain and understanding the customer viewpoint as well, whereas developers might focus more on technical feasibility and maintainability.

During the sprint

Sometimes one can observe a mini waterfall during a sprint: at sprint start the developers begin coding while the testers still finish tests from the last sprint, waiting until the first user story is ready for testing. And then, of course, a few days before the end of the sprint, testers are all busy and developers complain about running out of work.

If the whole team is accountable for delivering a working product at the end of a sprint, why not support the testers in running some of the still missing tests? Or even better: provide technical expertise to get those automated integration tests finally out of the door and make everyone’s life easier.

“I am a developer, not a tester.” In my opinion, this excuse often results from a hidden “fear” to get stuck with the low-grade work of testing. The important thing here is to convey the message to the team that testing is a central component of agile software development and “good” testing also requires sophistication and expertise to be efficient and useful. Therefore, each agile team should make sure to have someone with good testing skills in their rows and the goal should be to learn from this person so that everybody in the team is able to take over testing tasks when necessary.

Everybody is involved

Everybody involved in delivering software is a developer. This includes also team members doing mostly “test work”. In a truly cross-functional team this separation should become smaller over time because the members of the team learn from each other, share and swap tasks and focus on the common goal to transform requirements into working software - as a team of developers.

17 Mar

Team Objectbay skiing days

By Camilla Franek

Bright blue skies, snow-capped peaks and perfectly groomed slopes. The best conditions to start in our Team Objectbay skiing days.

16 Feb

What about quality? - Part II

By Susanne Albinger

It’s easy to talk about quality awareness and collective responsibility of the team. But often it’s a collection of small things and practices that add up to enable a team to deliver high quality.


Latest Articles

  • Focus your improvements

    Sep 21 / Arjan de Jong

    Anyone who has worked in an Agile team, knows that at some point, almost every team will grind to a halt due to external reasons. Because agility focuses on short delivery cycles, any existing problems will show themselves fairly fast ...

  • Dysfunction of A Team - 5

    Aug 17 / Alessandro Grimaldi

    The ultimate dysfunction of a team is the tendency of members to care about something else than the collective goals of the group. Team members value their personal merit over the joint success of the team ...

  • The glue that holds it all together

    Apr 24 / Susanne Albinger

    Put six people in a room, provide them with post-its, a team board and a common goal and - voilá - here comes your Scrum team! High performing, creative and innovative, delivering a shippable product increment every two weeks. Sounds easy. But…

  • Team Objectbay skiing days

    Mar 17 / Camilla Franek

    Bright blue skies, snow-capped peaks and perfectly groomed slopes. The best conditions to start in our Team Objectbay skiing days.