How can I start testing in a testing anticulture?

Question

I have a confession to make: Formalized automated testing was never a part of my programming background. I now work in a very large company with many developers (most of them web developers of one sort or another), and it's apparent that most of them don't test* either. (*I'm not going to keep saying formally; please infer it.)

If I wait to have the support of my organization to begin testing it will never happen. If I try to "change things from the inside" by pushing testing at management I will run out of steam before change happens. I need to start testing now.

But with TDD and its ilk I'm going to end up with lots of testing code right along with the production code. Our version control systems (all centralized) aren't organized for storing testing code. I'll have to find a place for all that on my workstation.

Is it possible to begin a personal practice of software testing in a culture that doesn't value or provide the tools for it? What techniques and tools do you use to enable you to test when the official tools and organization don't have a place for tests, frameworks and automations?

Answer 1

I've personally done this with considerable success. The key factors for success:

• Get (tentative) management support. The advantages of automates tests are well-documented and should convince any manager to at least try it. That includes finding a spot in the VCS and a build server, because
• Automated tests only provide their full value if they are run frequently and automatically so that you know about problems soon and don't have to rely on people not forgetting to run them. You need a build server that runs them at least daily. This can be an old workstation. Jenkins takes very little work to get running.
• Lead by example. Write tests, talk about the benefit they're providing to you, and when they reveal errors introduced by other developers talk about it in terms of how they were protected from potentially much greater embarrassment.
• Go for the low-hanging fruit. Some parts of the application will be hard to test, others easy. Some will be robust, others brittle. Writing tests for brittle, but easy to test parts provides the most value in the shortest time.
• See if you can write reusable tests, e.g. that test conventions or features that all modules (web pages, REST services, whatever) must have but which is often forgotten.

Answer 2

Without management support you are dead in the water. Management will claim that you are not doing worthwhile work, you will get penalised in your reviews, and finally you will get fired. There are ways to bring management to see that early testing costs them less and all that. It is possible to change the culture but you are putting your neck on the chopping block.

I would suggest reading Machiavelli The Prince chapter on how to introduce change before doing anything.

Answer 3

In my experience if the culture is anti-testing, you can't reasonably introduce it. Either the tests will be seen as a waste of time and you'll be reprimanded for "wasting time" or "taking too long", or the code has festered from years of not being written in a testable way (e.g. no interfaces, everything tightly coupled) and you'll have to spend a lot of time refactoring and/or rewriting code (thus running the risk of "taking too long" and "wasting time") to make it testable so you can write tests in the first place.

You might have a chance if you're doing greenfield stuff that only has to interact with existing things (create a nice wrapper around the bad areas) or if you can do it in small quantities where it won't cause issues or require you to "work on tasks not assigned to you" which can put you in the doghouse.

Answer 4

I don't think you'll get very far until you can make a good enough case that there's a problem (that may not currently be recognised) that automated testing can address.

If there's a culture of manual testing against defined scripts, then there's a cost of executing those scripts coupled with a risk of incomplete or inaccurate results. There may be a history (documented or in "war story" form) of this. Suggest a pilot project to automate some of those manual tests with a view to delivering a long-term cost saving.

If there's not even a manual testing function then I'd suggest that the business doesn't perceive that any kind of formal testing, automated or otherwise, has value. In that case I'd consider the road ahead to be long and steeply uphill, but again it's likely to need a clear demonstration that the business can benefit from adopting a less casual approach to software quality. If you can't do that then it's hard to see how there could be any support for the idea on commercial grounds.

Answer 5

One idea is that you aim to write a test that proves that code that someone else has written is faulty. Should sell the concept.