Agile Software Designing

History: To understand the testing process in Agile development methodology, it is important to understand the paradigm of Agile development. The Agile Development paradigm is not new. Although Agile Software Designing Manifesto was launched in February 2001, the concepts existed well before this and have been expressed in different ways. Development methodology spiral is an example.

What is Agile Software Development: The Agile Software Development focuses mainly on an iterative development and delivery. Developers and end users to communicate closely, and the software is built. A working software is delivered in a short period of time and based on the comments more features and capabilities are added. The emphasis is on customer satisfaction by providing software quickly with minimal features and improvisation based on the feedback. The client is closely involved in software design and development process. Delivery times are short and the new code is built on the previous one. Despite this, the quality of the product can not be called.

What is the test in a scenario of Agile development? The test strategy and the Agile development approach could be very different from the traditional bureaucracy. In fact, it can vary with the needs of the project and the project team. In many scenarios, in May it make sense to not have a team of test. The above statement should be understood carefully. Failure to have a testing team, we do not consider the tests to be less important. In fact, testing can be more effective in short, by people who know the system and its objectives very well.

For example, some teams of Business Analysts could make a few rounds of tests each time the software version is available. Business Analysts understand the requirements of the company and the test software to check if it meets the requirements.

Developers test the software in May. They tend to understand the system and can verify the test results in a better way. Testing for Agile Software Development requires innovative thinking and the right mix of people should be selected for the test.

Software Testing Process Structure

Software Designing of a large project proceed as per the following team structure.

1) Team of Feature Owners: It is a top-level team in the hierarchy, which directly interacts with the prospective customers. It is responsible to minutely understand the customer requirements and groups them into several features. Various members in such a team may become the owners of some of such features. The team members take due initiative and actively interact with various teams become instrumental in providing necessary directions in developing the features owned by them.

2) User Interface Team: The User Interface called UI in short is extremely significant for the product. Even if a software product has series of excellent features, but its User Interface is not effective & convenient, the product is destined to fail.

Hence independent User Interface team is created. The members of a User Interface team are specialists in designing the User Interface for the software products and understand the difference among a good User Interface and a poor one. The sole objective of such User Interface team is to do extensive research in the User Interface.

The UI team designs UI for the product or its features. In the next step the UI team interacts with Feature Owners team to give a practical shape to the UI jointly. Such meeting may result into may be “Page designs” or some “Mockups” containing all elements of the UI as required in the page. The mockups are helpful in presenting the desired appearance or looks of the page. Actual navigation between various pages is also checked during such cross-functional meetings.

3) Development Team: Is entrusted the task of development of the Product.

4) Testing Team: Is entrusted the task of testing the product.

FLOW OF THE PROCESS:

1) Project Kick Start: The members of feature owners team kick start the process with the development of a design document at High level applicable for every feature & the same is released to all concerned.

2) Release of High Level Design Document: Apart from the High level design document prepared by features owners, the designs of the pages or the User Interface Mockups are released to all concerned for reference by the UI teams.

3) Software Development: Coding of the desired features is started by the development team as per the released documents.

4) Software Testing: The testing team kick starts the testing related activities in the following manner:

($) Preparation of a Document with Test Outline: This document describes details of flows of the test or Multiple-Test Scenarios projected at high level. Test outline shall have brief information as to what needs to be checked at which point during the flow.

In addition to the details of flows, this test outline document contains detailed matrix describing all the requirements from the High Level Design Document (HLD) down to the test flows. In HLD a unique ID can distinctly identify each requirement. The purpose of this matrix is to make sure that all requirements have been carefully checked for any deficiency.

($) Preparation of Test Cases: Every test scenario is further converted to an individual test case, which contains all the detailed information. It specifies exact steps for navigation, desired data and detailed information as to what needs to be checked. Detailed explanation in Test Cases is helpful especially when the persons writing the test case are other than the persons going to execute them.

($) Test Automation: Although not compulsory, test automation is optional step. This involves automation of the designed test cases with the help of some automation tool, best suited to the requirements of the company.

($) Concurrent Activities: Development & testing work is carried concurrently. The development team gets engaged in the main task of coding of the desired features. Development team sometimes does some sort of testing at their end as well. In the meantime the testing team prepares the test cases for manual testing and automation scripts for automating the test execution with the help of some automation tool.

($) Product Testing: The cycle of testing begins when the testing teams actively start the testing of the product and start logging the bugs in the defined bug repository system. Concurrently the developers are engaged in fixes of the bugs.

As a best practice, two separate instances of the application are maintained. One instance is earmarked for the testing team and the second one is meant for the team of developers or bug fixing team. However both the teams operate on the same code level.

($) Logging of Bugs: Prior to logging a bug in bug repository system, it is verified as to whether we can reproduce it in the instance meant for the developers or not. If the bug is reproducible, it is assigned to the concerned developer for necessary fixing. When the bug is fixed, then the code fix is applied on developer’s instance, thoroughly verified and then it is applied to the testing team’s instance for regression testing.

However if the bug can not be reproduced on developer’s instance, it may be inferred that it can be a problem related to some type of application setup. In such case the developer interacts with the testing team to ascertain if it is a genuine bug requiring changes in the code or it is some kind of application setting issue. Such application setting issues are quite common during testing of software suites of tightly integrated products.

($) Regression Testing: Code patching is done & the testers repeat the testing from the beginning. In order to fix the bugs, frequent patching of the system is avoided. As per the best policy for patching the bugs, involving for multiple rounds of testing, patching of all bugs accumulated between two testing rounds is done once only, The bugs are fixed and kept ready for patching together. This also does not have a hard & fast rule. Exceptions are there for bugs, which are considered to be critical & which can severely hamper the testing can be patched immediately.

($) Sanity Testing: After the patching is done, the application instance is subjected to sanity testing by the development team. Then it is released for the next testing round involving execution of all the test cases again. This includes execution of the test cases which happen to pass in the previous round.

($) Stopping the Testing Operation: In a scenario of multiple testing rounds, an important decision needs to be taken as to whether to proceed to the next round of testing or halt there itself. The vital decision to a large extent depends upon the number of bugs which had been logged during the previous round of testing. Two factors can help take such a decision are:

1) Further testing can be stopped when no fresh critical bugs are detected & when there is no further need felt for regression testing.

2) Further testing can be stopped when very less number of minor issues are left. The term “Less” is highly subjective and depends largely upon the application under test.