Common Testing Snags

Software Testing is an integral part of the software development life cycle. Inadequately tested applications result in loss of credibility with the customers–be it an existing customer or a new one. It is therefore very essential that effective testing be performed with an intention to eliminate the common problems that might cause havoc before releasing any software. This document briefs the common testing snags most of the testing projects face and a few tips to overcome them.

1. Poor Planning or Estimation
Effective planning is one of the most critical and challenging steps in a test project. Test planning and estimating indicate the order and way in which the tasks are to be carried out and the resources required to execute the same. Proper planning is not possible without a sound and reliable estimate.

• Effort: Delays can result because of lack of resources to perform the activities in a certain time frame or in less efficient use of resources because too many resources are allocated
• Schedule: Schedule is estimated after the effort is estimated. Developers underestimate the effort and resources required for testing. As a consequence of which, deadlines are not met or software is delivered only partially tested to the ultimate end user
• Cost:When budgets are not correctly estimated, it becomes relatively expensive; it might result in some test activities to be cancelled causing more insecurity about the quality of the project

How to tackle?
Take a percentage of the total effort, employ standard ratios in testing based on previous similar test processes, allow for overheads, estimate the hours for individual activities and extrapolate the results. Inadequate testing because of lack of knowledgeable resources such as using testers with little or no experience also results in poor quality of testing. Do not forget to include

• The training time required to improve the knowledge level of the resources on the domain or technology
• Buffer time required to resolve any risks that you foresee

2. Ambiguous Requirements
Without adequate documentation, the testing effort usually takes longer and allows more errors to get through to the released version. Ambiguity in requirements makes the test design phase a tedious task. The cost of uncovering and correcting requirement deficiencies at this stage is significantly less than that incurred during the acceptance-testing phase. There may be numerous implied or underlying requirements, which may be overlooked by the testers on glancing the requirements. It is therefore essential that the requirements be understood thoroughly at the initial phase of testing.

How to tackle?
The testers can review the requirements and prepare a list of queries to be addressed on the requirements and get them clarified even before preparing the test cases to enable them deliver a quality product. A report with the deficiencies in requirements may also be prepared.

3. Insufficient Test Coverage
A good test suite will achieve high coverage. Inadequate number of cases cannot complete testing the functionality in its entirety. Test coverage is only a measure of the quality of testing. If high-test coverage is not achieved, it is imperative that the process needs to be strengthened. Another factor to be added is the inadequate test data that does not completely the possible ranges.

How to tackle?

1. The associated test case identification number (say a unique number for every case) can be marked against the requirements in an excel sheet to ensure that test cases are written for all requirements. Low coverage indicates a process problem, which might require test generation technique to be improved, or training to be imparted to the tester. Many tools are available in the market to measure the test coverage.
2. It is not possible to test all conditions in an application system. Data design with valid, invalid data to cover normal processing operations adequately can be prepared. Techniques of boundary values, equivalence partitioning can be applied while preparing test data.

4. Uncontrolled Test Environment
The more the test environment resembles the final production environment, the more is the reliability of testing. Lack of such an environment will result in unpredictable results while in production.

How to tackle?

1. 1Testing should take place in a controlled environment. It is therefore separated from the development or production environment. The ownership of test environment should be with the testing team and without their permission no change should happen in the environment.
2. Measures can be taken up to set up the test environment in time and ensure that it is well managed; ie. The test environment should be sufficiently representative for the test to be performed that is, it should be closer to or the same as that of the production environment. It is necessary that the Test Manager or a coordinator manages deliveries from development team and is made responsible for the set up, version management, authorizations etc. If an independent test team is established, it will be ideal to have an independent configuration team also.

5. Testing as an Aftermath
Underestimation of the effort and resources required for testing results in starting testing activities at the fag end of the development cycle when it becomes difficult to fix the major bugs unearthed by the testers and also results in compromising on details in the test documents owing to time constraints.

How to tackle?
Test planning can be initiated as soon as the requirements are defined. Process of test execution in parallel with application development can be adopted.

6. Inadequate Test documentation
Inadequate/improper test documents (test plans, test specifications, defect reports etc) results in loss of time while analyzing what to be tested/re-tested and the related areas to be tested, which might in turn have an impact in the delivery or the quality of the product.

How to tackle?

1. Adequate effort needs to be spent on documentation also, as test documentation is a very important task in all phases of testing.
2. Care can be taken that all documents related to testing are prepared right from the beginning of the SDLC and updated continuously.