Agile Best Practices for Large-Sized Projects Agile Testing

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

Agile Development and Testing for Large-Sized Projects

  • Pair testing –In combination with the practice of involving testing practitioners as early as possible in the software life cycle, strongly consider pairing testing resources with developers to provide software quality advice and guidance during development. Combined with the practice of encouraging developers and testers to see themselves as software engineers, pair testing can be a particularly effective practice to improve the quality of delivered code. Where you do observe pushback 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 – The practice of continuous integration becomes increasingly valuable with a large team of developers writing and submitting completed code in parallel with the growing code base. A tool-based continuous integration solution should be adopted to automate the build process and also run other tools such as unit test, code coverage, and functional/regression testing tools to verify the quality of each build as it is generated. Combine continuous integration and automated build with innovative techniques for visualizing the results of a build, such as the red–green lava lamp solution described in(where a red lava lamp would come on if a build failed). Ensure all defects that are highlighted through this approach are fixed as soon as they are found to support the process of building defect-free software.
  • Test refactoring –For a large agile project, with a large team and a complex application, there is also likely to be a large and complex test suite. With good test management practices, the test suite may be well structured, perhaps involving subsuites linked to particular functional areas of the application under development, or associated with testing code developed within a specific iteration. However, if the test suite is not well structured, or there are difficulties in completing the regression testing within acceptable timescales, test refactoring must be considered. Removing tests2 that cover some aspect of the application under test that you have a high level of confidence in, or modifying existing tests, may improve the efficiency of the regression test. This practice should be combined with the practice if identifying targets of test.
  • 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. If you have a well-structured test suite–perhaps involving subsuites linked to particular functional areas of the application under development, or associated with specific iterations–it may be possible to simply leave a particular subsuite out of the current regression test(particularly if the tests are associated with a tried and trusted part of the application under test). More rigorous approaches are also possible for selecting the individual scripts to omit from any particular test, involving code coverage metrics and statistical calculations.
  • Code coverage metrics – When running a large test suite against a complex application under test, it is very difficult to have confidence that each and every code statement has been covered in the test, that all subroutines have been tested, or that all possible logical paths through a conditional statement have been exercised. The use of code coverage tools and the metrics they produce will give you an accurate picture of just how thorough your testing has been. Such tools can also be of value in assisting you to identify targets of tes. Combined with the automated build process and sophisticated graphical solutions for visualizing code coverage, this practice can quickly and easily highlight code coverage issues before they seriously impact the project.
  • Rapid prototyping – The practice of rapid prototyping can be of major value in a large agile project–exploring the customer requirements, gaining valuable feedback, and ensuring that the final system matches the customer needs. It is important to make sure that the prototypes are developed in such a manner that maximizes the reuse of the code in developing the final system; avoid wasted time and effort writing code that isn’t actually used in the final system. In a large agile other developers, who may be able to reuse the code in the completion of their tasks.

