Thinking of starting new test automation project, STOP! , take a coffee and read this first.
I’ll give you the Punch line of this story first:
It is almost a classic already, but still so valid and highly recommended reading for all those considering a start in test automation.
Software Test Automation
by Mark Fewster and Dorothy Graham
Addison-Wesley, ISBN-13: 978-0201331400
Available from various book and online stores.
For example, from TextBooks.com where you get 30% discount on this book.
Remember that the biggest problem with test automation is not the execution engine (I.e. to execute your test cases against SUT) but the challenge of making your test suites reliable, maintainable and effective over time. This is way too often forgotten as many focus on the test execution, without realising that the design of your test cases and the test framework & test ware architecture is actually the key to the success. Infact, you should actually design your test framework in a such way that the execution engine is modular and can be changed to something else later, this way you can also avoid any “vendor lock-in” situations..
So its worth to have a read few words about test frameworks and test ware architecture, my personal favourite is book by Mark Fewster and Dorothy Graham available at Textbooks.com (or in many other online store). You should start first thinking how to manage your test cases, version control, meta data like headers, scope, test data, etc. But soon you should also consider the way you actually constract your test cases itself, there should be a way to decouple test case logic from SUT specific test steps.
Example:
You might have a test case that has #TestObjective to verify that AMEX Credit Card number is accepted on payment application.
The logic and purpose of your test cases is rather clear, isn’t it? You want to confirm that the numberic format complies with the standards set to AMEX Credit card followed up successfull validation by the payment gateway.
But what you are not specifying there are the steps to nagivate through the application under test to perform the test. This is exactly what we want to achieve also in our reliable test automation test case design, you want to decouple test case logic from actual steps. Another way of looking at this is to consider few steps in version X of the application under test, but consider what would happen if the very first step, say welcome screen, does change. Your #TestObjective remains the same but steps to execute the test in the new version Y of the application under test just happen to be different.
The best approach is to abstract your test case into logical groups of actions, or modules. Using our example those logical steps could be:
- Start the application under test
This can be web page, application, or even physical interface - Authenticate
This can be just simple user name / password, or on another application or version of the application it can be 2 factor authentication - Navigate to Payment module
Here you might need to go through welcome page and some menus to get to the place where we do the actual test - Enter valid AMEX Credit card number
This should also be a reference to your test data set, i.e. you can re-use the same test case for all your valid or invalid test data - Confirm AMEX Credit card number is accepted
Here again the way to confirm this could be different dependent on your application
Now consider each of these steps to be re-usable modules, building blocks. If your application under test goes through an upgrade and the menu structure does change, you don’t have to change hundreds of test cases but only single common module (Step 3 in our case) and all your test cases are relevant again. Similarly If your want to add another test objective for Master Card, you can re-use your modules and just add test data set to your step 4.
Summary
This is just one of the key aspects how to keep your test suites relevant, remember that your best possible return of investment comes from multiple test execution cycles of your test cases. I.e. if it takes X number of hours to run the test manually, you will only get the benefit until your test scripting time Y and cost of your test framework have been covered.
You can read more about this topic from the excellent book (here) mentioned earlier, and I will also collate my own experiences from last 15 years of building test frameworks in another blog post later on..
Until next time!..☆☆☆
.
by 