Testing in the hostile environment

Testing is inevitable in software development. Testing is mandatory in any software application developed. As a test engineer, your get you due chunk of time to test the AUT (Application Under Test) and do justice to the job.

In my role as a software tester, this has not been the case always. I have come across many software development projects which are a complete exception from all the SDLC methodologies that the industry preaches, follows and propagates.

These exceptions are unavoidable as that is how the customer wants it. There have been project kick-offs with no common understanding of the requirements and expectations. There will be constant change in requirements which will go un-noticed. When the entire development team is working against time to meet the deadlines testing becomes the toughest.

The Challenges for testing in such an environment are:

1. No well defined spec. Though available it keeps changing.

2. Keeping track of the changing requirements.

3. Lack of communication to the Software Test team

4. The actual time available to test id often less than what was estimated.

One of the possible solutions for this can be AGILE METHOD of software development. But with all the above 

issues under considerations, even attempting AGILE can be a big overhead.

How can testing be done in such a hostile environment?

At least, the development team can version control their code and keep track of changes in whatever way it is possible.

It is for the Software Test Team to align themselves with the actual conditions to ensure in spite of all the challenges, the software is delivered as per expected quality standards.

The testing team, in such cases, should think out of the box-go beyond Test Cases and focus more on the user scenarios in the exploratory style to ensure more time is spent in TESTING rather than documenting.

The testers should be innovative in think of more possible user scenarios and walk through the application in all possible ways to figure out the defects. The defects identified can be fixed time and again by working closely with

the coders when the defect tracking tools and time are luxury.

The logic is simple, the more time you spend in the application, the better you can test.

Though it might not hold good for all software testing assignments, in the hostile testing environments like in our discussion, this may be an efficient way though.

Happy Testing!