Agile Process and Project Management for Large-Sized Projects

  • Be sensitive to the reuse of traditional testing techniques–In large agile projects, with large(and potentially distributed)teams and involving complex software development, you must consider the value of reusing traditional development and testing techniques where appropriate. V-model[4], for example, is a tried and trusted solution to organizing testing plans that has been shown to have benefits when used in agile projects, and particularly when applied to test planning in longer iterations.
    Many agile methods reduce the number of testing phases used in a traditional test process(such as XP), but, depending on the project, it may be necessary to increase the number of testing phases. For example, in developing an application that needs to integrate and interoperate with other existing systems, you may have to consider introducing a systems integration test phase to ensure these requirements are properly tested.
    Similarly, with increasing project size and complexity, the benefits of traditional project and test management practices should be considered. For example elements of the PRINCE project management method[22] have been shown to have been of value in agile project management. Where you have very experienced testing staff involved in your agile project, be sensitive to any suggestions they may have about traditional practices that may benefit the current project.
  • Progress measurement –For large agile projects with large teams and extended timescales, the availability of accurate information on progress is of essential importance, particularly where timescales and budgets are likely to be tight and meeting planned milestones and delivery dates are critical. Add to this the likelihood that it may not be possible for the whole team to be co-located on a large project, and collecting and analyzing progress data quickly becomes a major challenge. While simple fifteen-minute stand-up meetings may be sufficient in small agile projects to discuss progress, such techniques can become unwieldy and inefficient in large projects. The role and use of tool support must be considered in large projects. While simple tools, such as spreadsheets, may provide a practical and inexpensive(in terms of tool acquisition costs) solution to collecting and recording estimates of the time and effort to complete a task and the actual time expended on the task, they must rely on timely and accurate reporting of progress and estimates for completion. Commercial products are available that automatically collect data on estimates and actuals as tasks are planned and completed. These products do not have to rely on the vagaries of optimistic or pessimistic estimates or on the need of the developer to submit these estimates; they can provide the project leader or manager with an accurate view of the state of the project in real time. Ensure that effective progress measurement is combined with effective methods for progress visualization.
  • Progress visualization – In addition to the importance of making project progress information available to the project leader, it is essential that all the stakeholders on the project have access to key project information. With increasing numbers of staff working on a larger agile project, and with the likelihood that not all of the stakeholders will be co-located, providing accurate and effective information to the team is challenging. Project and/or iteration burndown charts that are attached to the wall in a shared project area are unlikely to be effective under such circumstances, and more sophisticated means of sharing project data are needed.
    Consider publishing project information via the Internet or a local intranet, particularly if the tools that have been selected for use on the project have a web interface, which allows stakeholders to remotely access requirements information, for example. Other tools can be used that allow the setting up of a project portal, where customized views of project data can be displayed and could also be adopted as a means of delivering agile process guidance to the stakeholders. This is an area where thinking out of the box can bring significant results, such as the more unusual display methods described in the case studies, such as the solutions described by David Evans in his case study. that were used to show the quality results of the code integration process.
  • Availability of agile process guidance –A very significant number of the case studies point to agile project success being linked to the availability of welltrained, well-motivated, knowledgeable, and experienced agile practitioners. It may be a relatively simple task to obtain the small numbers of such individuals for modest-sized agile projects, but trying to staff a large agile project entirely with such super developers and testers would be both a major recruitment challenge and have serious cost implications for the delivery of the project(although it could be argued that a large project staffed entirely with the cream of agile practitioner-hood would be bound to complete early and under budget–if we ignore the issues of obtaining such a team in the first place). The reality on projects of any significant size is that they will almost certainly be staffed with a mixture of experienced practitioners and less-experienced staff. Also, over the course of an extended project, it is very likely that staff will leave or join the team fairly frequently. Under such circumstances care must be taken to ensure project staffing is organized in a way that ensures a good mixture of experienced and inexperienced staff on tasks, and to encourage skills transfer and mentoring. It is also critical to have good agile process guidance readily available to the team for reference and for skills enablement purposes. Effective solutions can be as simple as providing process guidance on ready reference sheets. Internet-based portal solutions can also be used to deliver process guidance to the team via web browsers. In large agile projects that are staffed with a high proportion of new or inexperienced agile practitioners and/or those that involve offsite or offshore teams, there may be value in using a process enactment–style product that provides a customizable agile development environment, and which itself embodies and enforces the principles and practices of whatever agile approach has been selected for use on that project.
  • Metrics–It is strongly recommended that a metrics scheme be set up and run for a large agile project. A metrics scheme can provide value to the project in a number of areas, including assisting with more accurate estimation, supporting process improvement, and feeding information to the project portal(or other means of distributing key project information). Given that there is already likely to be significant project activity associated with collecting information about estimates and actuals, productivity, defect detection rates, code coverage, and so forth, the additional effort expended in ensuring that this information is reused in a wider metrics scheme should not result in a large overhead. When deciding what metrics to collect, first make sure you are clear about the goals of the scheme and precisely what it is you intend to investigate or analyze, since this will guide your selection of data. Make sure that the effort expended collecting and analyzing the metrics is recorded in the metrics scheme(to determine how much time and effort it costs to run the metrics scheme). Review the benefits of the metrics scheme in the project retrospectives and challenge the value of continuing to run the scheme and, where appropriate, change how the scheme is run. Consider the role and use of tool support for the scheme, particularly if an existing product that is being used on the project can provide access to the data needed. contains comprehensive guidance on setting up and running a metrics program.
  • Reduce documentation overload –The time, effort, and cost required to compile, distribute, maintain, and make use of documents on a large project have significant implications for the agility of the project. Also, paper-based solutions are notoriously error-prone, involving the potential loss of critical project information. While daily stand-up meetings may be a solution to communicating information that might otherwise have been typed into memos and/or emails for small and even medium-sized agile projects, such techniques can become unwieldy and inefficient in large projects. Information that might, in traditional projects, have been recorded and distributed using paper-based solutions, such as project progress information, process guidance, and reports, can all be managed using appropriate tools. Requirements management tools provide a thorough and effective means of documenting and maintaining project requirements, while a web-based project portal can be used to provide real-time graphical displays of project progress and instant access to agile process guidance, as well as graphs, bar charts, and pie charts showing defect rates, code coverage, and metrics revealing where in the project life cycle the most defects are being detected.
  • Co-location of project stakeholders–Although this is the ideal option for organizing the team in small-and medium-sized agile projects, 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 other demands on her or his time. For those large projects with stakeholders that are offsite, effective solutions need to be found to ensure that they are able to communicate with other team members who are co-located as efficiently as possible. A range of solutions can be investigated, such as simple instant messaging systems; Internet telephony, with or without webcam technologies;full-blown videoconferencing facilities; or even use of Web 2.0 technologies, such as virtual project meetings in Second Life.

