The first scrum team I worked in was small. The developers sat on their side of the building and worked on new feature code. I sat on the other side with the testing group, looking for problems in that new code. Testers and developers met once each morning to talk about our progress, and what was preventing us from moving forward. Our version of scrum and agile was a waterfall process that took two weeks.
Each phase of the project took place in sequence, so that progress would flow steadily forward. Today I view this type of process as a “mini-waterfall” and therefore a transition state, and as a step in the right direction. Then again, in terms of improvement, everything is a transitional state. As testers, we needed to adapt our strategy, therefore our test team created a balanced skill-set to help smooth the flow of development.
Join 34,000 subscribers and receive carefully researched and popular article on software testing and QA. Top resources on becoming a better tester, learning new tools and building a team.
According to The Scrum Guide by Ken Schwaber and Jeff Sutherland, teams are self-organizing and cross-functional. The Scrum Team consists of a Product Owner, the Development Team, and a Scrum Master. Through my experience, I have observed that there are different roles within our test team too.
The Technical Tester
Ron Jeffries describes the ideal agile team like this: A very small team with just enough skill to deliver one piece of code works on a change until it is ready to deliver to the customer. That’s it.
A balanced scrum team might have a developer or two to build the API, a front-end developer, someone that understands build-tools, and delivery, and a tester. While the back end is being built, the tester is making one API call at a time to explore the codes capabilities. The tester will also be busy building automation in an API testing framework. This is the behavior of a relatively “Technical Tester”.
There is a wide spectrum for how technical that tester needs to be; anything from being able to fake calls and debug the API in the browser, to writing production code.
Once the API is checked-in, the front-end developer can start wiring up their changes. This presents an opportunity to build a small amount of UI automation. UI automation can be a challenging task (see a previous blog, Consider “Reasonable” UI Test Automation), however building it at this point forces exploration. I can’t build UI automation without exploration. I might start with an idea of what I need to build, but not fully understand the workflow to get it done. Before I can write code, I open the browser and work out how the user would behave. That usually involves discovering different ways to perform a workflow, coming up with questions about the product, and probably discovering bugs. To really shift, and have an effective scrum team that delivers ‘done’ code at the end of each sprint, testers need to understand a little code.
Balanced scrum teams with Technical Testers don’t have sprint lags so that one team member can catch up on building automation, while the other developers move on to the next release. Features are done when they have been developed, explored, and have automation running in continuous integration. A complete feature is a ship-able feature.
The Tool Smith
This person is a programmer with a deep interest in testing. Some might call them ‘test infected’. The Technical Tester is someone that can use frameworks, and write just enough code to build a test. For the most part, that isn’t a whole lot of code. Tool Smiths build the tools that help testers get their work done in a sprint. UI automation built directly with an API like WebDriver is good for a handful of tests, but after a while it becomes increasingly challenging. When code is duplicated, one UI change will require updating several tests. The Tool Smith alleviates these problems by building PageObjects and domain specific languages (DSL).
Without a page object, the tester will have to:
- Write code that navigates to login page.
- Wait for username field to be visible.
- Wait for password field to be visible.
- Enter username and password.
- Click submit and wait for landing page.
With a page object, the test builder simply types logOn().
It is also worth noting that the Tool Smith is also helpful in the build and deploy pipeline.
I have started several automation projects over the course of my career. I usually started out with a request from management, focused on shrinking the time it takes to do pre-release testing. We would look at several different tools and build a proof-of-concept (POC) with each. After doing a demo of each tool, a manager would select the most suitable tool and we would move forward with that one. Then during the first couple of weeks we would build page objects or reusable libraries for an API suite. At some point, someone would ask “Hey, where are those tests running?”. No one would have a good answer, because we had been running the tests on our local machines’ the entire time. Each day we would ask our Ops person to help us get the tests running in Continuous Integration, and each day that person would come up with tasks that were more important. If we had a person that was familiar with build systems and empowered to make changes, our tests would have been running with every build from the first day.
The Generalist
So far, I have discussed the technical skills required to balance a fast-paced scrum team. Those technical skills are not useful, unless you already have a solid foundation in testing. I mostly see this skill set in people that have moved between different roles in software development. I spent the first three years of my testing career doing mostly non-technical work in a waterfall company. It wasn’t glamorous, but we delivered software that people paid for. We had a new specification, new project deadline, and new features to test every release cycle. I developed some fundamental testing skills during this period; test techniques, list domain and scenario testing. I also developed an understanding on how specifications or user stories were useful, and how they could lead testers astray. My skills in observation and discovering what is important, improved. Eventually, I started working on a technical project building UI automation. Those skills helped me better understand what tests would be more useful to run repeatedly and why.
My personal experience has been that people with experience in support, product management, testing, and automation are best suited to the role of a tester on a scrum team.
Getting Real
When people talk about scrum teams, I usually see a waterfall team plus daily stand-ups. This is the same silo-ed groups working through the same start-and-stop methodology as they always have. I see balanced scrum teams as something different. A balanced scrum team has a small group of developers, just enough to cover the skill set they need to produce features for this release cycle. This will also have arguably more importantly, a tester that is skilled in software testing and has a good technical foundation.
The next problem is the roles. Many Scrum teams don’t have a technical-tester, or a Tool Smith tester. They might not even have three testers, or even two. In those cases, I see the skill set fluctuating. The build-master might take over the role of the Tool Smith, or, at larger organizations, a single Tool Smith might support multiple teams. On some teams, the developers are Technical Testers, requiring stories to be tested by someone else before they are told they are done, and that person might be a programmer. In some cases, a single generalist test coach supports many generalist programmers-who-do-lots-of-things.
As I hinted at before with continuous improvement, the key is not to define some perfect end state the team should reach in eighteen months. Furthermore, the key certainly is not an immediate process cut-over with no skill development. Instead, the question is what to do next; a little more of this, a new responsibility here, a little less of that.
Get the balance right, and you can be ready to release software any time.
This is a guest posting by Justin Rohrman. Justin has been a professional software tester in various capacities since 2005. In his current role, Justin is a consulting software tester and writer working with Excelon Development. Outside of work, he is currently serving on the Association For Software Testing Board of Directors as President helping to facilitate and develop various projects.
