This is a guest posting by Jess Ingrassellino. Jess is a software engineer in New York. She has perused interests in music, writing, teaching, technology, art and philosophy. She is the founder of TeachCode.org
It’s a big, Agile world out there, filled with lots of advice about how Agile practices can help your company deliver more stuff, better and faster. As a tester, you might see those Agile practices as being great ideas, but be unable to get them implemented in your organization. Perhaps instead, you can incorporate some of them into your everyday testing practice?
Here are three ways that any tester can implement some fundamental principles of the Agile Manifesto into their day-to-day work.
Get TestRail FREE for 30 days!
Working Software: Minimize Necessary Documentation
In some organizations, highly regulated industries for example, it’s difficult to reduce the amount of documentation required to prove that appropriate testing has been carried out. For these companies and testers, documentation is a serious part of their work, providing external auditors with an understanding of everything that has been tested. Since most companies aren’t regulated though, testers have a lot of freedom in how testing is performed so as to reduce unnecessary documentation.
Session-based testing (allotting a specific amount of time, or a session, in which to complete an exploratory test), or test charters (a way to document the details of an exploratory test session), are ways to reduce documentation while still maintaining the desired level of testing evidence. Good test charters contain rich descriptions of the ways in which testers interacted with the product. They also contain bugs that might be logged, notes about potential issues, and questions that can be used to enhance regression suites, create further test charters, or inform acceptance criteria in new features.
A sample test charter for a 90-minute session, testing e.g. a checkout page on a website, would include technical information — like the browser, operating system, and any other information pertinent to the environment in which you are testing. Then you might make a claim: “Today, I will test the checkout page of XYZ Widgets Website”, and make a shortlist of areas that you want to cover: shipping name and address, billing name and address, and billing information, might be part of a checkout page for example.
In the charter, you keep detailed notes about your activities. There is no script. As you are testing the shipping name and address, you might find that no zip code is required to save shipping information. In your notes, you describe what happened, and what tests you decided to perform because you found out that the zip code is not required. You can write about issues and bugs too.
Furthermore, the test charter can be a collaborative artifact in development teams, shared with product managers and developers using whatever communications tools are available. The charter can be read by developers and project managers, who in turn can leave their comments, questions, and concerns, leading to meaningful dialogue about the software under test.
Customer Collaboration: Good Test Design
Testers serve the end user, but in a collaborative development environment, testers work with developers, product managers, and customer support in order to do their work. Robust test cases and acceptance criteria are generated by getting feedback from developers, product managers, and even consumers (or their representatives in the company) to ensure tests are designed that address a wide variety of use cases.
Collaboration with customer support can help testers get into the mindset of the customer during exploratory testing. Customer support hears customer issues daily, and can tell testers how users are engaging with the application.
Getting realistic use cases and user stories can help frame the tester’s mindset for exploratory testing. This mindset can be extended as testers identify scenarios that are best suited for automated regression and write end-to-end tests from the customer’s perspective. In this way, testing becomes a channel for helping to improve product quality, and better acts as an advocate for the customer.
Responding to Change: Virtuous Feedback Loops
The final principle of the Agile manifesto highlights responding to change. Feedback from testers helps development teams by providing them with more information with which to respond to the changes that they may have introduced to the product. Testers have many opportunities to provide feedback to the entire business, and to involve the business in the process of getting that feedback.
For example, testers can invite the sales or marketing teams to test a major feature before release, getting valuable feedback from them as they see the feature for the first time, while also providing them with an experience of being a part of the testing process. The feedback garnered from this group testing event, provided to the development team, can yield interesting bugs, as well as insights into how end-users might engage with the finished product.
Everyday Agile Practices
Every tester can look to the principles of the Agile manifesto, and engage in any number of practices that will improve their daily work. Some of them might be transformative, like having lunch while introducing a new feature; others might be small, such as using test charters as a collaborative documentation tool. But they are powerful nonetheless, because they make testing work more meaningful.
- TestRail Again a Leader in the G2 Grid for Software Testing
- Announcing TestRail 5.7 with Enterprise Features, new API Endpoints and Edit Result Permissions