Agile Communication and Meetings for Large-Sized Projects

  • Improve interpersonal communications –Good interpersonal communication is vital to the success of large agile projects; but with increasing project size, larger teams, and the potential for some of the stakeholders to not be co-located for part or all of the project, maintaining effective communications becomes increasinglychallenging. In meetings and other project communication, techniques to encourage all members of the team to participate must be used; all members of the project have a valuable perspective and must be given the opportunity to contribute, and instances of where dominant personalities may hijack meetings or where knowledgeable but less extroverted individuals are prevented from contributing must be avoided. Similarly, when important issues need to be discussed, techniques for keeping all members of the team focused on the task at hand are key in facilitating larger meetings. Make good use of the communications techniques to significantly improve the quality and effectiveness of communications in large-sized agile projects.
  • Interim iteration meetings – For large-sized agile projects involving relatively long iterations, there is likely to be value in holding a meeting at the midpoint(or more frequently if the iteration is particularly long)to discuss progress, review risks and dependencies, and review outstanding tasks. This is particularly appropriate where one or more key stakeholders are not co-located but are able to make time to be present for such a meeting. One of the case studies also describes the benefits of scheduling such a meeting to coincide with another regular event or meeting so that particular staff can attend both events. On a Scrum-oriented project, this goal might be achieved through a Scrum of Scrums(in effect, a higher-level meeting where the attendees are representatives drawn from other Scrums). In particularly large Scrum projects, this might even be achieved using a Scrum of Scrum of Scrums.
  • Agile workshop meetings – As the project size expands, as team numbers grow, and as the complexity and duration of the project increase, there is likely to be a requirement for longer and increasingly formal meetings that involve more stakeholders. In RAD projects[18], joint application design(JAD) workshops are attended by customer representatives, developers, and project administrators and can last up to five days for particularly demanding tasks in large and complex projects. Where such meetings are necessary, the proposed duration of the event must be challenged to ensure it does not adversely impact project progress. Additionally, make good use of techniques to control the duration and focus of the meetings.
  • Agile project closedown meetings–For large projects with extended timescales and a large number of stakeholders, there may be significant value in holding a project closedown meeting above and beyond the end of iteration retrospective meetings. Such meetings 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.

