Chapter 1: Introduction to Automated Testing
A couple of years ago, I finally got to write this book on application test automation – one I had wanted to write for a long time already, as automated testing doesn't appear to be a love-at-first-sight topic for many. And, like testing in general, in many implementations, it tends to be subordinate to requirements specifications and application coding, be it a project or a product. And who really loves testing? It is not typically what the average developer gets enthusiastic about. Even functional consultants do not easily step up, for example, when raising this question during many of my workshops on automated testing.
So, when I started writing this book, inevitably, I did pose the question to myself: do I love testing? And I answered it with a yes. A big YES. This subsequently led to additional questions, such as: What makes me love testing? Did I always love testing? Why do I love it while the rest of the world seems not to? Questions with answers that made me go around the world evangelizing test automation, stubbornly sharing my findings, and pushing Microsoft to improve their tests to make them better and reusable. And all because I reckon that it is fun – BIG fun!
Having been an application tester in the former Dynamics NAV Global Development Localization (GDL) team at Microsoft, I surely got exposed to the testing virus. You could say that I had to learn to do the testing job, as I was paid for it. But it also suited me well, with me apparently having this specific DNA kind of a thing that makes testers what testers are. Having pride in breaking the thing and loving to prove its robustness (hopefully) at the same time. And, not in the least, daring to break it, running the risk that your developers will no longer like you.
Testing is not rocket science, nor is automated testing. It's just another learnable skill. From a developer's perspective, however, it requires a change of mindset to write code with a totally different purpose than you are used to. And we all know that change is often not the easiest thing to achieve. Because of this, it's not unusual for attendees at my workshops to get to a certain level of frustration.
Application testing is a mindset, and it needs a big dose of discipline too – the discipline to do what needs to be done: to verify that the feature was built right; to verify that the feature under test meets the requirements – and the discipline when bugs are reported and fixed to execute the whole test run again and again with any new bug, to ensure that the verification is complete.
I tend to see myself as a disciplined professional. I have been quite a disciplined tester, with a high rate of bug reporting. But did I always love testing? You know, in those days, all our tests were executed manually, and with each bug I found, my discipline was challenged in some way. Imagine my mind running when executing the fifth test run after another bug fix. It's 4:00 P.M. and I am almost done, and the feature under test has to be delivered today. At breakfast, I promised my wife that I would be home on time, for whatever reason. Let's pick a random one: our wedding anniversary. So, me being a disciplined tester, my promise to be home on time, 4:00 P.M., and … I … hit … another … bug. Knowing that fixing it and rerunning the tests would take at least a couple of hours; how do you think my mind is running? Right: binary.
I had two options:
- Reporting the bug would keep me at work and make my wife highly disappointed, to say the least.
- Not reporting the bug would get me home on time and save me trouble at home.
Had automated tests been in place, the choice would have been quite simple: the first option, resulting in no hassle at home and no hassle at work. Welcome to my world. Welcome to test automation!
In this chapter, we will discuss the following topics:
- Why automated testing?
- When to use automated testing?
- What is automated testing?
Note
If you prefer to read the what first, you might first want to jump to What is automated testing?
