The Ultimate Guide to Agile Testing for Modern Software Teams: Part 2

In The Ultimate Guide to Agile Testing for Modern Software Teams: Part 1, we looked at the agile testing life cycle, agile testing quadrants,

In The Ultimate Guide to Agile Testing for  Modern Software Teams: Part 1, we looked at the agile testing life cycle, agile testing quadrants,

In The Ultimate Guide to Agile Testing for  Modern Software Teams: Part 1, we looked at the agile testing life cycle, agile testing quadrants, and agile methodology in testing. In Part 2, we’ll go more into the agile testing process and check out agile testing methods, agile testing tools, agile test automation, and more!

Let’s look at other agile testing methods in modern software development.

Agile Testing Methods

As mentioned earlier, test-driven development (TDD) is an agile programming technique that requires developers, before they write any unit of code, to write an automated test for that code. Writing the automated tests is important because it forces the developer to take into account all possible inputs, errors, and outputs. 

• TDD allows an agile team to make changes to a project codebase and then quickly and efficiently test the new changes by running automated tests. 
• The result of using TDD is that agile teams will accumulate a comprehensive suite of unit tests that can be run at any time to provide feedback that their software is still working. 
• If the new code breaks something and causes a test to fail, TDD also makes it easier to pinpoint the problem and fix the bug.

Behavior-Driven Development (BDD)

Behavior-driven development testing (BDD) is an extension of test-driven development (TDD) that encourages collaboration between developers, QA, and non-technical or business participants on a software project. It extends TDD by writing test cases in a natural language called Gherkin that non-programmers and domain experts can read. 

BDD features are usually defined in a GIVEN WHEN and THEN (GWT) format, which is a semi-structured way of writing down test cases. A BDD feature or user story needs to follow the following structure:

• Describe who is the primary stakeholder of the feature
• What effect the stakeholder wants the feature to have?
• What business value the stakeholder will derive from this effect?
• Acceptance criteria or scenarios:
    Feature: Items on abandoned shopping carts should be returned to inventory
    In order to keep track of inventory
    As an on-line store owner
    I want to add items back into inventory when an on-line shopping cart is abandoned.
    Scenario 1: On-line shopping cart items not purchased within 30 minutes go back into inventory
    Given that a customer puts a black sweater into his shopping cart
    And I have three black sweaters in inventory.
    When he does not complete the purchase with 30 minutes (i.e. abandons the shopping cart)
    Then I should have four black sweaters in inventory

In TDD, the developers write the tests while in BDD the automated specifications are created by users or testers (with developers writing the underlying code that implements the test.) A key BDD best practice is to use, a collaborative approach to define the requirements and business-oriented functional tests for software products based on capturing and illustrating requirements using realistic examples instead of abstract statements.

User stories, which we described earlier, are used in agile development to help shift the focus on software projects from writing about software requirements to talking about them. User Stories aren't formal documents in the way traditional requirements are. They’re intended to be placeholders for conversations among the stakeholders on a project to get agreement on acceptance criteria for a particular piece of functionality. 

The Three Amigos

Another best practice to encourage this kind of conversation about functionality is to use "Three Amigos" meetings that involve a product owner (or a business analyst), a developer, and a QA tester, who get together (either face-to-face or online) to review the requirements, tests, and dependencies of a feature request on the backlog.

Acceptance Test Driven Development

Acceptance test driven development (ATDD) is another enhancement of test-driven development that promotes collaboration between business users, testers, and developers to define automated acceptance criteria before coding has begun. 

ATDD and TDD are complementary techniques: 

• ATDD helps describe the high-level business objectives, while TDD helps developers implement them as requirements. 
• ATDD helps ensure that all project members understand what is being implemented since failing ATDD tests provides quick feedback that requirements are not being met.

Although they don’t have to be written in the Gherkin language used on BDD projects, User Stories on ATDD projects should be well-defined. A best practice for doing this in a "Three Amigos" meeting is to follow the "3 C's" formula, devised by Ron Jeffries, that captures the components of a User Story:

1. Card – stories are traditionally written on notecards, and these cards can be annotated with extra details
2. Conversation – details behind the story come out through conversations with the Product Owner
3. Confirmation – acceptance tests confirm the story is finished and working as intended

A key part of ATDD tests is that they are run automatically whenever a change is made to the source code. In addition to testing the application, automated acceptance tests are useful in measuring the progress your project team is making since, on an agile project, working software is considered to be the only objective measure of progress.

Exploratory Testing

There are many exploratory testing methods. Exploratory tests are tests where the tester actively controls the design of the tests as those tests are performed and uses information gained while testing to design new and better tests. 

• Exploratory testing is done in a more freestyle fashion than scripted testing, where test cases are designed in advance. 
• Exploratory testing is important on Agile projects since developers and other team members often get used to following a definite process (such as those dictated by TDD, BDD, or ATDD testing approaches) and can stop thinking outside the box. 
• Because of the desire for fast consensus among self-organizing Agile teams (even globally distributed ones), collaboration can devolve into groupthink. 
• Exploratory testing combats this tendency by allowing a team member to play the "devil's advocate" role and ask tough, ‘what if’-type testing questions.

Example of Exploratory Testing

An example of exploratory testing on an online shopping website would test the following functionality from the perspective of an end-user (in any order the tester chooses): Login, List of Products, Loading and Unloading of a Shopping Cart, Payment Processing, Order History, and Product Shipment.

When is Exploratory Testing Useful?

Exploratory testing is especially useful in complex testing situations when little is known about the product, or as part of preparing a set of scripted tests. The complexity of modern applications makes it difficult for prescribed manual or automated tests to find all of the edge cases needed to fully capture your end user’s experience. Exploratory testing excels in allowing non-testers to go through an application and provide clear, captured, annotated data for your team to replicate any issues that are found.

Because exploratory testing is a time-consuming process, a best practice requires the Project Owner to budget enough time so that the tester can understand the business requirements and the purpose of the app being tested. Testers should also use testing tools and other resources that can help document any bug found clearly and concisely so that developers can recreate and fix the bug. Exploratory testing is best done in a collaborative environment where testers work closely with developers.

Session-Based Testing

Session-based testing is a type of structured exploratory testing that requires testers to identify test objectives and focus their testing efforts on fulfilling them. Test sessions differ from test cases in two ways: First, more than one test can be carried out in a single session. Second, like test cases, test sessions can tell you who tested what, but they can also tell you how, when, and why the tests were done.

Pre-written test scripts can be run during a session, but because test sessions emphasize test objectives over specific test cases, testers are encouraged to