This is a question a lot of organizations and teams have when they want to start with test automation.
“What tool(s) are we going to use?“
Answering that question isn’t that simple else not so many teams would struggle with that question so much.
Currently I’m helping a client to set up test automation. We also had the same question. This is what I experienced in the last couple of weeks.
- There is no silver bullet test automation tool (thanks Martin Gijsen)
- As I mentioned in one of my other posts, knowledge is essential. Not only about the principles and practices of test automation but also about the tool or the framework that is used.
- Make small steps to start the movement, instead of talking a lot and moving further in the wrong direction.
- Use the knowledge that is already present within the team/organization and start with that. This helps to make the first steps and to change te mindset of the team members.
- Monitor the automated tests? Are they working, stable, transparent and visible for everyone? This will help in the adoption and will stimulate other team members/teams to also start creating automated tests when they see the benefits.
- Starting with Specification by Example is a team effort else it won’t succeed.
When you use the knowledge within the company, the tool doesn’t really matter. Of course there are differences between the tools that are available for test automation. But the way you build up the tests is more important for success and maintainability.
Many tools support record and playback and those are really tempting to use for unexperienced team members who want to contribute to test automation. At my current assignment, we are using HP UFT (HP Unified Functional Testing) for test automation. Not my first tool of choice, but as I mentioned before, the knowledge base of this company was in UFT. Many testers received a training recently so we started with that.
One of the reasons UFT isn’t very popular, is that many users apply record and playback. In te last couple of weeks I’ve been coaching two testers who are writing automated tests in UFT. During this process, we are creating the tests manually using the descriptive programming approach. This enables us to separate the technical logic from the test to make the tests readable for non-technical team members and stakeholders. But last week one of them had a relatively simple test case and used the recorder to create the test. I accepted this because I knew it would come back to haunt us soon enough.
Within that same week, we had to finetune the tests a bit based on new insights (we are still learning UFT and the application). When we came to the recorded test it became clear that the test could be written in a few statements, because we basically already had the actions available already. Besides that, changing the test would require to re-record the test. This way, the team member got convinced quite fast that recording a test is not the way to go.
In conclusion, the choice for the tool(s) that you are going to use to automate your tests is not as important as the knowledge base present in the company. Build on the knowledge there is and become great with that knowledge, even if the sexiness it not what you had hoped it would be. Strive for good results and let all team members feel as if they can contribute, not as if they have spent the last years of their careers learning stuff that doesn’t work in the sexy world of test automation tools. When the mindset is changed there is room to look into other tools that would fit the application / organization better if necessary.