By introducing continuous integration into the development cycle, project managers can potentially decrease software defects and development cycle times. Taking advantage of both, however, requires the team to create and adhere to proper acceptance criteria for each new code submitted. It's up to the project manager to ensure that developers and testers gather the detailed information they need at the outset of each new development project.
Continuous integration (CI) is practiced as part of an Agile approach to software development. It improves the efficiency, productivity and reliability of releases, enabling businesses to provide higher quality software at a faster pace. Developers integrate code often -- sometimes daily or even more frequently -- rather than at the end of a long development cycle. Each code commit triggers a battery of automated tests based on the preset acceptance criteria. Integrating code builds more frequently exposes defects earlier in the cycle.
It's common for developers to find defects when their new code is merged with the code base. Defects are often found and fixed before the new software code ever reaches the software testing team. Overall, software quality improves because the defects are caught early and aren't hanging out in a defect reporting system waiting to make a prioritized list or be discovered by end users.
Acceptance criteria on a story provide a lightweight version of simple, direct, specific and testable requirements.
Speedy release and deployment cycles don't necessarily improve quality if the acceptance criteria and testing are not planned or discussed. In a fast-paced development environment, it's difficult to add more testing, regardless of whether the type is automated or manual. The problem is not in the method of testing, but rather, it's in skipping the planning of the acceptance criteria.
Acceptance criteria on a story provide a lightweight version of simple, direct, specific and testable requirements. The details are not provided in their entirety because they are subject to change based on new developer discoveries or design changes. Developers and testers need enough detail to start a design discussion within the team so coding and test planning tasks can start. The purpose of a user story is to provide this detail. Adding acceptance criteria to each story also ensures quality remains in the forefront during development and testing.
It's the design conversations between the development team, product managers and testers that result in testable acceptance criteria. Software testers can improve the development team's discussion of acceptance criteria by encouraging focus on vague story descriptions and creating interest in the value of testing.
Getting customer-focused acceptance criteria through team planning
As a software test team member, you should actively participate in all planning and design meetings. One way to do so is to look at the existing user stories that are coming up and write a test prototype that includes acceptance criteria. Come up with testing workflows and stories through admissible means. Use a spreadsheet, matrix or text to create test scenarios for all the workflows that end users are expected to follow. Include an outline of what the test objectives are and what type of test is planned: unit, automated or manual. Make it a simple and concise test plan, and in a format the team can quickly review.
If a tester takes the initiative to pre-plan testing in a simple, easy-to-use format, then that paints a picture for other team members of the test team's understanding of how the function is going to work for end users. It also brings out any contradictions and misconceptions so the team can discuss them, and makes the tester an active participant in all phases of development rather than just the testing phase.
Testers can influence code design as equally as they test it. The goal isn't simply to make code pass unit tests. Real testing takes more than that. Testers must participate in and influence the development design by creating additional conversations and adding test plans to the acceptance criteria for each story.
Tackling vague definitions
In preparation for planning or design meetings, send out the testing prototype data at least a day in advance and bring it to the meeting. Prepare to discuss the test plan for each story to influence the design and document the acceptance criteria in a testable manner.
In a CI environment, testers need to plan tests ahead and have a prototype plan to achieve the most effective participation from development.
Focus the test prototype on specific workflows that are controlled by the team if possible. When the story is initially created, the details are often vague. In my team, that ambiguity creates a discussion on its own. This is an important time to discuss acceptance criteria as well. Most developers hesitate to think about testing or acceptance criteria before the software is designed, but this is actually the most efficient time to attract their attention and input. Without developer input, it's difficult to verify that the test plan covers all functionality.
When the presented test data includes that type of test, it creates another team conversation. The team can determine what type of test is the most valuable for each function. If the tester has thought through the test type and objective, it steers the conversation and breeds necessary developer involvement in reviewing test objectives. These objectives become expected results, which in turn frequently become acceptance criteria.
Creating interest in testing value
An effective method for drawing clarity and value from acceptance criteria is to make a prototype test plan. The format doesn't matter because it depends on the preferences of the tester and what developers will read. Ensure the test prototype is succinct and organized. Nothing derails participation in discussing testing and acceptance criteria faster than a disorganized presentation. Be prepared to confidently present the prototype test plan in an organized manner. If the conversation wanders, the audience will too.
In a CI environment, testers need to plan ahead and have a prototype plan in mind to achieve the most effective participation from development. Make it concise and valuable, but above all, make it count. Present the meat of the functionality as the tester plans to test it without wasting time, and get the team to formulate acceptance criteria from that conversation.
Taking the initiative to pre-plan testing in a simple, easy-to-use format creates participation both by the tester and within the development team. Testers need to actively participate in all phases of development and influence design by starting or creating design discussions. Put testing ideas out there in prototype form. It's quick, direct and will bring in the input needed from development. The tester becomes part of the design team and the team gets valid, workflow-based acceptance criteria that increases the quality of the software and improves user experience.
