Foundation Agile Best Practices Agile Testing

The best practices documented in this section have been shown to have been used successfully in the majority of the case studies. These practices can be viewed as providing a solid foundation on which you can build your own agile process, by adding those practices from the following sections that best match your own agile requirements.

All agile projects should strongly consider the use of the following practices.

Agile Development and Testing

  • Iterative development – This fundamental agile practice is valuable from a software quality perspective because it allows testing to begin as early in the project as possible and to continue frequently throughout the project. In addition to allowing early and frequent testing, this approach also provides value in terms of allowing early versions of working software to be shown to the customer, obtaining valuable feedback, clarifying the requirements, and also managing the customers’expectations of the final delivered software.
  • Well-bounded iterations – Time boxing, sprints, and other techniques for bounding agile development tasks are tried and tested agile best practices. From a software quality perspective, it is recommended that the planned testing element of such iterations be strongly protected to ensure adequate testing occurs. In projects where the testing time within an iteration is habitually eaten into, strongly consider creating a ring-fenced iteration(such as a testing time box)explicitly for testing. Where appropriate, look to fit iterations into naturally occurring intervals, such as one-or two-week periods.
  • Early involvement of test resources –Look for opportunities to involve testing practitioners as early as possible in the project and continue to involve them throughout the project life cycle. For example, involving a testing analyst or designer in the process of generating use cases or user stories alongside the analyst and customer has been shown to be of significant value by allowing the test analyst to review the requirements for testability, to help ensure there are no errors in the requirements(such as duplications, omissions, or contradictions), and to create the test cases in parallel with the use cases and user stories.
  • Every day is test day –In addition to implementing practices to drive testing earlier into the project life cycle, encourage a culture that is aware of the need to test the code as frequently as is practical. Unit testing tools can be valuable in supporting this approach in the early stages of code development. In terms of looking for additional solutions to increase the amount of testing completed on the project, unit testing tools can be combined with continuous integration, build management, and capture–replay tools to allow testing to be run unattended(overnight or over a weekend, for example).
  • Test-driven design –In addition to being a key best practice in a number of agile methods(such as XP), the case studies have shown that where developers review the requirements and generate the unit test before coding begins, they gain a much clearer understanding of the requirements, produce better quality code, and don’t spend any additional time overall completing the task. In fact, because of the benefits of gaining a better understanding of the requirements and writing high-quality code, this practice arguably saves time and effort that otherwise might have been spent rewriting and retesting code containing defects.
  • Fix all defects immediately –A number of the case studies describe a practice in which, as soon as a defect is detected, all development halts while the defect is fixed. This approach has very significant benefits in terms of avoiding late detection of defects, and the cost and time-scale implications this has for the project. Combined with some of the practices allowing for the real-time visualization of the status of the project(such as the lava lamp solution covered later in this section) vfixing defects can become a matter of both urgency and pride, with the team working hard to achieve a “green lava lamp state” again.
  • Collective code and test ownership –Collective code ownership is another best practice that a number of the agile methods promote(such as XP). From a software quality perspective, a number of the case studies describe the benefits of the analogous practice of collective test ownership and its role in encouraging test refactoring(that is, all members of the team have the opportunity to modify contents of the test suite for the purposes of improving the quality of the tests and/or their efficiency). Where this practice is adopted, consider the role of change and configuration management tools to trace the changes and to allow changes to be undone where necessary.
  • Agile exploratory testing –This is a valuable addition to other testing practices being used on a project. An experienced test practitioner will frequently find defects that a developer or testing tool cannot, using their knowledge of the sort of errors developers often make(such as incorrectly coding logical boundary conditions), knowledge of how users often abuse systems(such as performing unexpected navigation or entering inappropriate values), and that mystical tester ability termed error-guessing.

