A Sophisticated Study on Best Practices of Agile Software Testing

Size: px

Start display at page:

Download "A Sophisticated Study on Best Practices of Agile Software Testing"

Janice Parker
6 years ago
Views:

A Sophisticated Study on Best Practices of Agile Software Testing Harish R Madhu B K Lokesha V GSSIT, Bangalore, GSSIT, Bangalore, Acharya Institute of Technology, Karnataka, India Karnataka, India

1 A Sophisticated Study on Best Practices of Agile Software Testing Harish R Madhu B K Lokesha V GSSIT, Bangalore, GSSIT, Bangalore, Acharya Institute of Technology, Karnataka, India Karnataka, India Bangalore, India harish22011@gmail.com madhubkrishna@gmail.com lokiv@yahoo.com Abstract-From the time procedure is penned for an development process, its best practices and easy way to implement those practices are discussed and optimized. In recent years many Software development life cycles are introduced and their best practices are discussed and studied empirically. Agile software testing being most adopted in software product development process emerged as an solution for efficient solution to test in Agile frame work. It derived and explained that automation testing is best suited for Agile Software testing technique. In this paper a complete study is made on the procedure of Agile Software Testing explaining its various stages. Also the procedure for Agile Software Automation Testing and its best practices to be followed to deliver optimal working product to the customer is discussed. Paper includes best practices to consider before implementing automated software testing. These best practices are strategic and are applicable regardless of the automation tool you use giving a clear path to test Software Product in Agile development process. Keywords- Agile Software Testing (AST), Agile Software Automated Testing I. INTRODUCTION Agile Software Testing is an independent and distinct part of Agile Software Testing Framework [1]. Figure 1 depicts the agile frame work procedure. The term 'Agile Software Testing' is a philosophy and is a conceptual framework for undertaking software engineering projects. Most Agile Software Testing methods attempt to minimize risk by developing software in short time boxes, called iterations [2]. Each iteration is like a miniature software project of its own, and includes all of the tasks necessary to release the mini increment of new functionality: planning, requirements analysis, design, coding, testing, and documentation. While an iteration may not add enough functionality to warrant releasing the product, an Agile Software Testing software project intends to be capable of releasing new software at the end of every iteration. Agile Software Testing methodologies address the needs Figure-1: Framing Agile Process of the real world because they are based on the already proven strategy of iterative development. Simply put, iterative development works by breaking the project into more manageable chunks (iterations) and focusing the team on creating functional software at the end of an iteration (iterations are 2-8 weeks in duration depending on project size and the Agile Software Testing methodology selected). Software engineering can often be complex. To succeed, it demands the use of IT methodologies. However off-theshelf methodologies can often be unwieldy or inflexible. There has been a notable shift towards more iterative development methodologies in the past decade, as researchers and technology leaders sought increased adaptability and flexibility that was not deemed possible using traditional waterfall methods [3]. Agile Software Testing methodology gives birth to thinking in different directions leading to customer satisfaction and optimized software development. It provides optimal approach for forming small testing groups of highly motivated resources, working with a defined goal. This approach of testing not only complete testing life cycle in quick time but also Published by IJECCE ( 26

2 ensures a proper quality testing will be implemented. Agile Software Testing software testing states an effective approach in providing effective results in best possible timescale. To practice and implement any process, principals and methodologies need to be defined and freezed [4]. Agile software development is great for many situations but isn't appropriate for every shop or even every team within a company. It's also not a guarantee for success. It requires an appropriate attitude, an eye for spotting deficiencies in the process, and a willingness to correct the process itself with every iteration. II. PROCEDURE OF AGILE SOFTWARE TESTING III. BEST PRACTICES FOR AGILE SOFTWARE TESTING Often what vary between agile teams are not the practices as much as their underlying philosophies and principles. Discussed are the few encounter issues while working in an Agile Software Testing project. 1. Expect to work in a team that emphasizes cutting to the chase. Test deliverables will be asked to deliver every week or two weeks. 2. The outset of an Agile Software Testing project is usually short. Typical outline of test framework is created and testing is started from day one based on the implementation speed. 3. Once the testing phase has begun, the team will have a tough time telling the early part of it from the later parts. All work takes place in iterations of fixed length-- most typically one or two weeks each. 4. Each test iteration begins in a planning meeting lasting a few hours. The "customer," who is represented by one or more individuals, who know the next most important features that the team should build and test drives this collaborative working session. 5. A very important aspect of Agile Software Testing method is that they all emphasize is delivering working and tested software at the completion of each iteration. 6. From day to day, team start solving the problem by sequence of efficient testing. A Status meeting of 5- minutes are done to proceed further. 7. From a technical standpoint, most of the Agile Software Testing methods say little about what a tester does from day to day. 8. Throughout iteration, the Agile Testing Team will not only just trying to complete individual technical tasks but also promised to deliver completed business functionality. 9. The business side of the fence defines acceptance tests. Some of development work for the iteration might include automating these tests so you can execute them on demand, or as part of the nightly build. It is impossible to optimize all testing, so it is important to determine what tests will produce the most benefit. Tests that require large amounts of data to be input and tests that are run frequently, such as regression tests, are good candidates for automation which is efficient tactic to practice in Agile Software Testing. It is a good method to adopt maximum automation test methodology at Agile Software Testing wherever possible. Any test that has predictable results and meets one of the following criteria is a candidate for Agile Software Automation Testing: 1. The test is repetitive 2. The test evaluates high risk conditions. 3. The test is impossible or costly to perform manually. 4. The test requires multiple data values to perform the same action 5. The test is a baseline test run on several different configurations. Automating the repetitive and boring tasks frees up testers to perform more interesting and in-depth tests. Keep an eye out for tests or areas of an application that are frequently modified. These are barriers to automation. If there is an area of your Web site that changes daily, it will be difficult to define exactly what constitutes a passing result. IV. PHASES OF BEST PRACTICES 1. Prepare your applications for Agile Software Automated Testing Automation tools use a series of properties to identify and locate controls. For example, when searching for a button, the script might use the button label to locate the object. If the label changes from OK to Submit, scripts will no longer be able to find the button when they run and will fail. Developers should immediately notify testers of Published by IJECCE ( 27

3 any application changes so the necessary updates can be made to scripts. If possible, have developers create unique names for controls. Providing a unique name makes it easier for both the script and the tester to identify controls. This reduces the chance that the automation tool will have to rely on location coordinates to find the control. Automation tools can reveal duplicate control names and non-standard development practices. Allow testing to occur more frequently Improve test coverage Ensure consistency Improve the reliability of testing Define the testing process 6. Define measurements for success 2. Identify the correct search criteria If the controls do not have a unique identifier, consult with development to determine a set of control properties that you can combine to create solid search criteria. For example, combining the control type and location coordinates can help distinguish between two combo boxes with similar properties. Keep in mind that some applications have dynamic properties. For example, a Web page can have dynamic hyperlinks that include a session ID. Since that ID changes each time the site is accessed, the hyperlink reference does not make effective search criteria and will eventually cause the script to fail. 3. Define a standard display resolution In some cases, the test tool will need to use relative coordinates to locate controls. All mouse actions also rely on coordinates, so changing the display setting will affect script execution. Use a standard display setting. If testing requires more than one display setting, create displayspecific subroutines that can be conditionally called to perform mouse actions. 4. Prepare Your Automation Team, Processes and Divide your efforts Identify the skills of your team members. Some team members are better at writing test cases than writing scripts. Have a tester with a programming background create any subroutines and functions needed to perform specific actions. Then document the functions and how to use them so other testers can easily include them in scripts. 5. Create an automation plan To decide which tests to automate, it is helpful to write an automation plan. Begin with your goal for Agile Software Automated Testing. Following are examples of possible goals: Speed up testing to allow for accelerated releases Agile Software Testing Software Testing goal should not be automation for automation s sake. In the automation plan, define how you will tell if your test automation is effective. Following are potential measures for successful automation: Same number of features are tested in less time More features are tested in the same time Current testing costs are less than previous testing costs 7. Develop test cases Creating and debugging automated scripts is time consuming. Therefore, you should avoid ad-hoc tests and tests that are only performed a few times. Automated tests should be repeatable and should have clear results. After you determine the types of tests to automate, write test cases that clearly document the goal of the test, the prerequisites, the expected outcomes, and what determines a failure. Ensure that each test has a specific purpose and identifiable results. It is helpful to begin by automating previously documented, manual test cases. When developing tests identify checkpoints you can use to verify test results. Ask yourself what changes in the application to indicate a successful test. The system might update a database or present a verification number. Use a spreadsheet or databases to verify the expected changes. V. IMPLEMENTING AGILE SOFTWARE AUTOMATED TESTING In addition to writing an automation plan, create an automation testing standards document. Decide on how to organize the scripts after they are recorded and define a structure for the scripts. Before recording any scripts, establish naming conventions for scripts and variables. Also, create a separate document that lists all automated tests and the purpose for each test. Use comments throughout scripts to explain the logic of the test. Published by IJECCE ( 28

4 Create reusable and maintainable automated tests-it is best to create small scripts then combine them to create more complex tests. Long, complex scripts are difficult to debug and update. When creating scripts, strive to keep them reusable, understandable, maintainable, and modular. You can use the acronym RUMM to remember the characteristics of an effective script. The following describes how to achieve each of the characteristics. Reusable Keep scripts small and focused on a single task. For example, if you are testing the functionality for setting user options, you can create one script that opens the user options and one that closes it. This allows you to use these steps repeatedly without including them in every script that accesses the user options window. You can also use variables and external data to make scripts reusable. When values for input fields are not hard coded in the script, you can use the same script to test for a variety of different conditions. Understandable Maintaining a document that contains detailed descriptions your scripts functionality and purpose makes it easy to understand what types of scripts are available and how to combine them into larger tests. In addition to a list of scripts, comments in the individual scripts can go a long way to making them easy to use. As a general rule, add comments to variables, functions, subroutines, and branching structures so it is clear how the individual components work. Maintainable Using external data not only makes scripts reusable, it also makes them easy to maintain. To add different test scenarios, you can simply add more data to a spreadsheet or database without needing to edit the script. Also, using an automation tool that includes a textbased scripting interface or allows you to edit a script in a text editor can reduce maintenance time. Modular Creating scripts to perform specific tasks gives you the flexibility to build complex tests from small scripts that are easy to troubleshoot. If your code base changes, it is easier to add small, modular scripts that address the new functionality. You can organize scripts by the application interface, major/minor division in application, or common functions VI. CONCLUSION form the basis for effective Agile Software Test automation. Implementing them can help you avoid common mistakes and improve your testing process regardless of the automation tool you use. REFERENCES [1]. Madhu B K, Megha J and Lokesha V: A Study on Agile Software Testing Emergence and Techniqes African Journal of Mathematics and Computer Science Research Vol. 3(9), November 2010 [2]. Martin, R. C. (2003). Agile Software Development: Principles, Patterns, and Practices Ioannis G. Stamelos, Pagagiotis Sfetsos: Agile Software Development Quality Assurance Information Science Reference [3]. Lisa C, Bob G (2009). Agile Conference The Testing Stage Sessions proposal, [4]. Dyba T, Dingsøyr T (2008). Empirical Studies of Agile Software Deve: A Systematic Review, Information and Software Technology, doi: /j.infsof [5]. Elisabeth Hendrickson.: 2005: Agile Testing [6]. Madhu B K and Lokesha V: Mathematical Modeling and Analysis of Agile Software Testing National Conference on Applied and Engineering Mathematics (NCAEM 2011), RNSIT, Bangalore, Karnataka, India [7]. C. Larman, Agile & Iterative Development: A Manager s Guide. Addison-Wesley, [8]. J. Stapleton, Dynamic systems development method The method in practice. Addison Wesley [9]. W. Cunningham: Agile Manifesto [10]. S. W. Ambler: Software Development [11]. P. Wendorff: An Essential Distinction of Agile Software Development Processes Based on Systems Thinking in Software Engineering Management. Addison Wesley; page 218. [12]. J. Highsmith and A. Cockburn: Agile Software Development: The Business of Innovation IEEE Computer Agile Software Testing is more effective when it is used with the tactic of Automation testing. Automation testing is optimum technique to gel with Agile framework, as it saves time and testing will be effective. The best practices discussed in this paper can be directly adoptable to software development process. Also, these best practices Published by IJECCE ( 29

5 [13]. B. Pettichord, Agile Testing Challenges, Proc. Pacific Northwest Software Quality Conf-2004; [14]. C. Kaner, J. Bach, and B. Pettichord, Lessons Learned in Software Testing: A Context-Driven Approach, John Wiley & Sons, [15]. Agile Testing: The Tester Role on an Agile Project Lisa Crispin, Janet Gregory [16]. C. Larman, Agile & Iterative Development: A Manager s Guide. Addison-Wesley, [17]. B. Boehm, A Spiral Model of Software Development and Enhancement, IEEE Computer, May 1998 [18]. K.Mar and K.Schwaber, Experiences of using Scrum with XP, [19]. L. Rising and N. S. Janoff, The Scrum software development process for small teams, IEEE Software, Issue 17, pp , 2000 [20]. First eworkshop on Agile Methods, Centre for Experimental Software Engineering Maryland, April [21]. P. Wendorff, An Essential Distinction of Agile Software Development Processes Based on Systems Thinking in Software Engineering Management. Addison Wesley; page 218. [22]. J. Highsmith and A. Cockburn, Agile Software Development: The Business of Innovation, IEEE Computer [23]. J. Highsmith and A. Cockburn, Agile Software Development: The People Factor, IEEE Computer [24]. J. Highsmith, Agile Software Development Ecosystem. Addison Wesley, 2002 [25]. M. Fowler, Is Design Dead?, Software Development, [26]. L. Williams and A. Cockburn, Agile Software Development: It s about Feedback and Change, IEEE Computer, June 2003, pp Published by IJECCE ( 30

Testing in the Agile World

Testing in the Agile World John Fodeh Solution Architect, Global Testing Practice 2008 Hewlett-Packard Development Company, L.P. The information contained herein is subject to change without notice. Outline