This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.
Testers, Orgs, and the demand for Java jobs
In agile product development (or any responsible product development environment), people don’t just talk about high quality, they are passionate about it. Think beyond software…companies build marketing strategies around quality. Fruit of the Loom, Zenith, Toyota…all have marketed solely around quality. But for far too long, software development processes in general have treated testing as a second class citizen. Have you seen any of the following scenarios?
- The organizational view that ‘anyone can test’ – evident by ‘power users’ becoming testing leads without any software background
- Team growth due to a high amount of product maintenance / support
- View on testing, sometimes from director of quality, that testers should just be given finalized specifications and file defects (and track) against every bullet point
If you have witnessed any of the above scenarios, then you have seen firsthand a testing environment in a sad state. I can’t wave the magic agile wand and change the world – I think you need a couple hundred kids holding hands and drinking Coke to change that. I will, however, give some ideas on how we can start righting this ship.
Respect testing, and make it evident by hiring practices and job duties
Testing cannot be viewed as ‘entry level’ into agile software development. It is not the place to bring the director’s kid in to learn ‘how the real software world works.’ It is not the job for the secretary that has been very loyal for 5 years but now wants a little more pay.
To have great testers, start off by respecting the role and only hire great testers. People with experience in positive as well as negative testing; people who care about your users and know their experience. With a position that you respect, you simply won’t expect the person in that position to repeat mindless tasks. Expect them to master their domain and be able to automate mundane and repeatable tasks. The kids that didn’t want to learn were the ones that stayed after class washing the erasers – the kids that learned went on to explore more fun and interesting topics. You want people with the same passion for testing – they have the curiosity and desire to get outside the box fast, learn, and try to break the system. Finally, make these people part of the discovery process as a complete member of the agile team throughout a project. The best discussions I hear are when a team is talking scenarios upfront in regards to a product. ‘What should happen when…’ ‘Wouldn’t this make more sense?’ ‘What about if this one really weird thing that happens all the time happens?’ A great tester brings another critical view to how a system should be experienced.
Should testers know how to code? Would you want to drive a car that was fixed by a mechanic that couldn’t drive? Testers don’t need to know how to write the code for your product, but they need to know how to best automate their tools and tests which will require understanding and comfort with code.
Have product support issues? Don’t hire more developers, hire more / better testers
Did you see this article about the demand for Java developers? Long story short, it was a survey of people in hiring positions and it ‘revealed’ a 58% increase in the demand for Java developers. There are plenty of articles published recently with similar patterns. Is it real? Yeah, probably. Do you want to know why there is such a demand for Java developers? Because there is a ton of Java developers (and developers in general) out there being hired that aren’t focused on quality or sustainability of code. The cost of supporting and maintaining apps, regardless of language, written by irresponsible developers will quickly drag to a near halt an organization’s ability to complete new projects. What else can organizations do but hire more developers? ”All of our developers spend 50% of their time doing production support….lets hire more developers….And make sure they know SOA and ESB!’ Yeah, that will fix it.
I am convinced that once the we start respecting testing more, forcing back quality issues to irresponsible developers sooner and holding them accountable….the demand for developers will start to become more normal. In most organizations, testing is an afterthought. Problems are not prevented, they are found and often too late. When you have enough great testers, that model changes and you start actually preventing problems, which lowers the cost to support applications as well as the need to hire more developers.
There are amazing companies making money hand over fist with a small delivery team. How can they possibly do that? They respect quality and they only hire top quality-focused individuals.
Last but not least, let’s get rid of titles
My buddy Steve Ropa has mentioned a few times how developers change in agile, as well as a need for a reflection on words and titles in a team. I couldn’t agree more. Let’s get rid of the titles of ‘developer’ and ‘tester.’ Testing is even more misunderstood by recruiters than development. Throw in the towel. Let’s hire great technical resources that communicate well and understand how to work on agile teams to create something great. Some may focus on code to create the product while others focus on code to prevent problems. Everyone will focus on ensuring quality and to the greatest extent they can, discovering ways to make their product better as soon as possible.