If You’re Gonna Code in Texas…
Testing 1, 2, 3… Testing
One of the roles that should be in the Scrum guide is that of the manual tester. I know that testing within the Sprint is a ubiquitous feature of solid Scrum practices. But when I started and even to this day, the tester is often seen as an “outsider” who is going to “slow my code delivery down”.
In fact, the best-placed indicators of this are “devs can do their own testing” or “all my unit tests pass consistently, I have 100% test coverage”. And yet, we still find unit tests that test nothing. We see devs that test their own code, only to miss critical issues. And there is a general issue with quality testing of the Sprint’s content. This is where an engaged and active tester can help a team to get to the next level with their work. But only if they are accepted as part of the team.
One reason that the tester is not on the Scrum Guide is because of the definition in team. This was in one of the earliest versions of the Scrum Guide:
“The team of people performing the work of creating an Increment is the Development Team. Regardless of the work performed by individual team members, they are known as Developers.”
This sentence has led to many conversations and a little bit of conflict when forming teams. The intent for this was so that we would have a sense of equality, but in some cases within certain cultures, this resulted in the opposite. Currently, the 2017 Scrum guide states that:
“· Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;
· Scrum recognizes no titles for Development Team members, regardless of the work being performed by the person;
· Scrum recognizes no sub-teams in the Development Team, regardless of domains that need to be addressed like testing, architecture, operations, or business analysis; and,”
This does tend to line up with more modern expectations and even calls out “testing” in the wording! Yet, we still see organizations wrestling with this concept. We know that code developed by the team is best when tested during the sprint. Why then, do we still have trouble with the inclusion of Manual Testers into the Scrum Team?
The Tester “in” the Team?
When I start an assignment with a new organization, the first thing to do is to get to know the team members. I need to see what they are doing and why. The testers always have a lot to say, and a lot of observations in why the flow of work is the way it is. They are usually “holders of the knowledge” and seem to get along well with most people. But, usually, they are burned out. They feel like they are intended to be mute partners and felt left off most if not all team decisions.
I know what you are thinking — “Harry, they are RIGHT THERE!! Of course, the Testers are part of the team! Who would not know this?” But the last part — being a member of the team — is more than physical presence. Working together should mean more than “you get the story at the end, and make sure it is completed”. Many teams I work with separate stories by a developer — and the dev works on these most of the sprint. But the one (or two) testers, they must wait 7–8 days to get anything — and have two days to test the work of the remaining part of the team (3 to 5 devs). Of course, if a bug is found — it is the fault of the tester.
This does not describe a mature team. It shows a lot of built-in dysfunctions that have not been addressed. But the word “test” is now in the Scrum Guide. We physically assign a person to each team to make sure the quality is addressed. And, we have accountability, because bugs are discovered and annotated (for a later sprint, of course). Is this the right way to do this?
Now I have lost a lot of you. Many of you are thinking “this is IMPOSSIBLE — how could any company be that immature?” Unless, of course, you are a Tester. In that case, you might be thinking things like — “oh wow, that is exactly how it is!!” Or, “well, Harry — now that they eliminated my job and are only doing automation, it is a little late”. Or even — “since they do all their unit test, quality is zero. Because the devs only check the surface functions and have pushed me out of the way”.
I imagine there are places that are NOT like this. But I have yet to find one. Many places will not have all these issues — maybe one or two at best. Like testing at the end of the sprint (what else are we supposed to do?). Or, replacing manual testing completely with automation. You add the Tester into planning — but the estimates are for complexity only, so we mostly go with the dev points. If this is the case, this article may be for you.
The Tester and the Devs
One of the goals in Scrum is to have a “potentially releasable” delivery at the end of the sprint. This has led to the emphasis of the “vertical slicing” model for stories. Essentially, we are asked to code the story with as many component parts as possible. When the demo comes around, there is functionality with the delivery that is coded.
When testing in a vertical slice, things can get a little more complicated than usual. If the tester’s input was not listened to during planning, you add a large layer of risk to that story and to the sprint. This is one way to add a block to the Tester when trying to achieve “Scrum Discipline”.
A different way is to limit the Tester to “only testing”. I have seen this many times. Testers are either excluded or discouraged from participating in Refinement or Design Sessions. This can be a little more subtle, but the message is “we have Dev questions — anything else is noise”. When this happens, we miss items that can help the Developers ask a different set of questions. This can lead to misunderstandings that represent later as stoppages or missed functionality.
A while ago, I had a team that faced an unusual challenge. We were in an environment that baked in a “testing ramp” but we also wanted to be a “full” Scrum team. We had the challenge of environment access for the code once we entered the QA environment. In this case, we asked the testers what we could do to make our lives easier.
The team (with the tester at point) came up with some good ideas to do “testing in the sprint” prior to moving the code to the test ramp. Once code was merged, you could no longer develop on that until the code was regressed for you. They came up with the idea of “pre-test” and started writing test plans for the stories at the beginning. More on this later.
Testers have the uncanny ability to tell what dev wrote code by just reading it. In some cases, they can anticipate issues and can help the devs prevent those issues before they get too far. These issues have a habit of emerging at the demo, or worse, in a pushed release. When a Dev and a Tester really work together, the coding maturity can improve. And the team’s aim for quality also gets better.
In one team, the devs worked with the testers to do a “mini-demo” of their code. This allowed the tester to look at it for a while, came back and addressed the issues that could be there. For that team, the dreaded “hotfixes” improved tremendously. Instead of having to patch the patch that patched the other hole, they could have a sense of security knowing someone else had eyes on the fix. The “patches” started to disappear, as we were able to find root causes of many issues.
To boot, the demos to the PO and the Client became a much better experience. The team had lots of positive feedback and requests for more features. Simply connecting as a team between the developers and the testers can help the level of coding mature significantly.
The Tester and the PO
When the Tester and PO have a solid relationship, things clear up as well. I like to see that the tester will engage in “writing the test for the story while working with the PO”. It turns out when testers and product owners connect, sometimes the stories are clarified much better than when they do not. The Product Owner represents users and stakeholders, and the kinds of questions that testers ask usually come from the user’s point of view. This helps with the discovery and refinement process. But it also helps when the developers have questions — because now there are two people that have a shared vision.
This does not replace or preclude the Product Owner’s engagement. Rather it enhances the conversation and sometimes even bridges details during the sprint. At least in two cases, this has helped clear up (and break up) complex stories early on. It also led to cleaner delivery because the team came to a quick and clear consensus on what was needed.
Yes, we expect testers to test the code. But if you give them a real chance to get engaged as full and active team members in your environment, they bring so much more than testing. The above are some examples. I have seen team cohesion and collaboration improvements, product enhancement and even a defense of code standards. The testers bring an eye that seems absent when we have a whole row of instruments, and we sure could use one fiddle!
