Essential Software Testing Tools Blog


Rugged Individualism

January 18th, 2010 by William Echlin

You’ve avoided the usual traps and pitfalls with the implementation of a new software testing tool.

You captured the test tool requirements accurately.

You selected the right product from your list of software suppliers.

You trained the users to use your new software testing tool.

You’ve even planned for the ongoing effort and costs associated with this new testing tool.

And now that the test tool is live the team is using it consistently. In fact you’ve actually succeeded with the implementation of a new software testing tool. This is bringing big productivity gains to your team. You suspect that even the software development team is impressed with the testing improvements you’ve bought about. You’ve achieved a great result.

Although, let’s be honest here…….IT WASN’T JUST YOU WAS IT?

In an old edition of Fortune magazine, an article on teamwork noted that ‘Neil Armstrong didn’t get to the moon through rugged individualism; there is no such thing as a self-made astronaut’.

Successful software test tool implementation involves the whole team.

Software Testing Automation Guides

January 12th, 2010 by William Echlin

If test automation is on your list of things to do for 2010 then this might be of interest. We have written 3 new guides on software testing automation.

Implementing Software Testing Automation Tools” describes an essential Plan-Do-Check-Act process to help ensure the success of your software test automation project.

The Software Testing Automation Business Case” is a guide to help you get sign off for your test automation project within your business.

The Software Testing Automation Check List” provides a list of checks that should be covered when implementing, monitoring and rolling out a test automation project.

If you are interested in any of these software testing guides then we’d be happy to send you free copies. You can request them here (opens in new window):

Software Testing Automation Guides

Traps and Pitfalls

January 4th, 2010 by William Echlin

The road to software test tool implementation is strewn with traps and pitfalls. Traps and pitfalls that result in ’shelfware’.

As testers we’ve enough experience to get past the big implementation hurdles. Installation, setup and education are usually a breeze for us. We spend our day jobs working and learning about new software. So we should be good at this!

Yet we’re just as prone to one ‘gotcha’ as everyone else……..”the failure to treat new software systems and processes as ONGOING projects”.

Like everyone else we think implementing a new software testing tool is a one off project. Just switch it on, use it a few times and away you go. Treat your projects like this and you may as well be putting up a new shelf for the software to sit on.

Value from new software testing tools and processes grows OVER TIME not OVER NIGHT!

We must concentrate on the ongoing effort just as much as the initial effort.

When you buy a new car you don’t pay for it and then expect it to run at no cost for the next 5 years. Once you’ve made that initial outlay you expect to purchase petrol each week. You expect to pay for a service once a year. It’s the same for implementing new software testing tools.

New software testing tools need:

  • administering
  • training for new testers
  • monitoring for consistent usage across the team
  • tracking of user adoption
  • adjustment to match changing business process
  • implementation of new features
  • completion of upgrades

Don’t overlook any of these points! There’s a cost associated with each of them. They all take TIME,
EFFORT and MONEY.

The only option that incurs little cost is placing the software testing tools on a new shelf you’ve been carefully constructing. Even the conscious decision (or more commonly subconscious decision) to place new software testing tools on the shelf comes with a cost though.

That cost is the ‘opportunity cost’ of missing out on the benefits you were so close to realising.

Ongoing costs may be less that the up front costs. Yet you must budget money and time to address. If you do then you stand a far higher chance of realising the benefits you were hoping for.

If you’re considering implementing new software testing tools don’t forget the on going costs. They may be small but they are no less critical.

Implementing Software Test Automation – Part 2

December 18th, 2009 by William Echlin

Overview of PDCA

1. Plan a small-scale project, e.g. learn and use a test automation tool.

2. Do. Execute the plan, e.g. assign a resource to learn the tool and automate a suite of regression tests.

3. Check. Review the project, analyze the results and determine what you have learned.

4. Act. Take action based on what you have learned in the project:

i.    If the project did not work, go through the steps again with a different plan, e.g. maybe use a different tool if the first one did not work out.

ii.    If the project was successful, incorporate what you learned from the project into wider changes, e.g. automate all of your regression tests, or use the tool on other projects.

