What is Agile Testing?
Agile as the name refers implies something to do very quickly. Agile testing is used whenever customer requirements are changing dynamically. Hence Agile Testing refers to validate the client requirements as soon as possible and make it customer friendly. As a Tester, you need to provide your thoughts on the client requirements rather than just being the audience at the other end.
If we have no SRS, BRS but we have test cases does you execute the test cases blindly or do you follow any other process.
Test case would have detail steps of what the application is supposed to do.
1. Functionality of application.
2. In addition you can refer to Backend, is mean look into the Database. To gain more knowledge of the application.
Introduction to Agile Testing
While the given application under test is still evolving depending upon the customer needs, the mindset of the end user and the current market condition, it is highly impractical to go for the usual standard SDLC Models like Water Fall, V&V Model etc. Such models are most suitable for the Applications that are stable and non-volatile. The concept of “Time-To-Market” is the key word in today’s IT Business that compels the Software vendors to come up with new strategies to save the time, resources, cut down the cost involved and at the same time, deliver a reliable product that meets the user requirements. In this case, a reasonably good amount of end-to-end testing is carried out and the product could be acceptable with known issues/defects at the end of an intermediate release. These defects are harmless for the Application usability.
To adopt such a process in a systematic way, we have a new concept called Agile Methodology. This methodology continuously strives to overcome the issues of dynamically changing requirements while still trying to maintain a well-defined process.
The process is as follows:
1. The Customer prepares the Business Requirements and the Business Analyst or the Engineering team reviews it. Ideally, the Quality Assurance/Testing team is also involved in reviewing these requirements in order to be able to plan further stages accordingly.
2. During the Design and Implementation stages, the Engineering team writes User Stories and the analysis of issues at various stages. The Customer reviews these on regular basis and updates the Requirement specifications accordingly. The Testing team would follow up on regular basis at every stage until a consolidated documentation is prepared. This is to ensure that the Customer, the Engineering team and the Testing team are at the same page always and thus ensuring complete test coverage.
3. While the Engineering team starts the implementation, the Testing team starts with test planning, test strategies and test cases preparation. These would be properly documented and handed over to the Customer and the Engineering team for review. This is to ensure the complete test coverage and avoid unnecessary or redundant test cases.
4. As and when the Developer implements the code, the Testing team identifies if the application can be built using this code for a quick testing. This is to identify the defects at the early stage so that the developer can fix them in the next round on priority basis and continue with further development. This iteration continues until the end of the code implementation. Once the testing cycle starts, the Test team can now focus more on major test items such as Integration, Usability Testing and System Testing etc..
Process followed at various stages in the product life cycle:
Every intermediate release of the product would be divided into two short cycles, usually of the duration of 40 days each. Each cycle would be executed in the following stages. The roles and responsibilities of every individual and the team are clearly defined for each stage.
- Design Specifications: The Testing team’s efforts would focus on performing any tool or process improvements and reviewing, understanding, and contributing to the nascent specifications.
- Implementation: While the Engineering/Development team is implementing the code, Testers would develop complete Testing Plan and Test Sets (set of test cases) for each of the features included in the cycle. Engineering features must be included; they would likely require some level of collaboration with the engineering feature developer. All Test Sets should be ready to execute by the end of implementation period of the respective cycle. After Test Set preparation, calculate the time estimation and prioritization for the Test Set execution based on the complexity and expected execution time for each test suite.
- While the test execution time estimation is notoriously difficult, this number should provide the Customer with a starting point for benchmarking.
- Testing/QA: Test Set execution, raising defects and follow up with the Engineering Team. End-to-end validation of the defects. Focus simultaneously on improving the quality of test cases. Watching out for and adding new cases as testing proceeds. Testing the software end-to-end to discover regressions and subtle systemic issues. Learning to focus more on using the time available to uncover the largest number of and most important bugs. Any deviation from the estimated time should be communicated across well in advance, so that the schedule can be worked upon depending upon the priority of the pending tasks. If there are certain issues or test cases blocking due to unknown errors, they would be differed until the beginning of next Testing/QA Cycle.
- Before acceptance: Follow up on ad-hoc requests/ changes in requirements on a regular basis, besides trying to complete the defined tasks.
The role of testing within agile projects as:
- Testing is the headlights of the project – where are you now? Where are you headed?
- Testing provides information to the team – allowing the team to make informed decisions
- A “bug” is anything that could bug a user – testers don’t make the final call
- Testing does not assure quality – the team does (or doesn’t)
- Testing is not a game of “gatcha” – find ways to set goals, rather then focusing on mistakes
The key challenges for a tester on an agile project are:
- No traditional style business requirements or functional specification documents. We have small documents (story cards developed from the 4×4 inch cards) which only detail one feature. Any additional details about the feature are captured via collaborative meetings and discussions.
- You will be testing as early as practical and continuously throughout the lifecycle so expect that the code won’t be complete and is probably still being written
- Your acceptance Test cases are part of the requirements analysis process as you are developing them before the software is developed
- The development team has a responsibility to create automated unit tests which can be run against the code every time a build is performed
- With multiple code deliveries during the iteration, your regression testing requirements have now significantly increased and without test automation support, your ability to maintain a consistent level of regression coverage will significantly decrease
The role of a tester in an Agile project requires a wider variety of skills:
- Domain knowledge about the system under test
- The ability to understanding the technology be used
- A level of technical competency to be able to interact effective with the development team
Advantages offered by Agile Methodology:
The very first advantage is the saving of time and money. There is less documentation required though documents help to a great deal in verifying and validating the requirements but considering the time frame of the project, this approach leads to focus more on the application rather than documenting the things. Since it is iterative in its form, it tends to have a regular feedback from the end user so that the same can be implemented as soon as possible. And because all phases of SDLC need to be completed very quickly, there is a transparency to each individual working on the project with the status of each phase.
Another advantage that Agile Methodology offers to other approaches available is that in case there is any Change request or enhancements come in between any phase, it can be implemented without any budget constraint though there needs to be some adjustment in the already allotted time frame which will not be a difficult task for the projects following Agile tactics.
Daily meetings and discussions for the project following Agile approach can help to determine the issues well in advance and work on it accordingly. Quick coding and Testing makes the management aware of the gaps existing in either requirements or technology used and can try to find the workaround for the same.
Hence, with the quicker development, testing and constant feedbacks from the user, the Agile methodology becomes the appropriate approach for the projects to be delivered in a short span of time.
Principles behind Agile Manifesto:
- Our highest priority is to satisfy the customer through early and continuous delivery of high-quality software.
- Welcome changing requirements, even late in testing. Agile processes harness change for the customer’s competitive advantage.
- Deliver high-quality software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
- Business people, developers, and testers must work together daily throughout the project.
- Build test projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
- The most efficient and effective method of conveying information to and within a test team is face-to-face conversation.
- Working high-quality software is the primary measure of progress.
- Agile processes promote sustainable development and testing. The sponsors, developers, testers, and users should be able to maintain a constant pace indefinitely.
- Continuous attention to technical excellence and good test design enhances agility.
- Simplicity–the art of maximizing the amount of work not done–is essential.
- The best architectures, requirements, and designs emerge from self-organizing teams.
- At regular intervals, the test team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
Agile Testing: Example
Agile methodology with Extreme Programming and test-driven development was used to develop the Smart Client Offline Application Block. The following are highlights of the approach taken on the project:
- The test team and the development team were not formally separated. The developers worked in pairs, with one person developing the test cases and the other writing the functionality for the module.
- There was much more interaction among team members than there is when following a traditional development model. In addition to using the informal chat-and-develop mode, the team held a 30 minute daily standup meeting, which gave team members a forum for asking questions and resolving problems, and weekly iterative review meetings to track the progress for each iterative cycle.
- Project development began without any formal design document. The specifications were in the form of user stories that were agreed upon by the team members. In the weekly iterative review meetings, team members planned how to complete these stories and how many iterations to assign for each story.
- Each story was broken down into several tasks. All of the stories and corresponding tasks were written down on small cards that served as the only source of design documentation for the application block.
- While developing each task or story, NUnit test suites were written to drive the development of features.
- No formal test plans were developed. The testing was primarily based on the tasks or stories for feature development. The development team got immediate feedback from the test team. Having the test team create the quick start samples gave the development team a perspective on the real-life usage of the application block.
- After the task or story passed all of the NUnit test cases and was complete, quick start samples were developed to showcase the functionality. The quick start samples demonstrated the usage of the application block and were useful for further testing the code in the traditional way (functional and integration tests). Any discrepancies found in this stage were reported immediately and were fixed on a case-by-case basis. The modified code was tested again with the automated test suites and then was handed over to be tested again with the quick start samples.