Despite what the test automation tool vendors are saying, test automation is not about record and playback but about programming. To automate a functional test case, a programming language is used for writing the automation code. This post will look at how to do automated testing with the approach of a developer.
This code interacts with the application under test (website, mobile application, windows application) through a test automation framework.
Before he can participate in automation projects, a manual tester needs to familiarise himself with
- a programming language
- a test automation framework
- a language for creating objects locator expressions like XPATH
- unit testing
What happens actually during this learning phase is that the manual tester is becoming more and more a junior test automation developer.
I will use in the rest of the article the TA dev abbreviation to refer to new test automation developers as opposed to application developers.
After the initial learning phase, the new TA dev will be able to
- write test automation scripts
- modify automation scripts
- run them
If the TA dev wants to improve further and get to the next level, how can he do this?
Is there someone that can teach him more advanced skills for test automation?
That person is the application developer
Automation projects are development projects and this is what developers do.
Development is their expertise.
Why dont TA devs observe then what application developers do and then apply these things to test automation?
Even better, why dont TA devs involve application developers in some aspects of test automation?
How to do Automated Testing
1. Developers use code review processes for improving the code quality
This process can be complex with a team participating in the review.
It can also be very simple with just another developer reviewing the code and providing feedback.
The feedback is then included in the code and another review is being done.
The process continues until the code is production-ready.
The TA devs can use the review process for their test automation scripts.
Another TA dev or even better, an application developer, reviews the test scripts and points areas of improvement.
The review process can lead not only to better test automation code but also to better programming knowledge for the TA dev.
2. Developers use good programming practices
Developers have good programming practices such as
- coding standards for names of classes, objects, methods
- programming principles such as dont repeat yourself, you arent gonna need it, information hiding, etc
- keep methods short
- refactor the code often to make it simpler
- write code that is easy to maintain and read
All these are very useful for TA devs as well.
Because their code should be at the same level of quality as the developers’ code.
3. Developers use source control systems for storing the code
They use the source control system for
- storing multiple versions of the code
- checking out code before adding changes to it
- checking the code back in after completing the development
- comparing versions of the code
- Using a source control system is beneficial for TA developers as well.
Test automation scripts can be stored in the same repository as the application code.
4. Developers write code based on requirements or user stories
TA devs should follow and write the test automation scripts based on automation test cases.
5. Developers extract code that repeats into classes that are included in frameworks
Testers should build test automation frameworks that include any common functionality needed in the test scripts.
6. Developers use continuous integration for checking all code changes by generating new builds
Testers cannot generate new builds of the test automation code.
They can integrate the test automation scripts in the continuous integration process.
This way, every time new code is checked in the source control system, a new build is generated and test automation scripts are executed automatically on the new build.
Test automation projects are more successful when testers and developers work together.
And there are so many things that testers can learn from a development team on how to do Automated Testing so go out there and learn!
Interested in Programming? Take your first steps into programming with this eBook Programming for Testers, It’s Easy!<
Greetings Alex,
While I agree that automation code should be developed following programming and, more importantly, design principles, I don’t think automation is only about programming.
Programming is only one piece of the automation puzzle, out of many. How many pieces you’ll have will depend on the problem being solved, what is being automated and for what purpose.
I think record and playback is also one of those many pieces that may or may not be needed to solve a specific problem. It is certainly not the only piece of an automation puzzle either. And most likely also need programming intervention.
Thoughts?
Thanks for your comment, Freddy.
You mention about test automation including more pieces than programming.
If these pieces are things like xpath, junit, maven, eclipse, I agree with you.
Otherwise, I am not sure what you mean.
Can you provide some examples?
Record and play was useful for me so far only in cases where I needed a quick script that was ran a few times and then discarded.
In all other cases, programming was the way to go.
Hello again, Alex.
Following good design and programming principles, as well as all of the other things you mention int the post, and that i agree with btw, will yield higher quality “automation” code. Just like it will for any other development project.
But, IMO, this is not what automation is (I.e. programming). I view automation as the next step in human time optimization. We delegate, via automation, a list of things we want to ensure, or verify, or check are in a state we expect it to be; when they are not a flag is raised.
Regarding record and playback: I’ve found it useful under the following circumstances.
1. While learning / Teaching an API
2. Reproducing scenarios (bugs, user stories, support tickets)
3. Producing template code that can be quickly modified for methods (e.g. Login to website, check email)
Everyone’s mileage will vary on that one, I reckon.
Regarding programming is the way to go, I concur.