Testing [is] Dead? Do I now cease to exist?

Posted By Duncs ~ 18th November 2011

There has been a lot of buzz around how the role of the Tester is changing in light of a more responsive & flexible development process (“Agile”, if you will)

The GTAC headline of “Test is Dead” is attention grabbing, but when you listen to views being discussed, they don’t actually say there is no future testing, only that its perspective has shifted. Unfortunately, some people don’t read past than the headline…

Nor is this a new concept for 2011 - the role of the Tester has gradually been shifting since the introduction of different approaches to programming, such as Test Driven Development.

I have seen a few videos recently regarding the state of testing and where the future lies :

Alberto Savoia’s keynote at GTAC 2011

Goranka Bjedov at STANZ 2011

(Uncle) Bob Martin on “Agile QA” 2010

 

As well as a few great blog posts :

Rob Lambert’s blog posts, & here & here

Stu Taylor’s blog

Eric Jacobson’s blog

Scott Barber’s blog

Ben Kelly’s blog (thanks Phil K!)

Cloudspace’s blog

 

And discussion threads:

Software Testing Club

 

This post is not about criticising the content of videos (I enjoyed all of them, they had some great takeaways for my consideration), blogs or discussion threads but is more about me trying to understand what their implications are for me & what I need to take forward in order to remain as a “Tester”

The content of the videos is largely concerned with how companies are not adopting a testing phase after a development phase due to preference for speedier software delivery over quality software. Perhaps they’re actually referring to the death of the test phase?

So my current client is adopting an agile approach to software development - we try & follow the key principles of the Agile Manifesto such as conversations, working software & flexibility.

Part of the process is continually pushing the evaluation of the software further upstream - that is we use Continuous Integration (CI) to run automated regression checks against frequent check-ins of code.

These automated checks are run at low level - very, very limited GUI checks involved here. This is because GUI checks are deemed ‘expensive’ in a CI environment, so only the really necessary GUI checks are retained.

The rest of the checks are run at unit, container & integration (predominantly with DB) levels. These take care of the mundane logic testing & include the boundary checks, max character limit checks & error handling etc. All these checks run against stubs or mocks (fake versions of integration points)

If all these checks are being run against the code, where does that leave us Testers? Sounds like we’re just sitting on our thumbs.

What actually happens is we help with evaluating the software further upstream. Bob Martin says it well in his lecture - Testers in an agile environment are “Specifiers” as opposed to “Verifiers” - We don’t sit at the end of the develpoment lifecycle waiting for a load of software to be dumped on us, we get involved early & help to specify what gets developed.

Just for clarity of understanding, we refer to software currently being developed as “features” - a specific piece of code to solve a Business problem / need

Heres a high level overview of what We (Testers) get up to when ‘testing’ software :

• We help specify what the feature should be with the Stakeholders, BA & Programmers prior to development commencing - Requirements & Acceptance Criteria
• We help define how the feature is to be developed with the Programmers - break the feature down into discrete, testable tasks & determine the order in which code for the tasks will be (frequently) committed
• We help define the suite of automated checks required to help prove the feature meets the stakeholders requirements with the Programmers
• We help define at what level the automated checks should run with the Programmers - unit, integration, container or browser
• We prepare exploratory test charters & sessions based on the previously defined tasks
• We receive a demo from the Programmers when they complete a task on their local machine - We then have an initial test of the code & related checks on their machine to iron out any obvious problems
• We run exploratory test sessions of the committed code against our integration environment to flush out any integration bugs
• We demo each task / collection of tasks to the BA when we’re happy with the task/s
• We demo the feature to the Stakeholders when BA, Programmers & Testers are all happy with the feature
• Programmers & Testers branch the code containing the feature & release the future to Production
• Programmers & Testers pair in order to fix bugs

As well as testing the software, we also get involved in all manner of other activities :

• Retrospectives - for the past fortnight or significant incidents
• Estimations - so that the testing perspective of the feature is not forgotten
• Inceptions - what are the Stakeholder high level requirements for the next range of products
• Team building, brown bags etc - we are encouraged to consider our self development as well as delivering software

 

So how does this tie in with “Testing is Dead” & my so called career?

Comparing what I do now with what I did on previous clients sites, I can see the point the doom mongers are making - In the ‘new’ development lifecycle, the focus isn’t so much on quality - its more on speed of delivery.

Its seen as better to get working software out as quick & as cheap as possible. Having a dedicated testing period is soon too expensive & inhibitive to frequent software releases.

It is deemed cheaper to fix bugs found in Production than to spend time trying to discover the bugs in a testing phase. This is because it is so cheap (easy) to do more frequent releases.

 

From having seen both sides of the same story, I really prefer my role now compared to the role I used to fulfill. Its a lot more engaging, fast-paced & (buzz word alert) empowering. I really feel part of the bigger team, as opposed to a separate department, and my opinions & views are taken into consideration.

Its my job, as well as everyone elses, to help get software out of the door rather than be a gate keeper to quality. I still have my independence & my integrity. In fact I probably have more - I help to identify problems sooner rather than later, while the Programmer is still focussed on the same feature (maintaining their context). I find the Programmers more responsive to bugs if they are still working in that area of the code - compared to when bugs used to be brought to their attention days/weeks/months after they wrote the code.

I heard a great quote from a Tester, I can’t remember who, who believed Testers are like a nag following a window cleaner as they do their job saying “you’ve missed a bit…” Wouldn’t it better if we helped them not to miss bits in the first place?

 

As Testers we need to adapt to our changing surroundings, and this includes proving our worth to ensure our place at the development table. If we continue to be adverse to change then the Test Team will continue to be seen in a negative light. Its not a great leap from here to having no Test Team at all.

So I feel the act of “Testing” is not dead, only that the role of the “Tester” is changing. It is in fact the “testing phase which is post development and pre production” which is dead - Which isn’t necessarily a bad thing (IMO)

UPDATE 20/01/2012

More resources discussing the testing is dead topic:
TWiST #76 - Test is Dead, Part I
TWiST #77 - Test is Dead, Part II