9

What could one developer do to change the attitude towards testing in a company where testing is considered a second-class citizen?

I'd like to keep this question generic, but, if details are needed, by "second-class citizen" I mean that tests are very likely to be ignored and code reviewers are generally okay with not having unit-tests as a part of a change request most of the time.

The general reasons for not including unit-tests are usually "not enough time", "this is something we need to show to the customer asap", "nobody before me added tests for this". The latter one especially has a cascading effect.

Another problematic part is that testability is not being brought up while talking through the design and architecture of a new feature or project.

I consider this a problem and would like to do something about it. We are accelerating, producing more and more untested code which often leads to non-testable and non-modular enough code design and growing technical debt.

Improve this question
7
  • Did it lead to some undesirable consequences in production? Or you're just saying about possible issues which might be caused by this situation?
    – Alexey R.
    Dec 14, 2018 at 14:32
  • @AlexeyR. I am not aware of a specific production problem that could have been explained by the lack of proper tests at some point, but I am sure we are getting there at this pace :)
    – alecxe
    Dec 14, 2018 at 14:33
  • What is the release frequency of this product?
    – Vishal Aggarwal
    Dec 15, 2018 at 22:42
  • There are companies now who do code drops in every few seconds in production... part of the answer is they have solid testing practices in place.
    – Vishal Aggarwal
    Dec 15, 2018 at 22:45
  • @VishalAggarwal well, here I tried to stay generic even though I understand that release frequency is one of the indicators may be needed to better answer the question..In our case that's multiple products and services with different release cycles. Thanks.
    – alecxe
    Dec 15, 2018 at 22:50

3 Answers 3

Reset to default
10
+50

There has to be some sort of pain point to make Management and front-line employees aware of the need for testing. How your company does that depends on how mission or life-critical the software truly is. The typical Developer/Tester ratio in an unregulated development shop is anywhere from 4:1 to 8:1. NASA uses a ratio of 1:8. That's right, each Developer has 8 Testers.

Life-critical software like medical devices are regulated by the FDA and each requirement has to have a documented link to a test case and to a test case outcome. If this documentation does not exist, FDA marshals can perform investigations until they are satisfied and lay charges. The company may not produce or sell a single thing until the investigation is complete. There are cases where the investigation took so long the company went bankrupt and closed up shop.

Testing is an insurance policy. As such it has no ROI. It's like asking, "What is the ROI of your auto insurance?". You have it not because there is a problem, but because there might be a problem and you want to be protected if something does occur.

If your company is merrily moving along building software that satisfies the customer without the overhead of testing and there are no negative repercussions, good for them! They will probably continue to do so until there is a pain point.

How can you change the culture? Culture change is difficult. Since the business is humming along nicely without the overhead of testing, there may not even be a need for a formal testing group or test procedures. You have already indicated that front-line workers have great excuses for not creating unit tests. Does Management feel the same way? Ask your boss and your grandboss for feedback on whether or not they care. If they don't care about a lack of tests and test procedures, you will find it nearly impossible to change the culture. You may have to seek a culture that is more aligned with your own.

If you want to start changing the culture yourself, start with yourself. Create a unit test repository. Create unit tests for everything you develop. Share that repository with all the other developers. Create a document that describes the procedures you use for creating and maintaining unit tests so that the rest of the company can use it when they are ready. Make your boss aware of these things. Keep track of the number of times your unit tests find an issue caused by you or someone else changing code. These are bugs that didn't get out into the wild. By catching them before public release your unit tests helped save company reputation. Let your boss and your grandboss know about these. Keep a public running tally, some sort of metrics dashboard that shows this.

Improve this answer
3
  • 1
    Absolutely awesome answer! My wishful thinking reads this as: start a change with yourself and apply for NASA :) Thanks so much, I've learned something new and now have a few things I need to start tracking and doing more.
    – alecxe
    Dec 14, 2018 at 19:25
  • 1
    Totally agree that all you can do is set a good example, and hope it's catching.
    – George M Reinstate Monica
    Dec 14, 2018 at 19:38
  • 2
    Note you’re at least initially going to be less productive than other developers who aren’t writing unit tests. However, eventually, you should be more productive, and producing better code. So you’ll need management support to accept that initial loss of productivity. And depending on where your software is in the stack, it may be very hard to demonstrate that your more reliable code is actually an asset, as the surrounding code will still have problems. Essentially, management needs to feel some pain from the lack of quality, and be persuaded that testing will ease the pain.
    – Kevin McKenzie
    Jan 1, 2019 at 17:36
2

Testing culture can only be changed with support of upper management. If management doesn't support you, then you won't be able to change the culture. So you have to make a case to management that testing should be prioritized. Try to build the testing as a part of the SDLC.

Otherwise, people will always cite deadlines and release cycles as the reason they can't get around to testing.

Improve this answer
1

Who Test Often, Release Often.

Proposed Solution:One needs to build a strong case for testing to project team/ management in terms of visibility.

I think the key lies in release frequency.This is something which is most tangible to the team(AND to the management) and can be used to make a solid case on investing & implementing solid quality checks in place in the form of automated unit/API/UI tests which are running on every check-ins and giving a quick feedback loop on builds.

Baby steps:How about a start with a small smoke suite(10 min) with solid coverage as a demo? which based on your current bug analysis will definitely give the most bang for the buck...

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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