Structure of Software Testing Process
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
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.
($) 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:
This unique article has been published on http://EzineArticles.com