Test Automation Blog Introduction

Software Test Automation (STA) is a broad field. There are tons of tools, technologies, and frameworks out there that follow different approaches to testing software in automated ways.

In this blog series I want to share experiences and thoughts from years of working as a software engineer with a focus on quality and testing.

I plan to write broadly about the topic of test automation, and also more detailed solutions to technical challenges I worked on in the past.

Software QA Map

When holding workshops or training engineers, I like to start by painting an "overview map" and then zoom in on the topic at hand.

My high-level view of all Software QA practices looks like this:

Testing mainly is home in the "Defect Detection" part of software quality assurance. And a sub-category of software testing are automated software tests.

Another view I find very helpful are the Testing Quadrants originally by Brian Marick, and published in "Agile Testing" by Lisa Crispin and Janet Gregory:

(from Lisa Crispin's Blog)

Lastly, when talking about functional test automation in particular I find the testing pyramid makes explaining some aspects of this complicated topic easier:

There are different interpretations of the testing pyramid, but let's keep it simple here.

I will not go into detail in this blog post and save if for a later entry.

What I want to emphasize here is that test automation is a broad and interesting topic. Unfortunately, I often see test automation be reduced to a small subset of the maps you see above. Particularly, some vendors sell their product as the one you need to solve all your quality concerns.

And many inexperienced test engineers do equate E2E testing with test automation. Which is a dangerous thing to do when suddenly you find your test strategy relies on only one small subset of automation techniques.

In one of the following posts I want to introduce a sample test strategy for a web application, which will take some inspirations from strategies I introduced and implemented for different teams.

I'll also share a few horror stories of testing disasters I have encountered in the past.

So stay tuned for the next entries!