GOOD DEVELOPMENT PROCESS
Pattern summary
Use a good development process for test code; the same as developers (should) use for production code.
Category
Process
Context
This pattern is necessary if you want your automation to be long lasting.
If you are just doing short term automation you will not really need it (even though it would still be helpful).
Description
Test automation is development, so you should adopt a process similar to the software development process (assuming it is a good development process). Development of test code works very well if it is an agile process.
See 'www.satisfice.com/presentations/agileauto.pdf' for a good presentation about agile automation development.
Implementation
Learn about software development principles, if you are going to be working directly with the scripting tools. There may be courses on programming from your local university, for example. Test code needs to be well structured, with small self-contained modules that call other reusable modules. Changes to the software should impact the smallest number of test modules. Scripts and all other testware should be under version control (Configuration management)
Agile development in general uses the following elements: (which work very well when developing automation)
- SHORT ITERATIONS: you don’t plan everything up front, but break up the work-load into short iterations. At the beginning of the iteration you plan to do only what you can completely finish. At the end of the iteration you have working software that you could deploy to production. The customer can check if you delivered what he or she had in mind. If not, you adapt it as required in the following iterations. In the case of test automation, your code will be scripts and your customers will be the testers, so it works the same way.
- Everyone on the team is responsible for the quality of the developed software. For test automation this means that team members:
You can document your test automation process in a Wiki.
Potential problems
If the software developers in your organization do not have good software development practices, then your development practices will have to be better than theirs!
It might be difficult to develop the test code in an agile way, if the software development is not agile, but it will still have advantages.
Issues addressed by this pattern
BUGGY SCRIPTS
DATA CREEP
GIANT SCRIPTS
INADEQUATE REVISION CONTROL
OBSCURE TESTS
SCRIPT CREEP
TEST DATA LOSS
Experiences
Added by Jen Leger:
At our company, we have one test automation team but our team members are sourced out to different projects. When it came to configuration management, initially our team kept the test automation scripts in SVN in our own test automation folder. We kept our common framework code and application specific code in seperate folders under this root test automation folder. We learned over time though, that each application could have multiple branches in parallel and we needed to do the same with our application specific automation scripts. Since all of our application code was under a common folder in SVN, it was impossible to branch our code to match the different application branches. =We realized our app specific scripts would need to live in SVN with the application code.= That way when a new application branch was created, or a branch was merged with the trunk, our automation scripts followed the same pattern and our tag numbers always matched with the application code. So if we were testing v 1.1.1 of an application, we knew we needed v1.1.1 of our automation scripts for that application. So now, all project specific code live in SVN with the application specific code and all common framework code lives in a different project in SVN. It is much easier to manage this way if you have different versions of application code being tested at the same time.
Added by Sergiusz Golec:
If the software developers in your organization do not have good software development practices, then your development practices will have to be better than theirs!
I think that after such statement, you may consider adding a short example, I heard (or read) years ago:
Imagine a task. To get from point A to B in time you have 2 resources - a car(vehicle) and a driver:
- If you have a great (smart AI) car, you can have an average driver (to get you there in time & quality).
- If your vehicle is bad - it's better that you have a great driver.
- Best if you have good or great both car and a driver. The Worst case - bad car & bad driver - invest in the change of your resources, or forget about getting to the point in time (& quality).
If you have also used this pattern and would like to contribute your experience to the wiki, please go to Feedback to submit your experience or comment.