I have been reading through Agile Testing: A Practical Guide For Testers And Agile Teams, by Lisa Crispin and Janet Gregory, when I found a small portion which discussed the existence of a "Bill of Rights" for programmers and customers. Lisa Crispin noted that a "Tester Bill of Rights" was absent, so she and Janet set forth to create one.¹
The "Tester Bill of Rights" contains six articles, each describing a primary right or responsibility of the tester within an agile team. Unfortunately, there is a lack of detail regarding each article. New testers may find themselves asking questions of these articles, specifically:
- What does it mean to provide estimates for a sprint story?
- Why should I advocate for the "whole team" approach to quality?
- How can I approach my team about adopting new tools?
This article seeks to answer the above questions while providing insight into the articles that Janet Gregory and Lisa Crispin originally penned.
Article 1
"You have the right to bring up issues related to testing, quality, and process at any time."
It is your priority as a tester to raise items pertaining to application quality at any time throughout the sprint process. These could be bugs, design inquiries, agile practices, or any other item which could be a target for continuous improvement.
While a QA Automation Engineer at TransLoc, I noticed that my team's grooming process was more focused on fleshing out stories rather than refining the backlog. This caused the team to spend more time discussing stories, ultimately ending with "grooming" a single story per session when we should have been doing at least five. As a result, we were holding two grooming sessions a week which cut into development and testing time.
I raised this as an issue to my team and discussed potential solutions with my scrum master. We decided that we would test grooming strictly as refinement time while asking for story writers to flesh out their tickets at least one week prior. The result was a net increase in efficiency as we were able to cut our time spent grooming and discussing tickets in half.
Speak up early and often about issues that you see, even if they do not directly pertain to quality and testing.
Article 2
"You have the right to ask questions of customers, programmers, and other team members and receive timely answers."
I am personally guilty of succumbing to imposter syndrome and spinning over something that I would not reasonably know while testing a ticket. I have yet to kick this ugly habit despite being in this industry for half a decade. It has caused me to waste time on development tickets that were otherwise straightforward. The solution?
Ask questions, not just of your development team, but of product stakeholders and customers as well.
One of my favorite elements of quality assurance is collaborating with my development team. I am a proponent of "desk checks" where, in an office setting, I will message a developer working on a feature and ask whether I can swing by to chat about how it is going. The developer walks me through what they have implemented so far, and I will take the time to ask any questions related to application quality.
It should be agreed upon that there are no stupid questions during a desk check. Instead, you should feel free to ask any question, big or small, that can lead to greater understanding of the feature.
I will also take time to speak with product owners and customers to better determine how our users consume the application. This not only helps when determining critical workflows or prime automation candidates, but also in becoming a stronger advocate for the customer.
You should feel empowered to ask your team, or a customer, any question which will help you better understand the application and how it is used.
Article 3
"You have the right to ask for and receive help from anyone on the project teams, including programmers, managers, and customers."
I ran into a situation recently where I was stretched thin and could not feasibly regression test all of my release tickets by myself. I had two choices:
- Risk pushing the release back by testing everything alone
- Ask my team to help test with me
I chose to ask my team to help me test, knowing full well that they are just as busy as I am. Our release went as scheduled and we were able to provide value to the customer.
I understand that for many testers it can be difficult to approach a team of developers and ask for a hand with testing, or with understanding how a feature was implemented. I have experienced this first hand, most notably when starting for new teams or new companies. What drives me forward is the understanding that if I do not ask for help, I could be sandbagging my team.
Do your best to help your team. Ask for assistance when needed, whether it be testing a ticket, clarifying a feature implementation, or understanding a process.
Article 4
"You have the right to estimate testing tasks and have these included in story estimates."
I cannot begin to tell you how often I hear from testers that their efforts in automation or testing are not factored into story estimations. Simply put, this is an anti-pattern, and one that can cost your team sprint velocity should it spiral out of control.
While it may be difficult to estimate the amount of time, t-shirt size, or effort points (whichever practice that your team follows) for testing items, you should do your best to provide a ballpark figure for the team to work with. The biggest concern that testers have when estimating is how to quantify the time they spend automating and testing.
For example, you have a ticket that is estimated at 5 story points for development which should be about 2–3 days of work. Testing for the ticket, based on history with the product, will take about half a day. Automation is being built in parallel with development and will likely take about a day to complete when all is said and done.
In my experience, I would estimate this story as an 8. I would personally add 0.5 points for testing and between 1–1.5 points for automation, resulting in 7 which rounds to 8 as the next Fibonacci number in the sequence.
Estimate your testing activities. Not only will it provide your development team with a better idea of how much effort and time it takes to test, it will also bring more accuracy to your velocity measurement.
Article 5
"You have the right to tools you need to perform testing tasks in a timely manner."
As a tester, you should feel empowered to ask for tools that may help you do your job, whether it is an open-source tool or a subscription. The best way to navigate this is by showing your leadership team the data as to why the tool is necessary for your day-to-day work.
When I started out at Vodori, Inc. the development teams were utilizing the free version of Hiptest (now Cucumber Studio) which, at that time, only allowed a total of 10 users at a time. Our team was constantly adding and removing users as developers took part in writing and executing test scenarios. It was a fairly cumbersome and time consuming process.
After about six months of wrestling with the free version, I raised that Vodori should consider the enterprise version. In an effort to state my case, I reached out to Hiptest and asked for a trial to be put in place. They gave us the enterprise version for one month with the stipulation that after the month was over, we would either need to pay or downgrade to the free version.
I charted out the amount of time we spent removing and adding licenses against the cost for the enterprise version. I also noted the benefits of using enterprise, such as access to "Living Documentation".² I then presented this data to my QA Manager and the CTO of the company, arguing that we would be saving time and effort by using enterprise.
My case was denied. Simply put, Vodori was not in the position to rely on enterprise software at the time. We just did not have the funding to justify the expenditure.
You should not feel apprehensive to ask for tools that can help you do your job better. State your case, show leadership the data, and be graceful should they deny your request.
Article 6
"You have the right to expect your entire team, not just yourself, to be responsible for quality and testing."
This is quite possibly the most important of the articles found in the "Tester Bill of Rights". Your team should understand that quality is an effort that the entire team should be working on, not just those responsible for the testing of the product.
My team at Pendo.io has been diligently working toward bringing quality from the right swim lane into the left-hand columns. Rather than focus on quality at the end of the sprint like a waterfall team, we try to discuss quality concerns as early as possible. We have currently taken the following steps to ensuring that quality is a "whole team" effort:
- Regular discussions on application quality and design in Slack
- Inviting testers to blueprinting, grooming, and planning meetings
- Noting quality impact during epic blueprinting, grooming, and planning
- Developers taking part in manual and automated testing
- Team forums on how to test and what to look for when testing
As Lisa Crispin and Janet Gregory emphasized many times in Agile Testing, quality is a "whole team" initiative and not the sole responsibility of the testing party.³
Summary
You cannot know everything, especially about new feature implementation. In these instances, ask your peers questions to strengthen your knowledge. Remember that you are not on an island, feel free to ask your peers for help whenever you feel the need to. Estimate quality tasks into sprint stories so they may provide a more accurate picture of your team's velocity. This will help fine-tune your sprints.
Ask for the right tools, but be prepared to show leadership the data on why you need it and what it can do for you. Inquire about application quality, process, and testing in order to continuously improve. Most importantly, remember that quality is a team effort.
Resources
- Agile Testing: a Practical Guide for Testers and Agile Teams, by Lisa Crispin and Janet Gregory, Addison-Wesley, 2014, p. 50.
- "Living Documentation." Living Documentation | CucumberStudio Documentation, support.smartbear.com/cucumberstudio/docs/bdd/living-doc.html.
- Agile Testing: a Practical Guide for Testers and Agile Teams, p. 15.
Jonathan Thompson is a Senior Quality Engineer at Pendo.io specializing in test automation. He currently resides in Raleigh, NC with his wife and a Goldendoodle named Winston. You can connect with him on LinkedIn, or follow him on either Twitter or Github.
Top comments (2)
I went from QA to Development and I really like this. There can be a tension that is completely unnecessary between the two. In the end, it's about making good things. I likewise think that the desk checks go both ways. If I am implementing something and some uncertain state becomes apparent, I like involving qa and business to get it sorted out, before jumping into faulty assumptions.
Yes! Desk checks can absolutely go both ways. I'm a big fan of developers pulling me aside as they are working on a project to discuss "gotchas" and other quality related items.