For a legacy system, particularly when there isn't any lower level automation to leverage, I find it helps to start with some analysis to determine first the major functional areas of the application and how much use they receive; then repeat that analysis for sub-sections within the major areas.
This allows me to have a basic guide to approximately how ...
There are a number of considerations.
You should avoid thinking of 'x number of test cases' means 'x number of automated cases'. As attractive as automation is, it is very limited in what it can do effectively, reliably and in a timely fashion. Some things it will be able to do better, others not as well. Humans do not have 'intermittent failures' - or ...
This book is exactly what you need: Working Effectively with Legacy Code by Michael Feathers.
Michael offers several approaches to TDDing legacy code. One of those is: Before you add a new feature, write tests in the area that you will change.
This approach gives a number of benefits:
Writing the tests will give you a certain amount of confidence that you'...
One approach is to spend some time creating a master list of all the application functionality. The simplest approach to that may be to base the list on UI functionality. A more complicated approach is to focus on the back end, based on code, classes, methods, etc.
One you have the list - say 278 total functions then you can measure your progress in ...
TL;DR: Code coverage
retrofit "automation" to a legacy project
What does legacy mean?
To me, legacy code is simply code without tests.
The Legacy Code Dilemma: When we change code, we should tests in place. To put tests in place, we often have to change code.
-- Michael Feathers (Working effectively with legacy code)
Michael Feathers ...
Generally, characterisation tests are not an end state. They're a way to pin the current behaviour of untested legacy code, so that you can start making changes towards maintainability and testability with a reasonable level of confidence that the overall picture hasn't changed. They're not good tests, though, they don't:
tell you any of the behaviour is ...
Here's how I'd approach this:
Analyze and rank the test cases by risk - First, I'd go through and analyze the manual test cases, looking to rank them in a way that helps decide on the automation approach. Some of the factors I'd consider are:
Impact - What would happen to a customer if this test case were to fail in production? A simple 1 to 5 or 1 to 3 ...
I'm not aware of a tool that's capable of doing this across multiple machines. I agree with you that TestComplete's capabilities in this regard are less than ideal. The master-slave setup is fragile at best.
What I used to do in my previous job (with TestComplete) for a similar kind of situation was:
As many of the applications as possible went on one ...
You have a described a situation where there is a lot of technical debt from having no tests.
My approach would be:
Change things for all code (new or updated) going forward to have tests.
This doesn't just mean 'require tests', it will mean investing in lots of education, training and introduction of a changed development philosophy and ...
Kate already gave quite a good answer.
From my experience I'd like to add
avoid heavy test/mock frameworks
There are some mighty frameworks out there that let you virtually break any restrictions that have been imposed by design or language on the legacy code. Though it's true that these are very useful to write characterization tests before moving legacy ...
The good thing to start with is with the requirement document which will help first getting the manual test done then other types regression, load and other types
Which will dedicatedly leads towards better quality of product