0

I am part of a new dev team that is assigned to work on a legacy app. The app currently has no regression or automated unit, integration and system tests.

Due to technical debt and convoluted architecture, automated unit tests would be difficult without refactoring the code. However refactoring code is not a something management wants to invest in.

I want to reduce my chance of breaking the system by creating a comprehensive list of manual regression tests for the suite of use cases that the system can perform. This way I can determine if any major functionality is impacted by a change.

However making this list would be time consuming. Is doing this worth the time investment?

The alternative is to do try to develop carefully, functionally test, and pass it on to QA and hope for the best. Not quite comfortable about the second option.

Improve this question
4
  • 4
    Maybe not in the way you're thinking, but adding tests certainly makes sense. Check out "Working Effectively with Legacy Code" by Michael Feathers. It's a practical guide to dealing with your exact situation.
    – bitsoflogic
    Feb 5, 2019 at 17:28
  • 1
    I would go as far as say Feathers book is the answer the question. Given the answer to the question is a book, the question is too broad for SE format, so voted to close.
    – mattnz
    Feb 6, 2019 at 7:43
  • I always thought that refactoring the code would be difficult without unit tests, not the other way round.
    – mouviciel
    Jan 5, 2021 at 6:57
  • How is it that the company has already decided to not invest time on automated unit tests, but would somehow be completely fine with investing time on manual testing? Time is time, wage (and thus cost) would be the same.
    – Flater
    Jan 6, 2021 at 11:12

3 Answers 3

Reset to default
2

Is doing this worth the time investment?

This cannot be answered by someone who doesn't know the context. There are many unknown factors here:

  • How critical is a regression? Can faulty production code kill someone, or is it at worst having to send an email to have a bug fixed?
  • How easy is it to change something in the codebase without breaking it? In other words, what are the odds of regressions popping up?
  • Is development/maintenance ongoing, or are you near the final delivery?
  • ...

Cost/benefit analyses are best left to management (albeit that I do expect them to ask for observations from the developers). You, as a developer, are not authorized to make decisions that affect the company's budget allocation or financial future.

It seems management has chose to not invest time in safety padding. Maybe that's a naive choice, maybe that's an informed choice. Who knows? Management does.

At best, you can pick it up with them and ask them if they have considered the risk of having to deal with regressions that turn development into a whack-a-mole game.

But in the end, the decision rests with them.

The alternative is to do try to develop carefully, functionally test, and pass it on to QA and hope for the best.

If management's decision is final; then you can mention that this is the only way you feel confident about further development in order to avoid time wastage on regressions. This again is a decision that management has to make: do they sign off on the slow-but-steady approach you're going to be taking, or are they explicitly telling you to rush it?

Very simply put, the responsibility of the decision lies with the decision maker. If management overrules your professional opinion, so be it. Do what they tell you to. And if it blows up, do not accept the blame for a decision that you argued against specifically so it wouldn't blow up.

Improve this answer
0

So, in other words you want to pass the "burden" to the QA group ? What do you think that they will do ? Either they will keep pass it and sadly the customer will have a bad experience as the tester of your "engineering effort" (and stop using your software), or that the QA will sit down and write this tests for you only to keep bouncing bug-reports back to you.

When working with legacy code; writing tests to assert past behavior is a very good way to gain confidence before changing things in the code. (If you add a new feature or even try to refactor the code, and a test asserting past behavior fails it can gives you an insight to what this code segment does)

To sum-up; it'll be best to automate this tests so you can run them continuously (and gain confidence in your changes, however small) and you should explain to your management that refactoring for automated testing is a necessity in this case.
Otherwise, you should write at least this manual regression tests and do them.

Improve this answer
0

Have a discussion with QA about what and how they are currently testing. It's a legacy app, so there a very good chance test plans are already prepared. You could then prioritize or edit them.

Either way, if management does not understand and appreciate the importance of testing, there is really not much you can do apart from changing the project or the company.

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.