Agile Best Practices for Small-Sized Projects Agile Testing

The best practices documented in this section have been shown to have value when used on small 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 small projects.

Agile Development and Testing for Small-Sized Projects

  • Pair testing –where there are sufficient resources on the project, consider the value of pairing a testing resource with a developer to provide software quality advice and guidance during development. Be careful not to give the impression that the tester is performing a “quality police” role. This practice works particularly well if you have avoided the “us and them” issues often seen between developers and testers by encouraging these practitioners to view themselves as software engineers.
  • Continuous integration –Although this practice works particularly well where there are a number of developers writing and testing code, its value on smaller agile projects, perhaps used in combination with tool support, should also be carefully considered.
  • Rapid prototyping –Consider the role of this practice on small agile projects but ensure that, if used, the prototypes are developed in such a way as to maximize their potential reuse in developing any deliverable code produced as a result of the prototyping exercise;that is, be careful not to waste time writing code that isn’t actually used in the final system.

Agile Process and Project Management for Small-Sized Projects

  • Metrics –There may be some value on a small agile project in collecting simple metrics to support the analysis of quality management information, such as defect detection rates. Without having such metrics available, it will be very difficult to measure the benefits of any test process improvements one might make.
    Since the activity of collecting and analyzing metrics involves time and effort, the use of metrics on a small agile project must be carefully considered. In the event that collecting and using metrics is thought to be of value, any metrics scheme should be very clear about the purpose the metrics are being collected for and should be focused on collecting just the data required for that purpose. The benefits of any adopted metrics scheme should be reviewed during agile retrospectives.

Agile Communication and Meetings for Small-Sized Projects

  • Improve interpersonal communications –Even on small, co-located agile projects, effective interpersonal communication is essential to the success of the project. In fact, in small teams, poor communications problems can have a disproportionately high impact. For example, it is possible for one particularly forceful personality to dominate meetings. Similarly, it is quite possible for the least assertive member of the team to have the most important contribution to make but not be given the pportunity to make it! Make use of the communications techniques described in to significantly improve the quality and effectiveness of communications in small agile projects.
  • Interim iteration meetings –Although of more value in medium and large agile projects, in projects involving longer iterations, or where some important stakeholder cannot be co-located, there may be some value in holding a meeting midway through an iteration or at some other appropriate point(s) to review progress, review risks and dependencies, and/or discuss lessons learned. Reasons for holding such a meeting might include the availability of a particular stakeholder(such as a non-co-located project sponsor) at a specific point in the iteration, the occurrence of some event external to the project that may impact project progress, or the detection of some significant risk or dependency that needs to be reviewed. However, the scheduling of additional meetings should always be challenged on a smaller agile project, since it is quite possible that the daily stand-up meetings will be sufficient.
  • Agile project closedown meetings/extended retrospectives –Consider holding a brief agile project closedown meeting if there are outstanding items not covered in the agile retrospective. If this is likely to be the case, consider combining the retrospective and closedown meetings into a single meeting that includes the agenda items from both.

Agile Automation for Small-Sized Projects

  • Role of static analysis tools –Consider the use of one of the open source static analysis tools that are available to check the quality of the code generated in the project. These tools can be used to detect issues or errors in the code that need to be addressed prior to execution, with a number of these tools also capable of being customized to check project or organization issues, such as adherence to a particular coding standard or company style.
  • Test harness tools –Where a significant need exists 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 tools that may have been developed in-house, there are a number of free test harness tools available that can save the project time and effort.
  • Requirements management tools –The majority of small agile projects employ simple, cheap(or free) solutions to record and use project requirements; very often, a simple spreadsheet will suffice. Where more rigor is required on a project–to formally document a customer’s requirements or to be able to trace the origin of some specific requirement, for example–a more robust and reliable solution many be required. The use of a commercial requirements product should be considered carefully on a small agile project, because such tools may need to be purchased and, even where free, are likely to incur training and familiarization costs.

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

Agile Testing Topics