I believe that teams can achieve quality by everyone experiencing what skilled testing is truly about. Understanding skilled testing can help team members realize what quality criteria should be there and what elements of a product contribute to great quality.

To learn all that, I propose that non-testers participate in testing. I’m not saying that there shouldn’t be dedicated testers anymore, or that everyone on the team has to own testing activities equally—just that all team members should contribute.

Whole-team testing means the whole team understands and participates in testing, using testing education as a tool to build a quality product. And to be able to support testing in a meaningful way, team members must experience how testing is done by professional testers.

This also means testers should be freed up to perform skilled exploratory testing on the product, identify risks that are beyond the obvious, and help the team to analyze, visualize, and improve quality throughout the product lifecycle.

The more people who learn, participate in, and facilitate testing, the more you achieve in less time.

Who Should Participate?

It’s obvious! Whole-team testing is meant to involve everyone who contributes to the quality of software or is responsible for its assessment. I highly recommend involving different stakeholders at regular intervals to make whole-team testing truly a whole-team effort.

There most likely will be some pushback, like not everyone being willing to accept responsibility for doing testing because it is not their primary job. These team members should realize that they can still help by having an understanding of what skilled testing is so that they can incorporate their knowledge into creating a quality product—and know how to approach testing in an hour of need.

There are other advantages, too. Typically in projects where dedicated testers are mainly held responsible for software quality, there is a back-and-forth between devs and testers that usually eats up a lot of time in discussing, fixing, and retesting the bugs. This can be avoided and a lot more can be achieved if everyone in the team develops a quality mindset and tries to acquire skills that help them perform meaningful testing.

What Quality Means

There are three main notions of quality:

• The quality of the product that the team together works to build
• The quality of an individual’s work (tester, programmer, or anyone else on the team)
• The quality of the project itself

I talked with Michael Bolton about this topic, and he said, “The quality of the project can be observed, assessed, or experienced by things that contribute to great working culture within the team, clarity of roles, depth and development of skills, awareness, availability and application of appropriate tools and mindset, and, ultimately, with effective and efficient development of the product.”

As we discussed critically the tester’s and programmer's roles and how they contribute to quality in various work contexts, Bolton made some interesting arguments: “In project teams in general, responsible testers have, for the most part, responsibility for and authority over the quality of their own work. They do not have that responsibility and authority with respect to the product. They contribute to the quality of the project, and they have responsibility and authority over that contribution, but not over the project as a whole.” Even though I believe this is subjective (provided that in some contexts, testers are part of the team who are given autonomy to make decisions about quality), I feel his argument holds true for most of our industry.

Bolton continued, “Similarly, a developer who is doing programming has control over the quality of her work and of the product. She is building the product and contributing to that. But when she starts testing her code or reviewing another programmer’s work, she’s in a different role: observing and analyzing product quality, not adding to it. That doesn’t happen unless and until she departs the testing role and testing mindset, re-enters the builder role and builder mindset, and changes her code. When the other developer changes his code, then he is adding to and controlling quality.

“The tricky part here is that those mode switches are hard to notice from the outside, and they happen very quickly. The two modes get lumped into ‘development.’ It’s not wrong to think of these two modes as the same thing at one level of observation and analysis. But if we want to look more carefully at particular skills, or activities, or mindsets, or problems, we need sharper conceptual scalpels.”

I think that by educating non-testers about testing and asking them to participate, it is possible to sharpen those conceptual scalpels. Individuals on the team can effectively contribute to project and product quality by improving the quality of their individual work at the same time. That’s essentially what I mean by achieving whole-team quality using whole-team testing.

Establishing processes and workflows to facilitate collaboration for testing efforts within the team is a useful mechanism, but I still look at them more as enablers. Merely pairing non-testers with testers is not going to help reduce dependency unless the non-testers are given the right tools, mindset, and skills to test independently and effectively.

With that in mind, I have created some additional session types on the grounds of session-based testing to give a structure to implement whole-team testing.

Quality Criteria Session

As Jerry Weinberg advised, “Act early, act small.” The earlier you start involving others in your testing-related efforts, the better it is going to be for everyone to contribute to creating better quality software.

If you are working in a typical Scrum setup, then I suggest you start with this session.

The team would perform this session at the time of sprint planning or discussing the sprint goal and epics. Ideally, everyone should participate, including the product owner and other relevant stakeholders.

I recommend creating a risk checklist for your team context based on the quality criteria heuristic from the Heuristic Test Strategy Model. For each item below in the mind map (click to enlarge), inspired by João Farias, determine if it is important to your project for given sprint goals or milestones you want to achieve, then think about how you would recognize if the product worked well or poorly in that regard.

As Bolton and James Bach point out, by thinking about different kinds of criteria, you will be better able to plan tests that discover important problems fast. Each of the items on your list can be thought of as a potential risk area. Do not get overwhelmed by the volume of the ideas; not everything will be applicable for every sprint. More important is that the team has a discussion and makes it part of the process.

When it becomes part of the team culture to regularly assess your sprint goals or user stories for risks and quality criteria, it will become part of an individual's habit to think of those factors consciously, putting further efforts toward achieving them. By involving everyone in this testing activity, you are making sure that you address important problems before it is too late.

Pairing for Testability Session

Whole-team testing is about more than performing the test design or execution together; it should be for improving the testability of product in a number of ways.

There are a number of ways to pair with programmers:

• Creating an alert system for error logs from production
• Creating solutions to more easily create test data
• Improving error-handling for the product 
• Creating solutions for better observability 
• Improving controllability for ease of testing 

Testers can perform the role of advocate here while also learning from programmers about technical details and useful practices.

Teams could create user stories or technical debt tasks and do these activities at regular intervals. I strongly recommend making intrinsic testability part of your checklist for this pairing session and using it for all major tickets, right from the beginning.

Pairing for Coverage Session

For this session, I recommend starting with analyzing the impact of a given change on your product, parts of the product, downstreams, or other interfaces your product must interact with. Pairing with the programmer will better help the tester to identify these areas of impact from technical aspects, and the programmer will benefit from the tester's input to understand functional dependencies, end-to-end business flows, blockers of any kind, or even test data and environment dependencies. Of course, the edge cases and other tricky situations are added benefits.

In the absence of a clear idea, this is easier said than done. If you need help getting started, I recommend referring to the product elements checklist as a basis for this pairing session. Having a quick discussion about all those elements of your product should help everyone think of aspects for better all-round test coverage.

Testers can also create a risk list that is applicable for each product or project and pair with programmers for developing it further. Whether to document these ideas in pull requests, user stories, or some other way is up to what your team feels more comfortable with. It is less about the format or process than about the value it is creating.

This session would usually be done before coding starts on high-complexity tickets by pairing with a programmer, or after the coding has been done to review and refine the test coverage map that the tester has already created.

For example, let’s say that the user story warrants you to change how the purchase of your product is being made, while that change depends on the payment solution being worked on by other teams. This change is complex and beyond just changing the business flow—it involves changes on many levels and interfaces. There are also business-analytics reasons for tracking this change. It is unlikely for an individual to come up with a comprehensive test strategy in a short time, so this would be a good situation for a Pairing for Coverage session about the requirements. A high-level outcome for the above scenario could look something like this (click the picture to enlarge):

I suggest you start practicing on larger, more complex tickets first, so that the pairing experience is not overwhelming for non-testers. Use this pairing opportunity to onboard them with given heuristics and prepare them to have a checklist in mind while they work through their tasks. Once they get familiar with these lists, they will find it easier to apply them to smaller items.

This pairing can also be extended to identifying what to automate and creating process flows and agreements around ownership of automation efforts. It would be great if testers could write automation and make sure that other members in the team are familiar with their checks so that others can take over to add new tests or fix broken ones if needed. Writing an automated check before deploying the change to production can also be an effective way to encourage sharing of responsibility for automation.

QX (QA + UX = Quality Experience) Session

Quality experience is what would happen if systems thinking meets design thinking. A regular and close exchange, typically during the design phase, between these two disciplines has tremendous potential to create a better user experience with enhanced product quality.

Sure, the design team can get some product ideas based on user tests and interviews they perform, but there is a lot more that matters when it comes to building software that a large customer base would like to use. I believe that challenges faced by testers and UX professionals are more or less the same when it comes to ensuring better quality and better user experience.

If a UX designer has a solution for a product problem, a skilled tester with quality insights, product knowledge, and awareness around cross-functional dependencies can point out a variety of ways in which the solution may fail, helping to avoid lots of unnecessary research and rework.

Testers can also borrow realistic information from UX's research that can help them design tests that matter and avoid straying into unwanted territory. Testers can get statistical data or interaction-based information from the UX team that can shape a better scope for their tests.