Hope you have enjoyed the Traditional Approach. Now let us discuss more about the common problems of Manual process. The main problems can be categorized as
- Process related problems
- Time related problems
- Technology related problems
- People related problems
|Process related problems:|
- CRs-Change Requests
- Modification for the CRs
- Execution for the prior test cases are very high
- delay in bug verification
- Inconsistent bug reporting
- Testing in different platform is time taking
|Time related problems:|
- The process become very much time consuming
- Turn around time (TAT) become high
- Peer checking eats up the time
- Testing window is very short
|Technology related problems:|
- Less technical support
- Risk is very high
- Due to this less productivity
|People related problems:|
- Not everyone is equally knowledged with and about the application
- Conflict of interest
- Prone to error is high
So based this scenario if somebody conclude test engineers only tests the new scenario or 80% of the effort must go to the testing process of new feature and regression should based on sanity.Will that work???
No…the regression might produce some more bug.Or due to fix of a bug might discover the hiding bug.Remember the cost of bug…
if a bug is caught well advanced the cost to fix and retesting cost is less but if it is later stage the cost might go up exponentially.
To mitigate such risk we have take a different approach. Most of test cases of earlier builds should be executed to detect the regression .Test engineers must check the new features..
Sometimes it is incredibly frustrating to work in agile mode of testing. There are pressure to deliver and many times the QAs are the lone person to raise voice when everybody thinks the software will work well.QA needs to be very confident about their work should be able to backup their opinions with real facts.
In agile mode of development QA can not be frustrated if there is less requirements or no requirements or frequently changing requirements.In agile world, requirements are constantly being altered,added,redefined,refined or scrapped. There will be constant flux. We the QA need to be agile enough to cope up with the changes.Many start ups don't even like to spend time and money in testing,even many times they think automation is the key to get success.To add to this they even call junior developers to test the application. But this strategy mostly fails as 100% automation is neither possible nor desirable. Again the developer can not test the application due to the mindset. They are creative by nature and QAs are destructive by nature.
Lack of advertisement also makes QA fail. In start ups QA team tends to small and mostly hidden under development. To mitigate the risk about a software QA's role is huge. They need to raise alarm on a faulty product at the same time need to pick the free software to make QA cost less. But overall they need to advertise for themselves. Only then the importance will be well understood.
In today's world people need good things at very minimal cost or in free. But at the same time they are ready to uninstall if there are bugs in the software. They may give negative comments about the product. Playstore -Android,Appworld-Apple etc are classic example of review comments. Few negative comments may slow down the selling or adapting new software. Think about real world,we always go by the rating and comments.
The startups and companies are cleverly taking a approach called alpha and beta testing to reduce cost. This strategy creates hype but produces bad more rather than good.
TDD-Test driven development is coming but in a very slow manner. Some also outsource the product to test. but the main problem is with the commitment level of the vendor company. They may not be as good a full timer.