iii.    Use what you have learned to plan new improvements, beginning the PDCA cycle again, e.g. make use of advanced automation techniques such as data driven testing.

PDCA Project Example

PLAN

Project: Develop a project plan to incorporate a test automation tool into your current testing process on a trial basis and automate a series of regression tests. Keep in mind that most tool vendors have a 30 to 60 day free trial period for their tools.

Process Definition: Define your current process. Incorporating a tool will fundamentally change your process, so benchmark your testing current process.

Data collection: To justify the investment in the tool you will need to determine the value it has added to your process, i.e. this is a cost-benefit analysis. Existing data to collect for the cost- benefit analysis will be:

i.    Number of manual regression tests.
ii.    Number of times regression tests were executed in previous releases.
iii.    Number of people required to execute the tests.
iv.    Time taken to execute the tests.

DO

Implement the plan. Collect data for the cost-benefit analysis and record observations during the project. The data to collect for the cost-benefit analysis will be:

i.    Number of regression tests automated.
ii.    Number of times regression tests were executed.
iii.    Number of people required to automate and execute tests.
iv.    Time to automate the tests.
v.    Time to learn how to use the tool.

CHECK

Review the project, analyze the results and identify what you’ve learned. You can now determine the value using tool has added to your process, with:

Value = Benefits – Costs

Where:

Benefits, represent the time and resources saved in executing automated tests instead of manual test.

Costs, represent the time and resources invested in automating the tests.

In addition to the Value added, you now have a basis for training others to use the tool.

ACT

Let’s assume the project was a success, i.e. the tool added value to your process, now you can act on what you have learned in this project, therefore;

i.    Update the current test process to incorporate automation.

ii.    Start collecting cost and benefit data during other projects that incorporate automation.

iii.    Develop a training regime for others to learn the tool.

At this point you are in a strong position to plan your next PDCA cycle for test automation. For example, you could automate the remaining regression tests for your next project, and follow that project by incorporating automation into other projects, or incorporating advanced automation techniques, etc.

Continuous Improvement

You now have a basis for continuous process improvement using test automation; however, as you continue to use automation to improve your test processes, and as test automation is adopted throughout your organization, the following overall pattern will emerge;

  • There will be an increase in the people and resource investments required for things like training, user support and documentation.
  • As such, there will need to be greater understanding, attention and commitment from management towards automation.
  • Consequently, you will need to have further controls, measurements, and reporting in your processes to provide the feedback that will tell you if your improvements are adding value.

Implementing Software Test Automation – Part 1

December 17th, 2009 by William Echlin

Why Implement Test Automation Tools?

If you currently perform manual software regression testing for each product release, have a large number of tests that need to be executed for each release, and you have frequent product releases then this is an ideal situation to make use of a test automation tool.

Manual software regression testing is an inefficient use of a test analyst’s time, especially if they are merely repeating documented tests.  You can reduce your test cycle times and improve the accuracy of your testing by letting a software test automation tool execute these tests instead.

How to Start – The “Ad Hoc” Approach

So let’s assume you purchase a software automation tool for the test analysts to use but you find things do not go as you expected:

  • Some analysts do not want to use the tool to automate their tests preferring to keep on testing manually.
  • Some analysts give up using the tool, but some users are using the tool successfully.
  • After the several releases the application has changed and a significant number of automated test scripts need to be updated.
  • The tool was expensive to purchase and so much time and resources are being used to maintain the automated test scripts it seems the tool is of marginal benefit.

This is a small sample of the problems that are likely to occur when you attempt to adopt a software test automation tool in to your organization in an ad hoc manner.

A Better Approach – “Plan – Do – Check – Act”

When you adopt any tool into your organization you intend to improve your current process but remember you are also changing the current process and this can be problematic.

Quality assurance and quality control people have developed a system that can make changes like these less problematic. It is an ideal way to adopt test automation into your organization.

This system consists of four steps, plan-do-check-act (PDCA).

Copyright ©2009 - Traq Software Ltd - All Rights Reserved.