Arnon Axelrod - Complete Guide to Test Automation: Techniques, Practices, and Patterns for Building and Maintaining Effective Software Projects

Any source code or other supplementary material referenced by the author in this book is available to readers on GitHub via the books product page, located at www.apress.com/9781484238318 . For more detailed information, please visit http://www.apress.com/source-code .

There are many great books about test automation, and particularly about best practices of Test Automation. However, theres no one size fits all. As I once heard someone saying: Best Practices is always contextual: even something as common as breathing may be catastrophic if the context is free diving

Most of the books that I have read so far about test automation are aimed mainly for developers, focusing mainly at unit tests or at developer-written end-to-end tests. Some other books that I either read or know about deal with a specific test automation technology, methodology, or are simply just too outdated. While I tend to agree that the idea of developers writing the tests may be very effective in many situations, in reality it doesnt fit all organizations at all stages. Moreover, test automation is a tool that serves and affects nearly all stakeholders of a software development organization, including testers, product managers, software architects, DevOps people, and the managers of the projects, and not only developers. As every software organization and project is different, trying to adopt techniques, practices, and tools that dont fit the teams needs or skills can cause the failure of the automation project and in some cases even the failure of the entire software project.

The goal of this book is to give a broad view on the subject of test automation in order to allow the reader to make smart decisions upon his particular case, giving his constraints and the benefits he wants to gain from having the test automation, but also to provide detailed and hands-on guidance for building it effectively, at least for the majority of cases.

As test automation affects nearly all stakeholders of software development organizations, and as this book attempts to cover nearly all aspects of test automation, this book is for everyone whos involved in the process of software development and is interested in knowing how to get more value out of test automation. This includes: QA managers, dev managers, developers, testers, architects, product managers (AKA business analysts, system analysts, or various other titles), DevOps people, and more. Ah, and of course test automation developers whose main job is to develop automated tests

While most of the book is not too technical and is aimed at the broader audience, Chapters are very technical and aimed for people who write code and are proficient with object-oriented programming (OOP). In particular professional test automation developers. The code in this section is written in C#, but the ideas and concepts are transferrable to any object-oriented language. As C# and Java are very similar, there shouldnt be any problem for Java programmers to understand the code, but Im also sure that programmers of other languages can understand the code or at least the main ideas behind it pretty easily.

In particular, I hope that many Dev and QA managers will read this book, as they typically have the biggest effect on shaping the methodology and working processes in their organization, which test automation should integrate with, and can help to improve. Having said that, this book also contains useful tips and techniques for non-managers for improving the methodology and working processes of their organization even without any formal authority.

When I first sat down to start writing this book, I tried to think about the high-level structure of the book, but I found this task very baffling because it seems that almost any topic is related to many other topics. At that time, I couldnt find a clear and logical way to divide the content to high-level sections, so I ended up writing a laundry list of topics I wanted to cover and just started writing by letting the knowledge spill from my head down to the paper (or keyboard to be more precise). Naturally I started from the most basic and general stuff and slowly built upon that with more and more chapters that are more advanced or specific. Because the topics are so interrelated, I often wrote a forward reference to a topic I was yet to write, and of course references from more advanced chapters to earlier ones. Eventually, like in a good Agile project (talking about cross-references see Chapter for more about Agile), the high-level structure of the book gradually started to emerge. At some point I realized that the book took a pretty logical structure consisting of two parts: The first part answers more of the general Why and the What questions, and the second one answers the more specific and technical How questions.

Generally, I encourage most readers to read the entire book from cover to cover. However, as this book aims at a broad audience, with different concerns, different starting points, interests, needs, etc., you might prefer to focus on specific chapters and skim, or even skip, others, optionally jumping back and forth to other chapters referred to from the chapter youre reading if you feel you need to fill in the gaps. Finally, keep this book within reach for later reference as the use of test automation in your organization matures and faces new challenges.