I am trying to understand best practices for writing test cases and I have a question.

I am working on a complex web app that currently has about 10 pages and about 60 test cases of different complexities.

I have a regression test for accounts homepage where a customer logs in and can see all their accounts and balances. This test covers most if not all the possible account types and scenarios.

Now lets say we discover a bug where a customer with account type xxx always sees a balance $100 less than what they have and we fix that.

Should I write a new test case to test where the workflow involves logging into an account that has account type xxx and verifying their balance or should I simply run the regression test that covers that page?

My only concern with doing it the first way is that since we are continuing development, we will end up with 500 test cases in about a year.

Thanks...

CodePudding user response：

I would refrain from increasing the number of manual regression tests due to a bug discovered.

Instead, I would

1. Add understandable "how to reproduce"-steps to the bug ticket, so the dev can reproduce it and when fixed, you can verify it.
2. Encourage the dev team to add automatic tests, e.g. unit tests, that verifies that this issue is fixed and will guard it from being reintroduced later. Some dev's do this by default, yay.

In case #2 is not possible, I would try to embed a check in an existing test case, where it makes sense to do the verification that the balance has not unexpectedly decreased by 100$. Again I would only do this, if the bug is significant enough.

I've seen regression test suites getting cluttered by "ensure that bug x from march 2019 is not reintroduced". If you don't practice good regression test suite maintenance this will become a beast over time.

CodePudding user response：

Yes, I would recommend it to add a test case of a reported bug, because like this we will have to make sure that it does not occur again.