Agile Best Practices for Medium-Sized Projects Agile Testing

The best practices documented in this section have been shown to have value when used on medium-sized agile projects. Combine the agile practices documented in the following sections with those described in Section to provide a set of best practices for use on medium-sized projects.

Agile Development and Testing for Medium-Sized Projects

  • Pair testing –With increasing numbers of staff on the project, there is increasing value in pairing a testing resource with a developer to provide software quality advice and guidance during development. This practice will work particularly well if you have adopted the approach of encouraging developers and testers to see themselves as software engineers, avoiding any “us and them” issues. Where you do observe push-back from developers who perceive the tester as being a member of the “quality police,” consider involving the test resource in a reviewing role toward the end of the workday.
  • Continuous integration –As the number of developers on the project team increases, this practice becomes increasingly valuable with individual developers submitting completed code to the growing code base. Using tool-based continuous integration, it is not only possible to automate the build process, but it is also possible to automatically run other tools, such as unit test, code coverage, code complexity, and functional/regression testing tools.Combined with innovative techniques for visualizing the results of a build, such as the graphical code coverage and complexity information provided through the continuous integration and build solution described and the practice of fixing all defects as soon as they are found, this becomes a highly effective and efficient means of building defect-free software.
  • Test refactoring –Where the testing suite becomes large and complex, difficult to manage, and/or takes an unacceptably long time to execute, you should consider the value of test refactoring. Removing test scripts from the test suite (but not deleting them, so that they can be reused later in the project if required) and/or editing or modifying them can result in a leaner, meaner, and more effective test suite. Care must be taken to target only those tests that are no longer being used, that are out of date, or that test low-risk or tried-and-tested elements of the code base. Combined with the practice of identifying targets of test, test refactoring provides a valuable solution for improving the efficiency of your test effort.
  • Identify targets of test –In the event that the suite of test scripts becomes sufficiently large that there are difficulties in completing functional and regression testing within allocated timescales, you should consider the use of this practice to assist you in selecting an effective subset of tests to run that will still provide you with good results from a quality perspective. provides excellent advice and guidance on this best practice.
  • Code coverage metrics –Consider the use of this practice as part of the process of ensuring good test coverage of the software. Where there are large numbers of tests to run and the application under test is large and/or complex, you should consider the use of a code coverage tool. Such a tool can also be of value in assisting you to identify targets of test(see previous section)as well as assisting you to target additional testing effort in those areas of the software where more thorough testing is needed. Combined with the automated build process and sophisticated graphical solutions for visualizing code coverage described.
  • Co-location of project stakeholders – Although co-location is the ideal option for organizing the team in a medium-sized agile project, as the team size grows, ensuring their co-location becomes increasingly challenging. This will be particularly true where the customer representative is an important individual whose time is valuable and who has commitments involving them in other roles outside the agile project. Where it is not possible to ensure all members of the team are co-located, other strategies for improving communications should be considered.

