This is a guest post by Sanjay Zalavadia, VP of Client Services at Zephyr, a leading provider of on-demand, real-time enterprise test management solutions and maker of 7 add-ons in the Atlassian Marketplace.
A good agile product development manager knows that you can’t separate coding from testing. Because agile methodologies are iterative, testing and coding are done incrementally and interactively so that features can evolve in response to changing customer requirements.
Agile testing comes in many shapes and sizes and covers all types of testing, including unit, functional, load, and performance tests. Depending on what type of agile testing you’d like to do: from automated, to manual, and everything in between, there are different test types you can choose from. How can you choose which type of test to perform and for what benefit?
The 4 agile testing quadrants
Agile expert Lisa Crispin developed four Agile testing quadrants as a guide for managers and development teams to use to create test strategies. It’s important to realize that the Agile Testing Quadrants diagram is simply a taxonomy to help teams plan their testing and that there are no hard and fast rules about which tests belong in which quadrant and in which order the different tests need to be done. (For example, it’s not necessary to work through the quadrants from Q1 to Q4 in a waterfall style.)
- Quadrant Q1: These are technology-facing tests that guide development, such as Unit tests, API tests, Web Services testing, and Component Tests that improve product design. Tests in Q1 are often associated with automated testing and continuous integration.
- Quadrant Q2: These are business-facing tests that guide development, such as those used for Functional Testing, Story Tests, Prototypes, and Simulations that make sure your software products are properly aligned with the business. Tests in Q2 are often associated with both automated and manual testing.
- Quadrant Q3: Tests in quadrant 3 are business-facing tests used to evaluate or critique the product. Q3 covers tests such as exploratory testing, scenario-based testing, usability testing, user acceptance testing, and alpha/beta testing and can involve product demos designed to get feedback from actual users. Tests in Q3 are often associated with manual testing.
- Quadrant Q4: These are technology-facing tests used to evaluate or critique the product. Q4 covers tests such as performance, load, stress, and scalability tests, security tests, maintainability, memory management, compatibility and interoperability, data migration, infrastructure, and recovery testing. These tests are often automated.
How to choose which test to use
Crispin’s four quadrants are based on Brian Marick’s Agile testing matrix, which makes a distinction between tests that are either business facing or technology facing. A business-facing test is one you can describe to a business expert in business terms, such as, “if your user’s account is overdrawn, will the system add a service fee?” A technology-facing test is one that uses language that developers might understand, such as, “PersistentUser#overdrawn adds service fee.”
Marick also recognizes a difference between tests that support the development team or critique the product. By tests that “support the team,” he means tests like component or unit tests where testable parts of an application are individually and independently scrutinized for proper operation. Tests that “critique the product” are those that are not focused on the development process but look at inadequacies in the finished product, such as not fulfilling a business requirement.
The division of tests into quadrants allows teams to strategize whether they have the right skills to accomplish each of the different types of testing, or if they have the necessary hardware, software, data and test environments. It also makes it easier to customize your agile testing process on a project-by-project or skill-by-skill basis. So, for example, if you don’t have a tester on your QA team with appropriate load or performance testing skills, it helps you see the need to bring in a contractor or outsource that particular test. A testing strategy based on the Agile Testing Quadrants requires effective team communication and collaboration, which a tool like Jira can facilitate.
Each time team members create an issue in Jira the input is instantly recognized and synchronized with associated relevant information. Jira’s synchronizer thereby communicates issue updates among team members in real time. Team members who are directly tied into specific issues, as well as the team at large, can view requirements for item updates and how those requirements affect the project.
To facilitate project communication among team members, Jira:
- Profiles and defines user-targeted tasks and projects
- Maps issues, fields, and values
- Smoothly exchanges and distributes associated information
The Jira platform enables and expedites task and project communication in agile software development, requirements management, project management, automated test management, release management, coding integration, reporting, and the software life cycle.
Agile teams have to produce working software at the end of the day, and there are several ways they can monitor the status of each of their development cycles, which are usually measured in one- or two-week increments. While it’s possible to keep track of the status of an iteration via daily standup planning meetings or group emails, agile teams that use Jira have access to burndown charts and other ways to track progress in each iteration.
A burndown chart is a plot of work remaining to reach a given goal on the vertical axis, and time on the horizontal axis. Each point on the chart shows how much work is left to do at the end of that day (or week, month or other time period). A burndown chart typically has a line that runs diagonally from the top left to the bottom right corner that represents the estimated rate of work or “burn” needed to reach the goal. If the line that shows the actual work done on the project is above the estimation line, the project is behind schedule. If the actual line is below the estimation line the project is ahead of schedule.
If your project has substantial scope change – where work is added to or removed from a project – you should consider using a burnup chart, which tracks completed work and total work with separate lines. Apart from burndown charts, there are a host of other options available in Jira for representing the progress of your agile project, such as sprint reports, epic reports, version reports, velocity charts, control charts and cumulative flow diagrams.
Maintaining agile focus
As useful as the functionality of Jira is in managing agile projects, it’s important to stay focused on agile values, namely:
- Individuals and interactions over processes and tools: In QA, it can be easy to prioritize testing tools and following procedure over in-person team collaboration. Through collaborative communication teams can discover incompatibility issues; more quickly and effectively devise and discover debugging solutions, and remove process clutter.
- Working software over comprehensive documentation: Documentation is essential within the QA process, but incessant documentation diverts valuable time from team members and is easily outdated. Software shared among QA, development, and IT organizations can supplant extensive historical documentation, leaving QA teams free to document elements and processes that contribute value without impeding production progresses. Focus on documenting systems and results, rather than processes.
- Customer collaboration over contract negotiation: Collaboration requires that teams and team members talk to customers, listen to customer feedback, and engage customers in listening to team considerations. Especially in the test configuration phase, contact must be a continual conversation to detect and pinpoint issues before they can block or deter operations.
- Responding to change over following a plan: The agile value of responding to change provides QA teams with essential tools for test module configuration and testing cycles. Using test management principles within automated test operations allows that individual test cycles be segmented out for quick and smooth response to change. Acknowledging response to change over following a plan enables QA production to remain relevant within the software market.
In an agile development environment, testing has to be integrated throughout the entire development lifecycle. Excellent communication among the project manager, business analysts, developers and testers is crucial to the success of an agile project, especially so in teams that work in different time zones and physical locations. Jira makes this communication easier by helping agile teams organize issues, assign work, and follow the progress of each software iteration.
Being agile means doing what you need to do to get the job done.
Use the Agile Testing Quadrants above to decide on the right combination of manual and automated testing that works best for each project you’re working on. Since manual testing often requires a tester to play the role of an end user and use most or all features of an application to ensure it behaves correctly, you should focus on automating as many repetitive tasks as possible. Test automation is critical if your goal is to build an agile DevOps culture capable of continuous testing and continuous delivery of high-quality software.
Learn more about how Jira assists globally distributed teams foster collaboration by attending the upcoming session of Atlassian Summit 2016– ‘Xero-ing in’ on Global Collaboration During Hyper-Growth.