Yes it is necessary!
Early on in my role as QA Analyst, I saw first hand the pitfalls of getting QA involved in a project too late. After all, it’s common knowledge that testing is not needed until the end of the project… Right? Wrong!
The project was about 75% complete when I came on board. The requirements were pretty well set (in somebody’s mind), but they were not all in one place. It turned out that they were sprinkled among the many other project documents and it wasn’t until we gathered them up to review that the stakeholders realized they were not exactly what they thought they were. Nobody likes surprises this late into a project because it usually leads to delays and more cost. As you might suspect, things did not end as well as they should have for this project.
It was, however, a good learning experience and I am happy to say that we learned from our mistakes, and are now embracing the idea by getting QA involved early on in the projects. The chart to the right shows a relationship between early and late testing.
This is not a new idea by any means, but people still have differing ideas on what the role of QA and Testing should be on a project. (See What is QA? for my thoughts on this.) If you have read any of the QA information on this site, you know that I am a firm believer in the Context-Driven approach to software testing. Today’s post reinforces this approach and it gives you a good idea of the kind of things we are thinking about while in these early project discussions.
This post was written by Michael Bolton (not the singer), and is shown in its entirety below. It explains some of the things we are looking at and thinking about during these early meetings and discussions of the project. I think it’s important for everyone in the project to have an understanding of others’ roles because this really IS a team effort, isn’t it. During these meetings, our minds do not shut out all thoughts that are contrary to our own roles so you are very likely thinking about things that I am concerned about. And I am, likewise, probably thinking about things that you are concerned about. Hopefully, this will foster discussions and we will all have a much better understanding of how the project will come together and succeed. Enjoy!
(At Least) Four Things for Testers To Do in Planning Meetings
There’s much talk these days of DevOps, and Agile development, and “shift left.” Apparently, in these process models, it’s a revelation that testers can do more than test a built product, and that testers can and should be involved at every step of development.
In Rapid Software Testing, that’s not exactly news. From the beginning, we’ve rejected the idea that the product has to be complete, or has to pass some kind of “quality gate” or meet “acceptance criteria” before we start testing. We welcome the opportunity to test anything that anyone is willing to give us. We’ll happily do testing at any time from the moment someone has an idea for a product until long after the product has been released.
When testers are invited to planning meetings, there’s clearly no product to test. So what are we there for?
We’re there to learn. Testing is evaluating a product by learning about it through exploration and experimentation. At the meeting, there is a product to test. Running code is not the only kind of product we can test—not by a long shot. Ideas, designs, documents, drawings, and prototypes are products too. We can explore them, and perform thought experiments on them—and we can learn about them and evaluate them.
At the meeting, we’re there to learn about the product; to learn about the technology; to learn about the contexts in which the product will be used; to learn about plans for building the product. Our role is to become aware of all of the sources of information that might aid in our testing, and in development of the product generally. We’re there to find out about risks that threaten the value of the product in the short and long term, and about problems that might threaten the on-time, successful completion of the product.
We’re there to advocate for testability. Testability might happen by accident, without our help. It’s the role of a responsible tester to make sure that testability happens intentionally, by design. Note that testability is not just about stuff that’s intrinsic to the product. There are factors in the project, in our notions of value, and in our understanding of the risk gap that influence testability. Testability is also subjective with respect to us, our knowledge and skills, and our relationship to the team. So part of our jobs during preparation for development is to ask for the help we’ll need to make ourselves more powerful testers.
We’re there to challenge. Other people are in roles oriented towards building the product. They are focused on synthesis, and envisioning success. If they’re designers, they might be focused on helping the user to accomplish a task, on efficiency, or effectiveness, or on aesthetics. If they’re business people, they might be focused on accomplishing some business goal, or meeting a deadline. Developers are often focused more on the details than on the big pictures. All of those people may be anxious to declare and meet a definition of “done”.
The testing role is to think critically about the product and the project; to ask how we might be fooling ourselves. We’re tilted towards asking good questions instead of getting “the right answer”; towards analysis more than synthesis; towards skepticism and suspicion more than optimism; towards anticipating problems more than seeking solutions. We can do those other things, but when we do, we pop for that moment out of a testing role and into a building role.
As testers, we’re trying to notice problems in what people are talking about in the meetings. We’re trying to identify obstacles that might hinder the user’s task; ways in which the product might be ineffective, inefficient, or unappealing. We’re trying to recognize how the business goal might not be met, or how the deadline could be blown. We’re alternating between small details and the big picture. We’re trying to figure out how our definition of done might be inadequate; how we might be fooling ourselves into believing we’re done when we’re not. We’re here to challenge the idea that something is okay when it might not be okay.
We’re there to establish our roles as testers. A role is a heuristic that helps in managing time, focus, and responsibility. The testing role is a commitment to perform valuable and necessary services: to focus on discovering problems, ideally early when they’re small, so that they can be prevented from turning into bigger problems later; to build a product and a project that affords rapid, inexpensive discovery and learning; and to challenge the ideas and artifacts that represent what we think we know about the product and its design. These tasks are socially, psychologically, emotionally, and politically difficult. Unless we handle them gracefully, our questioning, problem-focused role will be seen as merely disruptive, rather than an essential part of the process of building something excellent.
In Rapid Software Testing, we don’t claim that someone must be in the testing role, or must have the job title “tester”. We do believe that having someone responsible for the testing role helps to put focus on the task of providing helpful feedback. This should be a service to the project, not an obstacle. It requires us to maintain close social distance while maintaining a good deal of critical distance.
Of course, the four things that I’ve mentioned here can be done in any development model. They can be done not only in planning meetings, but at any time when we are engaging with others, at any time in the product’s development, at any level of granularity or formality. DevOps and Agile and “shift left” are context. Testing is always testing.
You can see Michael’s original post here: Four things a Tester can do to gain value in the early stages of a project. Michael Bolton is a well sought after professional tester, speaker, and consultant. He is also the co-creator of Rapid Software Testing, a course and a fast-growing methodology of testing that is gaining wide acceptance across the industry. Rapid Software Testing focuses on the skill and the mindset of the individual tester to perform excellent testing more quickly and less expensively, in a way that stands up to scrutiny.