0

Recently I've heard a lot about automating test is taking away manual jobs from the QA sector.

When I look at example of what it is about most of it is just running a sequence of functions over and over to make sure it ends up in same results or other similar kind of tests.

What exactly is groundbreaking there? Couldn't a tester write a script to automate that himself? Are testers really only qualified to just be a button pressing machine?

I am by profession a programmer and that too barely at an intermediate level, but even I sometimes automate code generation, boilerplate for example, where a pattern exists. In short why was automation in testing not common since 80s?

  • 1
    automating test is taking away manual jobs from the QA sector How is this different from the recurring argument that "automated [foo] takes away manual [foo] jobs"? Because that is inherently the point of automation. – Flater Oct 23 '18 at 8:37
  • Testing and QA Testing are not necessarily the same thing. Anyways, testing is (or use to be) a repetitive task. And everyone knows who is the best at doing repetitive tasks when it comes to human vs machine and cost vs benefits. – Laiv Oct 24 '18 at 9:32
4

It is opinionated question of why there is such percieved increase of automated testing. Especially automated testing done by developers, not testers. Automated testing is as old as software development itself. It might have something to do with raise of agile or maybe with percieved success of automated testing at big companies like Google and Netflix. Managers and businesses might starting to realize it is actually cheaper to invest 25% developer's time to create good automated tests than 100% of testers time to test the application every time realease is needed.

One question you pose is what is purpose of tester in this environment. First, even if testers create automated tests, the tests are often inneficient. Testers often only interract with the application through same API as user does, which is usually some kind of GUI. And tests going through GUI are notoriously hard to implement, slow to run, and easy to break. Testers don't have access to APIs that developers have, nor will they make use of fast feedback the tests provide.

At the same time, testers "clicking" step-by-step through GUI to test according to some kind of test protocol is almost immoral. I once heard it compared to modern day torture. Being mind-dumbing and monotonous work, no sane person would wish on someone else.

Instead tester's primary job should be to actually break the application with novel ideas. Tester should not be testing if application is working as it was working week ago. That can easily be automated. He should be testing if there are ways the application can be used that produces incorrect or unexpected results. Tester should be emulating a user who hasn't read the manual and doesn't know how to use the application, but still tries his darnest to make it work, somehow.

  • 4
    "Tester should be emulating a user who hasn't read the manual and doesn't know how to use the application, but still tries his darnest to make it work, somehow." or emulating an attacker who has read the manual and doesn't care how to use the application, but still tries his darnest to make it work in a very specific way not intended by the developers, somehow. – Jörg W Mittag Oct 23 '18 at 6:52
  • @JörgWMittag "Never attribute to malice what can be explained by incompetence" - Hanlon's razor – Euphoric Oct 23 '18 at 7:02
2

Aside from the other excellent answers, there are two other factors that I believe are relevant here:

The squeeze on testing time

Whatever the methodology, testing comes at the end of the development phase. If development overruns, the temptation is to reduce the amount of testing time. Regression testing can form a large part of this so it makes sense to build this into the process so that developers can run these ad hoc, or better still - have them run with every build (given how cheap hardware is these days).

The importance of failing early

It is taken as read that it is good to "fail early" for economic reasons. However, it wasn't that long ago that the role of testing was seen as an extravagance in some quarters. Any bug found was deemed to be down to a programming mistake that could be circumvented with better programmers or by using stick or carrot to drive the bug count down.

This fallacy has thankfully fallen away with the realisation that programmers and testers, while having the same end goal in mind have different mindsets: the programmer just wants something to work while the tester wants nothing to break.

1

Software economics happened.

Computers became ever faster and cheaper, while wages rose. In the 1980s it was very often better to hire someone with minimal skills to do repetitive tasks than to let a computer handle it, not because the computer couldn't do it, but because computing hardware and time was rare and valuable. The idea of quickly firing up another virtual machine or even buy another slice of online computing power didn't exist back then.

Pressure to cut costs rose slowly through the various economic crises, and at the same time that people got more expensive, computers got more available until now they're ubiquitous. The message took a while to percolate to the topmost decision makers, but now we live in a wave of automation that hasn't peaked yet.

(Note that economics is about marginal costs and about comparative outcomes, not about absolute figures. It's perfectly possible for human compensation to fall and still be uncompetitive because the price of computing power falls even faster. For a lengthy time, this is precisely what's been happening.)

  • I have heard some accounts of automated testing being used effectively by developers way before this kind of economics became obvious. – Euphoric Oct 23 '18 at 6:19
0

Couldn't a tester write a script to automate that himself?

No they couldn't. Although I would disagree with your use of 'recent'.

In the old days a tester would just be an experienced user of the system with a day job who is assigned the job of checking everything still works as it should because they 'know the system'

Then we moved to dedicated testers who would manually write and run test cases and record the results.

Now Testers are expected to be able to program automated tests, the separation between tester and programmer has all but disappeared in terms of skill set.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.