Showing posts with label Test automation. Show all posts
Showing posts with label Test automation. Show all posts

Sunday, April 14, 2013

ROI (return on investment) for investing on Test Process Improvement

I am sure every organization will have project analysis after a major release and followed by a formation of a  task team to implement some set of actions resulted out of project analysis meeting. Some of them which will always appear in the list are
1. Improve unit testing and define some criteria for integration and system testing team to accept build for their testing
2. Automate many of our tests which are used at various stages repeatedly (nightly build test, regression test)
3. Regression test automation % should progressively grow release after release
4. There should be clear production release criteria and risk assessment before release
5. Improve estimation
and so on

Many will finally agree that test process improvement seems to cover majority of the list  in the action items coming after project review.

Let me also share from my experience who will get the advantage investing in test process improvement. You need to answer "YES" or "NO" to following questions. It may look common sense but we ignore these patterns.
1. Are you able to make your last release with exact number of planned test cycles?
2. Can you assure that majority of the tests done by development team is not repeated again in next level of testing?
3. Number of patch releases made after final production release is under control therefore support team and customers are not cribbing?
4. You have a well defined maintenance team which work on customer issues and enhancements and none of your product next version road map plan are impacted due to maintenance release pressure?
5. When you analyse the defect found after release majority of them were not traced to "missing test case" or "incomplete regression test" due to lack of time?

If your answer is "No" to any two of the questions above I feel you must look at formal test process improvement in your organization. Some TIPs on how to go about it.
http://slidesha.re/MCN-Quick-TP-Assess

Like to hear from our software engineering community on their views.


Friday, August 5, 2011

Test automation challenges

Organization may be having the best test automation practice but test assets are inadequate. Such automation investment is of no use. Management will be wondering on so much money invested- on tools, training, hiring skilled engineers and scripting effort but defect escape to production is still bothering them.

Many parents who wanted their children to be successful in their life, sponsor them for whatever certification courses their son/daughter wanted to do after their graduation. Common mistake which I have observed is, parents sending them for some test automation tool training and get the certification. If you see the data points on how many were successful with that path, it is not that encouraging. Why? What went wrong? Automation of wrong tests may not yield anything as business value to organization. They need to understand what are the right test to automate is before starting on test automation. If that skill is not there difficult fro them to be successful in this path.

Another issue is organization management tracking on what percentage of tests automated than how it was done? They get some shocks like the automated scripts not working on new version of product but effort required to maintain scripts not possible to allocate with release pressure and scripts were dumped as useless assets. No frame work used and no standards in scriting maintenance is complicated.

The tool used for automation will not be supported from vendor from that year!. (Phased out tool), but automated scripts is really reducing test effort, helping in doing better regression tests, helping multi-platform tests etc. Oops! what to do? How can we accelerate porting these automated test solution to another tool?

HBT helps to address some of these challenges. Take a look at the following PPT