Agile Process and Project Management

  • Co-location of project stakeholders –This fundamental principle of agile development and testing is the ideal solution for organizing an agile project team. Colocation of the project stakeholders supports the practices of early involvement of test resources, as well as pair testing and early test case design. Although an essential agile best practice, this approach becomes increasingly difficult to employ where team sizes become very large, or impossible where it is necessary for some of the team to be at a different site or even offshore.
  • Agile estimation –Estimation is a key aspect of agile projects, and methods for estimating project and iteration velocity are well understood and used. Although most projects employ estimation successfully, a number of the case studies reported issues with agile estimation and stressed the importance of employing previous experience;the most accurate estimates for any particular project are made with the assistance of metrics collected previously on that project. For example, metrics collection and analysis can help a project leader identify resources who regularly overestimate or underestimate the effort involved in a particular task.
    On larger projects, with longer timescales and/or the additional challenges of not having a co-located team, there may be value in employing automated distributed support for estimation.
  • Progress measurement –Typically calculated agile metrics such as velocity are a valuable source of information for stakeholders to be able to understand project progress. Many of the case studies also report the value of collecting and measuring a number of quality management metrics as well. Examples include test case coverage versus requirements, defect detection and distribution rates, code coverage, and code complexity metrics. The availability of such metrics can be used to improve the effectiveness of the testing process, such as identifying which aspects of the application are more prone to defects, which testers are most effective at finding bugs, and supporting the comparison and analysis of historical and current data.
    On the smallest agile projects with relatively simple tasks, daily stand-up meetings can be a particularly effective means of reviewing such data. With growing team sizes and increasing project complexity, more formal means of obtaining estimates of productivity and calculating progress are needed. While spreadsheets may provide a simple and frequently used solution to recording the estimates and actual effort needed to compete a task, larger and more complex projects may need to employ tool support to collate such data.
  • Progress visualization –Although it is important for the project leader to have access to accurate and up-to-date project data, there is also a great deal of value in displaying progress information to the wider project stakeholders. Examples of progress visualization solutions drawn from the case studies include traditional approaches such as pinning up project burndown charts in shared project areas and using distributed electronic data(such as the graphical code coverage and complexity information provided through the continuous integration and build solution described
    Visualization of project data means that the project stakeholders can make use of this information to make decisions about how to improve their performance. For example, in the case study described in , displaying a chart showing the breakdown of defects detected versus the testing phase in which they were found provided developers with the encouragement to improve the effectiveness of unit testing. Similarly, the automated switching on of the red lava lamp when a build failed due to detection of a defect provided a massive motivator for the team to fix the problem and get the green lava lamp back on before the red wax became hot enough to melt and flow!
  • Process improvement –While process improvement should apply to all agile projects, the scope of this activity will change depending on the size, duration, complexity, and importance of the project. For small projects, agile retrospectives held at the end of each iteration/sprint(and particularly heartbeat retrospectives may be sufficient. As project size, duration, and complexity grow, more formal approaches to process improvement may be appropriate; for large, longduration, and complex projects, or projects being run within an organization that has corporate interests in process improvement, a scheme such as CMMI might be employed.
  • Everyone is a software engineer –To avoid the adversarial mindset that is frequently reported between developers and testers, a number of the case studies reported the benefits of replacing the titles of those practitioners responsible for development and testing with the title of software engineer. This practice was shown to provide benefits in one of the case studies by improving productivity and lowering quality issues through closer working, and in another by encouraging those staff performing development tasks to seek out staff with quality assurance skills for advice. Combined with the notion that software quality is everyone’s responsibility, this practice can lead to significant improvements in the quality of the delivered software.

Agile Requirements Management

  • Use cases and user stories–Strongly consider having a test practitioner work alongside the analyst and customer during the process of requirements elicitation to review the requirements for testability, to help identify errors in the requirements, and to create the test cases in parallel with the use cases or user stories. Designing test cases based on use cases is a very natural process, because the use cases which describe a series of actions leading to a specific outcome map very easily into test scenarios, which specify the navigation that needs to be performed to produce some expected result.
  • Look beyond requirements to customer needs –This practice provides valuable guidance about what to focus on when trying to understand precisely what the customer needs. An overly formal approach to requirements elicitation may undercertain circumstances miss those aspects of the proposed software system that will deliver genuine value to the customer.Being aware that you cannot know all the customer requirements at the start of the project and adopting an approach in which you refine the customer needs at each iteration will help address this issue. The feedback obtained using a rapid prototyping approach may also help in further understanding the customer needs.
  • Ensure all requirements have tests –To ensure complete test coverage of the requirements, each requirement must have one or more associated tests. On smaller agile projects, simple tool support may be used(such as a spreadsheet that lists the requirements, with a corresponding column to show the associated test case). For larger agile projects that have access to requirements management and testing tools, you should look for integrated solutions that are able to map test cases back to specific requirements to demonstrate test coverage.

Agile Communication and Meetings

  • Agile project start-up meetings – Agile projects should begin with a start-up meeting in which issues such as the team structure, project planning, risks and dependencies, architecture,and product release planning are discussed and agreed. Ensure quality management issues such as testing roles and responsibilities, test planning, and test resourcing are also covered in this meeting.
  • Agile iteration start-up meetings –Each project iteration should begin with an agile start-up meeting, whose agenda should include a discussion of the priority of the features that should be implemented within the iteration, agreement on the iteration plan, discussion and agreement of the success criteria for the iteration, and identification of any iteration-specific risks and dependencies. On a Scrum project, for example, this is analogous to a sprint planning meeting.
  • Daily stand-up meeting –During the course of the iteration, the project team should get together for a short (typically fifteen-minute)stand-up meeting for the purposes of discussing three things:(1) what progress they made the previous day;(2) what they plan to achieve today;and (3) what issues, problems, risks, or dependencies might prevent them from achieving their plans.
  • Agile retrospectives –Retrospectives should be held at the end of each iteration to ensure that the lessons learned during that iteration are discussed and recorded. These could be as short and simple as heartbeat retrospectives, or more formal (perhaps following the guidelines provided in Ensure quality management issues are covered in the meeting, for example, by reviewing the success of automated testing tools, highlighting lessons learned in trialing some new testing technique, or reviewing how well testing plans were adhered to during the iteration.An agile retrospective should also be held at the end of the project to ensure that the lessons learned on the project are discussed and documented. This will be particularly useful if there are likely to be similar or related follow-on projects with the same customer.

Agile Automation

  • Automated unit test –From the analyses of the case studies, automated unit testing is a universally successful agile practice;all developers should be provided with access to automated unit testing tools(such as [50]). Such tools are simple to use, provide good results, and can be easily integrated into automated continuous integration and build solutions, where the unit tests can be automatically run to verify the quality of the code. For small-to medium-sized projects, free opensource unit test tools may well be suitable. For larger projects, review the needs of unit testing tools to integrate with other tools and/or test harnesses being used on the project and consider the purchase of commercial products if appropriate.
  • Automated configuration management –All agile development projects should consider the use of configuration management tools as a general best practice. For small- to medium-sized projects, free open-source configuration management tools may well be suitable. For larger projects, review the needs of configuration management tools to integrate with other tools being used on the project and consider the purchase of commercial products if appropriate.

Face Book Twitter Google Plus Instagram Youtube Linkedin Myspace Pinterest Soundcloud Wikipedia

All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd Protection Status

Agile Testing Topics