This section provides best practice guidance on the use of automated software tool support for agile methods. Automation has the potential to save significant time, effort, and cost on agile projects, but, where selected or used poorly, it can also cost a project time, effort, and money!
As Jon Tilt puts it, “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.”
In addition to quality management and testing products, this section discusses agile best practices relating to other tools such as requirements management, configuration management, build management, and process enactment tools.
Select a Tool in Haste, Repent at Leisure
Phillips reports that the agile project he worked on was forced to change tools several times during the course of the project; the time and effort needed to select a replacement tool, plus the nugatory effort expended on gaining familiarity with the previous tool, and wasted effort using it, can all jeopardize the success of an agile project, where the goal is typically to reduce the effort and cost of delivering the product.
Prior to starting an agile project there are a number of things you can do to try to avoid making poor automation decisions:
Static Analysis Tools
These products typically allow the source code to be inspected to highlight quality issues without executing the code(some are even customizable to allow company coding standards and house coding style issues to be detected). Arguably, these relatively simple but highly effective tools should be another tool in the developers’ toolbox and should be used on a frequent basis to check recently written or modified code.
As with many of the products discussed in this section, static analysis tools can be particularly effective when used in conjunction with an automated build and testing approach. For example, Evansdescribes a system that combines continuous integration and build management tools to automate the creation of a new build of the software. During this process, automated unit, functional, and static analysis tests are run against the code to determine whether the build is a success. Should the build fail due to defects being identified, the build s rejected, and the defects are corrected before rerunning the build process once more.
Automated Unit Test
The use of automated unit test tools(such as ) appears to be an agile practice adopted in almost every case study (Cassidy, Wilson, Kingston, Warden, Tilt, and Stapp and Nowakowska). These simple and effective tools allow unit tests to be compiled in concert with code development and executed to ensure the code meets its requirements and performs as expected.
Although a wide range of unit test products are available to purchase or download as open-source tools, many developers also write their own unit test tools. Whatever solution is adopted, you should take into account support issues, the availability of practitioners who are familiar with the tools, and the need to maintain and update these tools.
Combined with test harness tools (used where the unit under test needs to interact with components that have not yet been coded)such as mock objects(Cassidy, for example), automated unit tests provide an inexpensive and effective means of initially testing a component as well as continuing to test the successful functioning of the component following a new build, release, or other changes to the software(such as code refactoring).
Finally, employed in concert with continuous integration and automated build tools, automated unit tests become a highly effective solution to accelerate development through continuous code quality assessment.
Test Harness Tools
It is often the case, particularly in the early stages of development, that code will be written that needs to interact with other components that may not have been developed at that point in time. Under such circumstances a typical solution is to employ a test harness to simulate the operation of the missing component(s).
It is not unusual for developers to spend some of their time writing and testingtheir own test harnesses(or reusing those generated by colleagues). Although of value in supporting more efficient unit testing, creating these test harnesses inevitably expends time, effort, and expense in generating a temporary tool that almost certainly will not have any purpose once the current project is completed.
To inctivity of developers and to save them the time and effort of building their own test harnesses, a range of open-source test harness tools have been developed that are available for use in unit testing. Evans, for example, describes his experiences in using the so-called mock framework test harnesses and their role in automated build and test, while Cassidy describes how his project began by using a number of freely available mock frameworks(such as EasyMock and then went on to develop its own generic reusable mock framework–SevenMock.
Functional Testing Tools
Functional testing tools, such as the classic capture–replay tools, allow testers to capture user navigation against the application under test and any specific verifications(that a particular window has appeared, or some specific calculation has been made correctly, for example)in the form of an automated script. This script can be replayed against later builds or releases of the software to ensure the functionality has not changed and that the new changes have not introduced any bugs.
The benefits of the use of such tools on an agile project are clear:
A number of case studies report significant benefits from the adoption and use of capture–replay tools for functional and regression testing(such as Denning, Cassidy, Phillips, and Tilt,)and variously cite reductions in testing time, effort, and cost, as well as improvements in quality through their use.
However, such tools are not a universal panacea, and a number of case studies report issues with using such tools.Knowles, for example, reports that well-managed manual testing delivered excellent results on the migration project described in his case study. In this instance, capture–replay tools were rejected on the grounds that the solution was too expensive to maintain in a rapidly changing development environment, with high cost and effort involved in maintaining the scripts. Phillips cautions against underestimating the time and effort required to develop and maintain a test automation infrastructure and particularly one where the capture–replay tool has to be integrated with a number of other products.
The characteristics of those projects that seem to be particularly suited to the application of capture–replay tools are as follows:
As a final thought, if you combine the introduction of capture–replay testing tools with your metrics program, you will be able to work out the precise benefits obtained from using the tool and make an informed decision on whether it is of value to your project.
Requirements Management Tools
A number of the case studies report the benefits of using tools to document and maintain requirements(Kingston, and Chana, for example).
From a quality management perspective, the ability to provide up-to-date requirements information to test managers and test analysts for test planning and resourcing, and test case design purposes were commonly cited uses of such tools. Kingston makes a strong case for the use of such tools to demonstrate formal test coverage against requirements, while Chana describes the value of the change history supported by such tools in providing a useful source of traceability(allowing the persons who requested, reviewed, and authorized a particular change to the code base to be easily identified, for example).
Kingston makes a further point about the utility of such tools on agile projects where not all the stakeholders can be co-located; the ability for remote stakeholders to access the requirements tool via a web-based interface enabled the offshore staff to work more closely with other members of the team and allowed all stakeholders(irrespective of where they were based) to contribute to the requirements elicitation and documentation process.
Sewell and Hodgkinson both describe the value of automated support in requirements elicitation, specifically in documenting and analyzing use cases within the EssUP and RUP frameworks, respectively.
Build Management Tools
A large number of the case studies document the benefits of adopting a continuous build or integration approach(Gilb, Thomas, Knowles, Wilson, and Evans,).
Unless the project is of trivial size and complexity, a build management tool must be considered for use in starting and running the build process. Many of the case studies(such as Evans; Phillips, Wilson, and Tilt,)also report the benefits of integrating other automated tools such as unit test, functional test, and code analysis tools) with the build management tool to ensure that those builds that contain defects are rejected.
Configuration and Change Management Tools
Configuration and change management are well-established best practices in both traditional and agile software development projects, and many of the case studies report the value of using them(Thomas, and Cassidy, for example).
Numerous configuration and change management tools are available, including commercial products, open-source tools, and those developed in-house for example), that can be employed in agile projects. In selecting such a product, you should be aware of support issues, the availability of practitioners who are familiar with the tools, and the need to maintain and update these tools.
Finally, be aware of the need for the configuration and change management tools you select to integrate with other tools that you are already using on a project or those that are planned to be acquired.
Process Enactment Tools
A number of the case studies emphasize the importance of providing good process guidance to the stakeholders involved in developing and testing the software(Sewell, Kingston, and Hodgkinson, for example); if you want your agile project to be successful, it is essential that the practitioners working on the project understand and are able to employ agile best practices.
Several of the case studies also provide cautionary tales about projects that claimed to be following an agile approach, but which in reality were not using agile best practices(Thompson, Allott, May, for example). The reasons for this can be diverse:
There are a number of options for addressing these issues:
Agile Testing Related Interview Questions
|ETL Testing Interview Questions||Manual Testing Interview Questions|
|Selenium Interview Questions||Database Testing Interview Questions|
|Automation Testing Interview Questions||Software testing Interview Questions|
|Performance Testing Interview Questions||Embedded Testing Interview Questions|
|A/B Testing Interview Questions||Hadoop Testing Interview Questions|
Agile Testing Tutorial
Old-school Development And Testing
Agile Development And Testing
From Waterfall To Evolutionary Development And Test
How To Test A System That Is Never Finished
Implementing An Agile Testing Approach
Agile Testing In A Remote Or Virtual Desktop Environment
Testing A Derivatives Trading System In An Uncooperative Environment
A Mixed Approach To System Development And Testing: Parallel Agile And Waterfall Approach Streams Within A Single Project
Agile Migration And Testing Of A Large-scale Financial System
Agile Testing With Mock Objects: A Cast-based Approach
Agile Testing – Learning From Your Own Mistakes
Agile: The Emperor’s New Test Plan?
The Power Of Continuous Integration Builds And Agile Deve- Lopment
The Payoffs And Perils Of Offshored Agile Projects
The Basic Rules Of Quality And Management Still Apply To Agile
Test-infecting A Development Team
Agile Success Through Test Automation: An Extreme Approach
Talking, Saying, And Listening: Communication In Agile Teams
Very-small-scale Agile Development And Testing Of A Wiki
Agile Special Tactics: Soa Projects
The Agile Test-driven Methodology Experiment
When Is A Scrum Not A Scrum?
Analysis Of The Case Studies
My Agile Process
The Roll-out And Adoption Of My Agile Process
All rights reserved © 2018 Wisdom IT Services India Pvt. Ltd
Wisdomjobs.com is one of the best job search sites in India.