QA staff members are commonly known as testers, but the role of a tester should go beyond the simple notion of verification testing. The primary responsibility—and passion—should be to contribute to the highest quality of the final product. Quality assurance staff are responsible for verifying that a releasable software product achieves a high level of quality and provides a good user experience. QA also helps the team identify problems as early as practicable, and works to avoid sacrificing quality when pressure builds to meet a delivery target. But there is more to it than this.
Testing innovative, complex software application requires the ability to recognize various situations that may arise as the product continues to evolve. A good tester must not only have a strong dedication to high quality but also have the ability to recognize a new testing context—and have a good perspective of the testing role—to work intelligently through the best testing approach. That is the main focus of this article.
Many development teams often make unsteady progress against aggressive project schedules, and frequently discover what must be done only a short time before it’s necessary to find a way to get it done. There are a variety of techniques and methodologies that are in use—some informal, some formal, some flexible, some too rigid. It is important to know how to test for each situation.
Much of our inspiration for this article comes from the book Lessons Learned in Software Testing: A Context-Driven Approach—in which the authors present a treasure trove of lessons on the best ways to develop professionally as a software tester. They share the wisdom that has accumulated from their extensive history as senior QA professionals in a variety of software product teams.
The authors of Lessons Learned in Software Testing are strong advocates for a context-driven approach to software testing. To avoid surprise, frustration, and delay, it’s best to maintain an expectation that while a particular method may work well in a few contexts, it may not work in various other situations. Instead of focusing on universal best practices, it’s better to get familiar with a variety of practices—each of which will be more or less suitable for a specific context. Though we won’t go into detail on this context-driven approach to testing (a topic for a future blog article!), we do cover the role of a tester from this general perspective: The WHAT of testing—the tools, techniques, and strategies—is seen most clearly in terms of WHO, WHERE, WHEN, WHY and WHAT IF.
Further on in this article, we’ll point you in the right direction to discover how Functionize Natural Language Processing and Adaptive Event Analysis can help you quickly adapt to different testing contexts. With Functionize NLP and AEA, it’s much, much easier to customize your testing on-the-fly, so that you can readily accommodate a steady stream of functional and configuration changes—as your application continues to evolve and grow.
The ideal should always be to take from a selection of known best practices and apply them to the specific situation that your team is facing—in the most efficient way that enables testing excellence. Good testing won’t happen by commandeering the project, being inflexible, or intimidating developers. None of us expects to do great testing by completing hundreds of little forms or wasting precious time on inefficient processes. Excellent testing requires (a) skillful technical work to search for defects and (b) persuasive, accurate communication. To the extent that this work can be automated with tools such as Functionize, all the better.
Every test that you run, every document that is written, and every meeting you attend diverts time away from designing and executing other tests that might reveal a critical defect. Facing this reality head-on, it becomes quite sensible to invest time optimizing your testing processes by leveraging more and more product knowledge—including the weakness therein. What you can assimilate well today will become part of better testing tomorrow.
A role defines a relationship. While you probably don’t control your role, you can negotiate its shape. People will sometimes be unreasonable, so when someone blames you—a member of QA—for a low-quality product, that person is exhibiting role confusion. Perhaps they mistakenly think that you didn’t properly wave the Magic Wand of Quality over the release candidate (perhaps with insufficient sincerity?) prior to shipment. Negotiation and clarity on QA role definition will set expectations for any future situation in which your efforts are called into question—by yourself or anyone else. Oh, and, we probably don’t need to tell you this, but a clear and suitable testing role is often a demanding role. But you can shine brightly when you clearly understand the role of a software tester.
QA is the headlights of the development effort. Most worthwhile software projects are much like driving a truck in the mountains at night, off-road—at night. Such projects need high-beam headlights. Together with your fellow testers, you illuminate the way forward. Though the team leads and developers may squabble over the reading of the map, QA helps the entire team get a clear view of the surroundings—providing the situational awareness at any point in the development pipeline. The testers do this in large part by communicating the viability of the product in its current state. Remember, above all, that testing is done to acquire information—which drives highly critical decisions about the current release cycle or the product itself.
Your mission may depend to some extent on your project, company, industry, and/or team dynamics. For the QA profession, an impediment to forward progress in test-craft has been the difficulty of having a common dialogue on test practices that spans different technical and cultural differences. These numerous differences correspond to a variety of missions among all test teams.
Any of the following might be part of your mission definition. Which of these are most familiar to you?
If you waste effort verifying requirements that your customer or team doesn’t prioritize, then you risk being counterproductive. Again, it’s vital that you negotiate and clarify your testing mission your manager. If you can’t agree on that mission, you won’t have a solid foundation for your testing efforts.
Testing is a service role, and vitally necessary to product success. Service implies that you have clients-those whom you serve. Team success is largely measured by how QA serves the needs of other dependent roles. Each of the other roles has particular needs (which sometimes don’t align well), and all of them have an interdependency with QA.
Project manager — The PM must know your process and have the right to influence it. You support the PM by reporting status as necessary, reporting critical problems immediately, and working hard not to block the project. The job of the PM is to direct the project team, and the job of a tester is to inform the PM what you can and can’t do—and how this impacts the project.
Customers — The customer is the penultimate client for the entire product development team. At the very core, you serve those who receive and use the release product. Of course, their satisfaction is paramount, but QA can also enjoy a special role in being the primary customer advocate.
Developers — You make the developers’ jobs easier by providing good bug reports—as soon as possible. Strive to know your craft and know the product, so you don’t waste the programmer’s time with mistaken or frivolous reports. If you can do that, you’ll have a lot more credibility, and that will translate into support and influence.
Technical writer — Along with QA and DevOps, those who write user guides often lack complete product information. You can assist them in understanding how the product truly functions, and you review existing documents for discrepancies. Reciprocally, writers can help by relaying information that you wouldn’t otherwise know.
Other roles include technical support, marketing, and upper management. Learn about those who are important on your project, and get to know those with whom you are collaborating. Discover whom you serve. This will carry you a long way toward excellence in testing.
The industry is long overdue for a viable, veridical testing automation solution that is easily reconfigurable and readily accommodates various testing contexts. That time is now upon us. Functionize makes it easy to establish, edit, change on-the-fly, manage, and continually refine the automation all of your test cases. Functionize has made it even easier with the addition of a natural language processing (NLP) engine to its comprehensive testing solution. Functionize NLP makes it much easier to create test cases and to modify each one—at any time you find it necessary. The NLP format is intuitively easy for virtually anyone to understand.
The Functionize NLP engine ingests a pre-formatted document containing test case plans that have been written as simply and naturally as you might have them already in a Microsoft Word or Excel document. You could write, for example:
“Verify that all currency amounts display with a currency symbol.”
Anyone on the entire development team can write statements like these. Indeed, most companies already have a written collection of statements that articulate use cases and user journeys. Many such statements can be placed into a file for import into the Functionize NLP engine, which can rapidly and intelligently process all of the statements in the import file—and generate each of the steps for the test case. It’s easy to modify those test cases when the import process completes.