Agile Communication and Meetings for Medium-Sized Projects

  • Improve interpersonal communications –Good interpersonal communication is essential to the success of agile projects, but with increasing project size, larger teams, and the potential for some of the stakeholders to not be co-located for part of the project, maintaining good communication becomes increasingly challenging. During meetings and in other project communication, techniques to encourage all members of the team to participate must be used, because all members of the project have a valuable perspective and must be given the opportunity to contribute. The communications techniques described can all be used to significantly improve the quality and effectiveness of communication in medium-sized agile projects.
  • Interim iteration meetings –For medium-sized agile projects there may be value in holding a meeting midway through an iteration to discuss progress, review risks and dependencies, and review outstanding tasks. This would be particularly appropriate where one or more key stakeholders are not co-located but could make time to be present for such a meeting. One of the case studies describes the benefits of scheduling such a meeting to coincide with another regular event or meeting to enable particular staff to attend both events. On a Scrum-style project, this goal might be achieved through a Scrum of Scrums in effect, a higher-level meeting where the attendees re representatives drawn from other Scrums), scheduled at some convenient point during the iteration.
  • End-of-iteration retrospective –These longer meetings(of up to four hours’ duration) provide an opportunity for the team members to reflect on what worked well in the iteration, what could have been done better, and to document the lessons learned as part of the task of process improvement. Ensure that quality management topics are on the agenda at such meetings and that effective communications techniques are employed.
  • Agile workshop meetings –As the project size expands, team numbers grow, and the complexity and duration of the project increases, there is likely to be a requirement for larger and more formal meetings. For example, RAD includes the notion of the joint application design workshop, which is attended by customer and developer representatives, chaired by a facilitator, and documented by a scribe. While such workshops can last up to five days for particularly demanding tasks in large and complex projects, clearly the smaller the agile project, the greater the drive for more focused meetings of shorter duration.The role of such workshops in medium-sized projects can be of significant value as an intensive means of discussing and documenting an important aspect of the project, but their duration must be challenged in order to ensure they do not adversely affect project progress. Techniques exist to focus the meetings(such as the fifteen-minute and 80/20 rules, and these can be used to ensure such meetings do not exceed the time allocated to them.
  • Agile project closedown meetings –With increasing project size and growth in team numbers, there may be significant value in holding a project closedown meeting above and beyond the end of iteration retrospective meetings. An agile closedown meeting can be of value by allowing the lessons learned from earlier iteration retrospectives to be collated, providing an overall project perspective on what worked well and what could be improved. From a Scrum perspective,such a meeting could be supported using a Scrum of Scrums approach, with one or more representative from each retrospective providing their input on the key lessons learned. Ensure quality management issues are covered in the meeting, such as 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.

Agile Automation for Medium-Sized Projects

  • Tool selection process–For those medium-sized agile projects where there will be significant requirement for the use of automation, it may be necessary to undertake a formal tool selection process. This process should be as lightweight as possible and could rely heavily on the previous experience of the team members, who may already have preferences for particular tools. Any tool review, evaluation, and selection process must take into account the integration and interoperation needs of other tools already selected or in the process of being selected for use on the project.
  • Although open-source products may be acceptable on small-sized agile projects, their use may need to be challenged on medium- or large-sized projects. In particular, issues such as availability of support, experienced users, training, upgrade, and maintenance should all be considered when making any decisions about a particular tool. Company standards and guidelines on tool selection and use may also need to be considered. Jon Tilt offers this advice on tool selection:
    There is always the temptation to architect yet another automation framework at the start of the project. Don’t! Look around at the simple tools that already exist and build on them as required. Developers and testers are much more likely to use something simple that is quick and easy to use.
  • There may be some benefit in terms of reduced time and effort in using the tools evaluation framework.

  • Static analysis tools –While the use of one of the free static analysis tools should be considered to check the quality of the code generated in the project, the use of more professional commercial static analysis products should also be investigated, particularly if the tool needs to integrate with any existing or planned tools in use on the project.
  • Test harness tools –Where there is a significant need to test software components that interact with other components that have not yet been developed, the potential use of test harness tools should be considered. In addition to those tools that may have been developed in-house, there are a number of free test harness tools available hat have been reported to save the project time, effort, and money.
  • Functional test tools –For small agile projects it is likely that the volume of functional and regression testing can be satisfied using a manual test approach. As the project size increases, it may still be possible to manage the increasing manual testing load using good test management techniques(such as reusable test scripts and test packs). At some point, however, when the duration needed to execute the manual test suite no longer fits into the planned timescales, when there are frequent builds and releases of the software, and/or when the maintenance of the manual test suite becomes an issue, it may be necessary to consider the use of a commercial capture–replay tool. Such tools record the navigation and verifications employed in a manual test in the form of an automated test script that can be replayed against later builds and releases to perform regression testing
  • Requirements management tools –Although small agile projects may be able to employ in-house or open-source requirements management tools, medium-sized projects are more likely to require an increasingly rigorous, robust, and reliable solution. A number of commercial products are available that provide facilities for documenting, utilizing, and maintaining project requirements. In selecting such a product, be aware of company standards and guidelines, the knowledge and advice of colleagues, and the need for the tool to integrate with existing or planned project tools. For example, a requirements product may need to integrate with a test management tool for test planning and design purposes.
  • Build management tools –Build management tools automate the process of generating a build, bringing together the units and components required to assemble the application under development. Used in combination with a continuous integration approach and potentially incorporating automated testing, these tools can provide a powerful solution to building and testing the software being developed. While the use of one of the open-source build management tools may be an option to consider in relatively small agile projects, as the project size, number of developers, and complexity of the software increase, there is a growing need to consider employing one of the more robust and reliable commercial build management tools.
  • Change management tools –Where agile teams are relatively small and colocated, simple communications between the stakeholders may well be sufficient to ensure that requests for changes to the software being developed are implemented. With increasing team size, complexity of the system under development, and potential lack of co-location of key stakeholders, the role and use of a change management tool becomes more compelling. On small agile projects, in-house or open-source configuration management tools may be an option, but as the project size increases, the use of more robust and reliable commercial products needs to be considered.
  • Defect tracking tools –Having spent significant amounts of time, effort, and money tracking down bugs in the software, it is essential that these defects get fixed. Similarly, when customers report defects in the software following its release, it is important that these are fixed by a patch or in the next release of the software. To ensure the formal logging of defects, their correction, and retest, some form of defect tracking mechanism must be employed on the project. In a small agile project with co-located stakeholders, which employs an approach where all defects are fixed immediately, the use of a commercial defect tracking tool may be unnecessary. However, as project size increases–with growing numbers of developers and testers, a large code base, and corresponding defect reports–a rigorous commercial solution will become increasingly necessary. Often, change management tools will also be used for defect tracking(since a defect is arguably a special case of a change request). Whatever defect tracking solution is selected, ensure it integrates with the functional, regression testing, and test management tools already being used or planned for use in the project.
  • Process enactment tools –For larger agile projects, particularly those involving new or inexperienced agile practitioners or where project stakeholders are distributed across a number of separate sites or even offshore, it may be a challenge to ensure that all stakeholders follow the chosen process correctly. Process enactment solutions provide an integrated development environment in which the users are constrained to follow agile practices. Such environments typically incorporate sophisticated facilities to promote effective communications across the project(which can include the offsite and offshore team members). Developer estimates and actuals can also be captured in real time to enable the project leader to accurately report on project progress.


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

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

Agile Testing Topics