Agile Automation for Large-Sized Projects

  • Tool selection process –On large-sized agile projects where significant use of automation is likely, or where an automation architecture is planned or in the process of being set up, it may be necessary to follow 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 had exposure to 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, as well as company guidelines on tool selection. Also, investigate what tool skills are available within the team; decisions involving the selection of a product that nobody knows about, in preference to one that members of the project team already have experience of using, should be challenged.
    Also challenge the use of open-source products; although their use may appear to offer cost savings, issues such as availability of support, experienced users, training, upgrade, maintenance, and scalability should all be considered in making any decisions about a particular tool. Similarly, the need for a particular candidate tool to integrate and interoperate with existing or planned products needs to be carefully considered. To save time and effort in evaluating products, and to adopt a formal rigorous approach, consider using the tools evaluation framework presented.
  • Static analysis tools – Strongly consider the use of a commercial static analysis tool to check the quality of the code generated in the project. For large projects with many developers, these tools can be used to ensure that a consistent approach to development is maintained. Examples of these tools exist that can also be used to verify that code conforms to project or company coding standards.
  • Test harness tools –In a large project there is likely to be a significant need to test software components that interact with other components that have not yet been developed. Under such circumstances, the use of test harness tools should be strongly considered. Although individual developers may generate their own test harnesses, to encourage standardization and reuse, you should strongly consider the use of the open-source test harness tools available to save the project time and effort and reduce cost.
  • Functional test tools – For larger agile projects involving many developers, with substantial code generation, and a complex application involving frequent builds and releases, there is likely to be significant value in using a capture–replay style functional and regression testing tool. Such tools are able to record the navigationand verifications employed in a manual test in the form of an automated test script that can be replayed against later builds and releases of the software to perform regression testing. Although they are of value to many projects, capture–replay tools are not the panacea for all software quality issues;they work best with reasonably stable software systems(where the user interfaces are not subject to frequent change), they should be used in combination with integrated requirements management and defect tracking solutions, and you should consider the value of using an integrated code coverage tool. Although such tools are valuable in allowing testing to be conducted in significantly shorter timescales than equivalent manual testing, and to support additional unattended testing of the software(overnight or over the weekend, for example), it is still possible on a large project for the test suite to grow sufficiently large to cause test execution performance problems. One of the case studies reported the use of an automated test suite that in the worst case could take up to ten days to execute! Under such circumstances, consider implementing the “identify targets of test practice” to reduce the size of the regression testing suite and to allow automated testing to fit into the required project timescales.
  • Requirements management tools –For large agile projects, with increasing team size, high complexity of the system being developed, and potential lack of collocation of key stakeholders, the use of an automated requirements management solution is essential. Bottom line–without formal tool support that provides rigorous traceability, it will become very difficult to ensure that the delivered system does what the customer actually requires of it. From a development and testing perspective, distributed requirements management tools allow the developers to understand what functionality needs to be implemented the customer requirements, and the tester to know what needs to be tested to ensure the implemented code meets the customers needs.
    In selecting a requirements management solution, ensure the tool integrates and interoperates with existing or planned products(and particularly change management and test management solutions). Where important stakeholders are unable to be co-located with the development team, ensure that the selected tool provides support for distributed requirements management. A number of such tools provide a web-based interface to allow distributed teams to inspect, use, and modify the requirements such a facility will be essential for offshore projects.
  • Build management tools – Such tools automate the process of generating a build, bringing together the units and components required to assemble the application under development. A number of the case studies describe the use of build management tools in combination with a continuous integration approach that incorporates automated unit test and functional test, and generates code coverage and complexity metrics. Used as a key component of an integrated tool architecture, automated build management tools can save projects significant time and effort and improve the quality of the delivered software.
  • Change management tools –With large and complex projects of extended duration involving large numbers of stakeholders(many of whom may not be colocated), the role and use of change management tools becomes critical. The role of robust and reliable commercial change management products, and particularly those with a distributed capability, must be considered for use in such projects. As with other tools, any candidates selected must integrate with other tools used on, or in, the process of being acquired for the project and should be selected with regard to possible company guidelines on tool acquisition.
  • Defect tracking tools –For large projects where substantial time, effort, and money are spent on software quality, it is essential that any defects that are found are fixed. Whatever defect tracking solution is employed, it should support a rigorous workflow that ensures that defects are highlighted to the appropriate stakeholders, that defects are fixed in a timely manner and retested, and that the fix is introduced back into the code base only after formal sign-off of the change by an authorized member of the team.Similarly, it is critical that defects reported by the customer following delivery of the software should be treated in the same manner, ensuring that they are fixed and that they do not appear in the next release(or later releases)of the software. Investigate the acquisition of a reliable and robust commercial defect tracking solution that integrates with the functional testing, regression testing, and test management tools already being used or planned for use on the project. Ensure that any such tool provides access for any stakeholder that is not co-located with the project team(this is a particularly valuable facility to provide to the customer–allowing defect reports to be submitted by the users, or a user representative, from their own site). Where a change management tool has already been introduced into a project, investigate whether it also supports a defect tracking solution.
  • 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 same process. Process enactment tools provide an integrated development environment that embodies and enforces the use of a particular agile best practice(good examples of such tools can be customized to support a particular agile method). In effect, the users are constrained to follow the specific agile practice selected for use on the project.
  • Such environments typically incorporate sophisticated facilities to promote effective communications across the project(which can include the offsite and offshore team members). Such tools can provide comprehensive support for metrics collection and use, with, for example, developer estimates and actuals that are captured in real time and which can enable the project leader to accurately report on project progress. Consider using process enactment tools in conjunction with solutions for making process advice and guidance available.

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

Agile Testing Topics