While automated testing can be quite valuable to a business, the topic generates many questions. Some of these focus on the technical side. Decision makers tend to ask themselves and others the more fundamental questions, such as:
- What benefits will automated testing bring me?
- Is my organisation ready for automated testing?
- Will our efforts be successful when so many test automation projects seem to fail?
- How can I ensure Return On Investment?
- How should we introduce automated testing?
- What tests should we automate?
- How do we approach automating tests for a legacy system?
- What test tool should we use?
- Are the tools really as easy to use and effective as their vendors claim?
- Are open source tools really cheaper than commercial ones?
- How do automated unit tests and acceptance tests relate?
- How can we manage the link between requirements and automated tests?
- Can we do an Agile project without automated testing?
- What is Model Based Testing?
- Is Model Based Testing better than automated testing?
- Should we outsource automated testing?
The central theme of this blog is automated functional testing. It attempts to present the essence of matters, leaving out details that are not required to make sound business decisions and avoid the various pitfalls. It should, therefore, be of particular interest to decision makers with an interest in how automated testing can be made to support their business. And also to those who advise decision makers, of course.
As situations can differ greatly between companies and also between departments or even projects, few answers are valid in every context. The key to finding the right solution for your situation is asking the right questions. The information offered in these articles is meant to point to the right questions to ask. The answers to these, whether coming from yourself or others, will then lead to solutions that will make a difference to your business.
A new article is planned every two weeks. Each one will focus on one question, either from the above list or from a reader. So all feedback is more than welcome.
There will be no sales pitch for any product or service in these articles. Not even my own.
The guy behind this blog is Martin Gijsen. Let me introduce myself.
I am an IT consultant, living in the Netherlands, who started as a software engineer in 1997 and became an independent consultant in 2008. While I have been involved in automated testing since 1999, it did not become the core of my work until 2008. Since then, most of my work consists of consultancy on how to successfully implement automated testing in an organisation and then training and coaching the people that are doing it. I also give workshops and presentations.
The systems for which I have created solutions for automated testing range from web applications to embedded systems. The development process was sometimes Agile, sometimes traditional. Where possible, examples will be taken from my own experience.
As a consultant, I aim for a solution that truly suits an organisation, so that benefits can be harvested for a long time. Because of this, I have a personal preference for open tools (i.e. with an API) because they tend to offer more flexibility in designing and creating such a solution. Many of these tools are also open source. But I use whatever tool is most suitable, and often this is a commercial one.
Besides this consultancy, the software engineer in me has been designing and creating the PowerTools, a suite of open source tools for automated testing. These tools make good use of existing free and open source tools such as Selenium WebDriver and Auto-IT to interact with a System Under Test. But the core of the PowerTools consists of its generic test engine that reads the test (from FitNesse or Excel), executes the actions and reports the results. The PowerTools also include a module for creating graphs using the GraphViz tool. For more details, please check out the PowerTools website.