Is testing dead?

James Whittaker tweeted:

My updated take @esconfs is that if you are still concentrating on testing then you are doing development all wrong. Test is dead.

— James Whittaker (@docjamesw) January 15, 2016

The short answer is: Testing as activity is not dead.

Testing like we used to in the 20th century should be dead, but is not.
In an Agile team there are more/better unit tests and with prototyping and early involvement of users functional testing becomes less of an activity performed by testers. Arguably tester as seperate role could be dying. But that is not my perception or experience.
Testers now are much more technical savvy. They have to be.
Since we mostly work in Agile teams the testing role has changed.
So let us focus on the team. An Agile team is not a team of some generic designers/developers/testers blended into one entity. It is a team of specialist.
We have UI-specialists, performance specialists, data(base) specialists and, yes, Testing specialists.
As part of the development team our activities have changed and include coaching developers, risk analysis, end-to-end testing activities and more often than not involves specializing in one of the areas like test automation, security or performance.

So a seperate test organization that receives software and performs tests on them?
Yes, that testing is (or should be) dead. It is outdated and does not deliver the quallity we demand.
Testing as specialist activity in a team? Not dead and probably will be around for a while.

So where I disagree with Whittaker is that he assumes that tester as role is dead and that testing activities will magically be done by others like developers and users – who in reality will be unable to see beyond their own horizon.
Testing activities are here to stay – and so are the professionals who are best suited to perform them.

Characteristics of an excellent software tester

Learn to code! If you ever want to grasp the intricaties of the product you NEED  to be able to read and understand code

Be curious – try to find out everything about the product under test

Be a fast learner – the ability to grasp the essence and do it quickly is very important

Be technical, we live in a connected world – your application is unlikely to live in a disconnected universe. Grasp the risks and test for them

Think out of the testing box. Yes requirements and the client are all very important but think beyond that.

Learn to automate tests. If you want to be included early you will need to do something for the coders – provinding an automated test environment with automated tests might just be the ticket to inclusion into the inner circle.

Learn to code!

Characteristics of a bad software tester

1- The I found a bug bot. This person stops at the first sign of a bug and directly files his bug report. Don’t get me wrong filing bug reports is very important – how else can bugs be fixed? But a little investigation into the own test or environment could make a big difference in filing VALID bug reports.

2- The I-am-not-a-programmer: I don’t know how to code, I don’t want to know how to code, that is the programmers job. This person does not understand the technicalities of the software under test or the technical implications of the bugs he/she stumbles upon. At best the person behaves like a user functionally looking at the software, at worst the person revels at placing v’s in checkboxes.

3- The I-need-all-the-documentation-or-I-can’t-test: Some people get stuck in the test basis intake steps. They have no imagination and can not just start testing based on the product, code and information from the programmer. This tester believes that the world (or at least the company) will end if not everything is in place before the person begins with any testing activities.

4- The ugly: My tests work, but:
I can not write a decent bug report
Most of what I write boils down to “It does not work.”
There is no investigation.
No consistent testing convention, or reporting convention, or communication.
Bug reports all over the place, etc.

5- The short term investor: The person tests. The person files reports. The person moves on. No attempt to learn the product, code or developers. You get tested software but nothing more is achieved. There is no knowledge added to the team.

6- The protester: The code sucks, the test plan suxks, I can’t do this, let somebody with more technical, domain, or any other knowledge tackle this. I hate this (ten times an hour).

7- The dictator: My way or the high way. It’s their “ideas” vs “your ideas”, not “project ideas”. It’s their solution vs your solution. I bet there will be an argument for sure. Somehow they will keep coming back to a test that you performed. This person is a big bottleneck to productivity and will be the first person to crumble under pressure and start pointing fingers. This person is not good for the team, however experienced/good a tester he may be.

8- The overcautious: The testers that freeze if not all requirements are set in stone. The tester that panicked when learning that not all documentation is available. The tester that cringes at not having 100% coverage (code-, functionality-, or anything else). These people will do anything to avoid getting out of their comfort zone. Good testers show a tendency to slowly/swiftly move out of their comfort zone in exploration.

9- The careless: Forgets to take a backup, snapshots, can’t reproduce bugs etc. This is a newbie tendency and gets better with more professional exposure.

10- The lazy software cracker: They pride themselves at using the latest tools and methods to test complex software. “This fourth generation, behaviour driven, automatically self testing software tool will solve all our quality problems!” 99 out of a 100 times this is a pose. They will invest a lot of time in getting the tools / environment ready and then it does not work without a lot of new investments. Getting the software ready and tested will cost much more than having tested it right the first time.