Read Along- ‘Agile Testing’ Chapter-8

“Business-Facing Tests that Support the Team”

A look at tests in Quadrant-2 – Business-Facing tests

Agile Testing Quadrants
  • On an agile project, the customer team and the development team strike up a conversation based on a user story.
  • Business-facing tests address business requirements. They express requirements based on examples and use a language and format that both the customer and development teams can understand. Examples form the basis of learning the desired behavior of each feature and we use those examples as the basis of our story tests in Quadrant-2
  • Business-facing tests are also called “customer-facing”,”story”,”customer” and “acceptance” tests. The term ‘acceptance tests’ should not be confused with ‘user acceptance tests’ from Quadrant-3.
  • The business-facing tests in Q-2 are written for each story before coding started, because they help the team understand what code to write.
    • Quadrant-1 activities ensure internal quality, maximize team productivity, and minimize technical debt.
    • Quadrant-2 tests define and verify external quality and help us know when we are done.

The customer tests to drive coding are generally written in executable format, and automated, so that team members can run the tests as often as they like to see if functionality works as desired.

  • Tests need to include more than the customer’s stated requirements. We need to test for post-conditions, impact on the system as a whole, and integration with other systems. We identify risks and mitigate those with our tests. All of these factors then guide our coding.
  • The tests need to be written in a way that is comprehensible to a business user yet still executable by the technical team.
  • Getting requirements right is an area where team members in many different roles can jump in to help.
  • We often forget about non-functional requirements. Testing for them may be a part of Quadrants 3 and 4, but we still need to write tests to make sure they get done.

There are conditions of satisfaction for the whole team as well as for each feature or story. They generally come out of conversations with the customer about high-level acceptance criteria for each story. They also help identify risky assumptions and increases team’s confidence in writing & correctly estimating tasks needed to complete the story.

  • A smart incremental approach to writing customer tests that guide development is to start with a “thing-slice” that follows a happy path from one end to the other. (also called a “steel-thread” or “tracer-bullet”). This ‘steel-thread’ connects all of the components together and after it’s solid, more functionality can be added.
  • After the thin slice is working, we can write customer tests for the next chunk.
    • It’s a process of  “write tests — write code— run tests — learn”
  • Another goal of customer tests is to identify high-risk areas and make sure code is written to solidify those.
  • Experiment & find ways your team can balance using up-front detail and keeping focused on the big picture.

Quadrant-2 contains a lot of different types of tests and activities. We need the right tools to facilitate gathering, discussing, and communicating examples and tests.

>>Simple tools such as Paper or Whiteboard work well for gathering examples if the team is co-located.

>>More sophisticated tools help teams write business-facing tests that guide development in an executable, automatable format.

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?

Read Along- ‘Agile Testing’ Chapter-5

“Transitioning Typical Processes”

  • There are many processes in a typical project that don’t transition well to agile because they require heavyweight documentation or are an inherent part of the phased and gated process & require signoffs at the end of each stage.

“Metrics can be controversial”

  • Measurements such as cycle time that involve the whole team are more likely to drive you toward success than measures confined to isolated roles or groups.
  • Lean development looks for ways to delight customers, which ought to be the goal for all software development.
  • Metrics that measure milestones along a journey to achieve team goals are useful.

When you are trying to figure out what to measure, first understand what problem you are trying to solve. If your goals are measurable, the measurements you need to gather to track the metrics will be obvious.

  • Figure each metrics Return on Investment and decide whether to track or maintain it. Does the effort spent collecting it justify the value it delivers? Can it be easily communicated and understood? Do what works for your situation. Experiment with keeping a particular metric for a few sprints and evaluate whether it is paying off.

“Projects succeed when people are allowed to do their best work”

  • Defects tracking systems (DTS) are too often used as communication tools & entering unnecessary bugs can be wasteful. Focus on using DTS for the right reasons.
  • Whether your team decides to create a test plan or not, the planning should be done. Each project is different, so don’t expect that the same solution will fit all.
  • Regarding Audits, Processes & Models
    • Traditional quality processes & process improvement models like SAS 70 and CMMI standards can co-exist with agile.
    • Quality assurance teams in traditional development organisations are often tasked with providing information for auditors and ensuring compliance with audit requirements.
    • Examples include what testing has been performed on given software release or proving that different accounts reconcile.
    • Testers can be tasked with writing test plans to evaluate the effectiveness of control activities.
    • Work together with the compliance and internal audit teams to understand your team’s responsibilities.
  • If your organisation is using some kind of process model or quality standard, educate yourself about it and work with the appropriate specialists in your organisation.
  • Process improvement models and frameworks emphasize discipline and conformance to process.

“Standards simply enable you to measure your progress towards your goal”

  • Working with existing quality processes and models is one of the biggest cultural issues you may face as you transition to agile development. All of these changes are hard, but when your whole team gets involves, none are insurmountable.