Collaboration is one of the four main actions at the heart of the agile methodology. Alistair Cockburn, co-author of the Agile Manifesto, recently stated that he thought the agile methodology had become overly decorated. "Let’s scrape away those decorations for a minute," Cockburn said, and get back to the four actions that are at the heart of agile, namely, "Collaborate, Deliver, Reflect, Improve." According to Cockburn, each of these four words unpack into unendingly complicated skills, actions, tools, and so forth, but it's important to "fold back up all the nuance and complications ... and remind ourselves that these four words are at the heart/spirit/center of agile." Testing is an expertise dedicated to reflection and improvement, so it follows that agile testing, along with collaboration, make up the spine or backbone of the agile methodology.
The Heart of Agile
Image Source: Heart of Agile
In traditional waterfall testing and development there are typically several points in the process where work is handed off from one group to another. Developers hand off their work to other developers, or to a Quality Assurance department for testing, or to Operations for deployment. Such handoffs usually involve checklists and documentation. But these handoffs are risky. A lot can go wrong, including written or verbal miscommunication that leads to finger pointing, and when that happens the whole process grinds to a halt.
Agile methodologies, on the other hand, encourage information sharing across teams and departments within an organization. This enhanced communication leads to collaboration, or activities where team members work together rather than independently to accomplish a task or complete a project. Rather than teams working in stand-alone functional silos, agile promotes frequent, in-person interactions to foster collaboration. Collaboration can be a challenge on large-scale agile projects where team members work in a variety of global locations but, as we'll see, there are some collaboration techniques that work well for these large and distributed teams.
Agile testing isn't a role on agile teams, it's an activity that involves the all members of a cross-functional agile team. On agile teams, everyone is equally responsible for the quality of the product or the success of the project. This means testing is done by the whole team, not just designated testers or quality assurance professionals, including team members whose primary expertise may be in programming, business analysis, database or system administration. Team members whose expertise is in software testing or using a particular testing tool aren't limited to only doing that activity--they can also collaborate with customers or business owners on product requirements and work with other members of the team to develop high-quality code that fulfills those requirements.
This "whole-team" approach allows testing and coding to be done incrementally and interactively, building up each feature until it provides enough value to release to production. The kinds of testing methodologies agile teams are likely to use include the following:
Test-driven development (TDD)
Test driven development (TDD) is a 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 the 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.
Test-driven development
Image Source: Excirial
TDD 2.0: ATDD is an enhancement of TDD
Image Source: Testdrivendeveloper
TDD 2.0: Acceptance test driven development
Acceptance test driven development (ATDD) is an 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 provide quick feedback that requirements are not being met.
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.
TDD 3.0: BDD is another enhancement of TDD
Image Source: AndolaSoft
Behavior-driven development (BDD) is an extension of test-driven development 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 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
A brief example of a BDD feature in this format looks like this:
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.)
Another Collaborative Testing Approach
Not directly related to Test-Driven Development, Context-Driven Testing is another testing approach that promotes collaboration among cross-functional teams in much the same way that TDD does. Context-driven software testing is a set of values about testing rather than a test technique itself. To do context-driven testing means approaching each testing situation as if it were unique in important ways. Graduates of the context-driven testing school of thought follow these seven basic principles:
- The value of any practice depends on its context.
- There are good practices in context, but there are no best practices.
- People, working together, are the most important part of any project's context.
- Projects unfold over time in ways that are often not predictable.
- The product is a solution. If the problem isn't solved, the product doesn't work.
- Good software testing is a challenging intellectual process.
- Only through judgment and skill, exercised cooperatively throughout the entire project, are we able to do the right things at the right times to effectively test our products.
The importance of context-awareness when it comes to testing on agile projects is illustrated by comparing the testing that goes into the control software for an airplane versus the testing needed for software meant to capture early mindshare among teenage gamers. The caution, precision, repeatability, and double-checking of work on the first project is much greater than the second project, which has an impact on the quality and quantity of communication and collaboration on the two projects.
The Context-Driven Testing approach also considers testing more than merely output checking: each test executed by a tester is the product of a detailed, planned thinking process. In A Context-Driven Approach to Automation in Testing, James Bach and Michael Bolton also say the terms 'manual testing' and 'automated testing' are misleading:
To produce high-quality products and services, we need skilled people applying appropriate tools to fulfill the mission of testing. The common terms “manual testers” or “automated testers” to distinguish testers are misleading, because all competent testers use tools. Programmers and researchers use tools, too, but no one speaks of “automated programming” or “automated research.” No manager who calls for automated testing aspires to automate his management. The only reason people consider it interesting to automate testing is that they honestly believe testing requires no skill or judgment.
Context is also important when doing agile testing on large-scale agile projects (those that consist of more than a couple agile teams). Factors you need to consider include the degree of expertise each of the different agile teams have with the TDD, ATDD or BDD testing approaches mentioned above. You should be careful about trying to organize testing activity on large-scale agile projects by expertise, in much the same way it doesn't make sense to have developers in one location or time-zone and testers in another. Dispersing talent this way wastes time and blocks collaboration on cross-functional teams that work best with a diversity of roles and viewpoints. Utilizing a agile test management tool can be very helpful, if not necessary with these large projects.
Multi-team, geographically distributed projects also create a necessity for application lifecycle management (ALM) tooling that can manage and monitor all aspects of the agile testing process, such as
- Requirements Management
- User Story Management
- Test Case Management
- Defect Management
- Test Script Repository
ALM software can also help multiple teams collaborate and be more productive at activities like exploratory tests. which 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 that scripted testing, where test cases are designed in advance. Modern ALM software allows even the most circuitous test path taken by an exploratory tester during a testing session to be recorded and played back. This helps other team members recreate the defect and fix the bug.
Exploratory testing is important on agile projects since developers and other team members often get used to following a definite process (such as the those dictated by TDD, ATDD or BDD testing approaches) and can stop thinking outside the box. Because of the desire for 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. By encouraging reflection and improvement, exploratory testing make sure collaboration remains the backbone of agile testing--and at the heart of all your team's agile practices.
Learn more about the impact of agile practices by attending the upcoming session of Atlassian Summit 2016– How Agile and JIRA Software are Changing an US Government Agency.
Related Articles: