Read Along- ‘Agile Testing’ Chapter-6

“The Purpose of Testing”

  • The Agile Testing Quadrants matrix helps testers ensure that they have considered all of the different types of tests that are needed in order to deliver value.

Quadrant-1

Unit tests verify functionality of a small subset of the system. Component tests verify the behaviour of a larger part such as a group of classes that provide some services. Unit & Component tests are automated and written in the same programming language as the application. They enable programmers to measure what Kent Beck has called the internal quality of their code.

Quadrant-2

  • Tests in Quadrant-2 support the work of the development team but at a higher level. These business-facing tests define external quality and the features that the customers want. They’re written in a way business experts can easily understand using the business domain language.
  • The quick feedback provided by Quadrant 1 and 2 automated tests, which run with every code change or addition, form the foundation of an agile team. These tests first guide the development of functionality and when automated, then provide a safety net to prevent refactoring and the introduction of new code from causing unexpected results.

“Appraising a software product involves both art and science.”

Quadrant-3

  • Quadrant-3 classifies the business-facing tests that exercise the working software to see if it doesn’t quite meet expectations or won’t stand up to the competition. They try to emulate the way a real user would work the application. This is manual testing that only a human can do…use our senses, our brains and our intuition to check whether the development team has delivered the business value required by the customer.
  • Exploratory testing is central to this quadrant.

Quadrant-4

  • Technology-facing tests in Quadrant-4 are intended to critique product characteristics such as performance, robustness and security.
  • Creating and running these tests might require the use of specialised tools and additional expertise.
  • Automation is mandatory for some efforts such as load and performance testing.
Agile Testing Quadrants

Technical Debt

  • Ward Cunningham coined the term “technical debt” in 1992, but we’ve certainly experienced it throughout our careers in software development.
  • By taking the time and applying resources and practices to keep technical debt to a minimum, a team will have time and resources to cover the testing needed to ensure a quality product. Applying agile principles to do a good job of each type of testing at each level will, in turn, minimize technical debt.
  • Each quadrant in the agile testing matrix plays a role in keeping technical debt to a manageable level.

The Agile Testing Quadrants provide a checklist to make sure you have covered all your testing bases. Examine the answers to questions such as:

  • Are we using unit & component tests to help find the right design for our application?
  • Do we have an automated build process?
  • Do our business-facing tests help us deliver a product that matches customer expectations?
  • Are we capturing the right examples of desired system behaviour?
  • Do we show prototypes of the UIs and reports to the users before we start coding them?
  • Do we budget enough time for exploratory testing?
  • Do we consider technological requirements like performance and security early enough?

3 ways Agile testers can use Walkthroughs

A walkthrough is a great review technique that can be used for sharing knowledge, gathering feedback and building a consensus. Typically, walkthroughs take place when the author of a work item explains it in a brief review meeting — effectively walking the team through the work — and gathers people’s feedback and ideas about it. These meetings may be as formal or as informal as needed and may also be used as a knowledge-sharing session with many relevant stakeholders at once.

In my article published at https://blog.gurock.com/tester-agile-walkthrough/ , I have discussed three ways agile testers can make use of this type of review for their sprint- and release-level test plans and test cases to get the entire team involved in the quest for quality.

I have also discussed how I have used walkthroughs in my agile team as a mechanism to review our sprint test scenarios with the entire Scrum team. The main areas of application are-

  • Defining Scope
  • Generating Test Ideas
  • Building a Consensus

Click here to read the complete article–>

Walkthroughs are a quick and easy review technique to adopt, and they can be especially useful for testers on an agile team to get reviews on their test plans, test cases, and scripts. Give this technique a try, even if in an informal sense, and see how beneficial it can be!