How to find business related bugs early in software development practices?

Question

I'm working with good group of very sharp developers on one of my client's premises. We are coding correctly around NullPointerException and other exceptions, so we don't have those. But when it comes to business rules we have some mistakes and find issues when already in production. Granted we have very fast paced environment, and deployment to production commanded by management team, not development one. But we passed "green light" with QA and Data Quality teams.

What are the best practices to find business related bugs early in software development process.

Answer 1

"What are the best practices to find business related bugs early in software development process."

Several things.

1. Use Cases.

2. Overall Tests based on the Use Cases.

3. Unit Tests based on the Use Cases.

The important thing is to tie the system -- as a whole -- to real actors, real business value. It's too easy to focus on technical issues. To avoid narrow focus on technical issues, have use cases and test against those.

Answer 2

I've found FitNesse helps in many such cases -- essentially, to over-simplify, the users specify important examples of "input data" and what corresponding "output results" they expect, and the testing framework checks that the correspondence is correct. Check it out, it won't solve every problem of wrong business rules, but it will help with many.

Answer 3

User Acceptance Testing focuses on these sorts of issues.

Answer 4

As a compliement to akf's answer, I would like to recommend a comprehensive guide, User Stories Applied.

Answer 5

User stories/Use cases should be specific enough to determine Acceptance critia; The acceptance criteria should include all business rules to prevent the situation you describe, and if your Unit Tests are just testing technical capabilities they are insufficient.

Can you learn from those incidents you mention, why they weren't covered in those artifacts?

Also, in my experience, this is the #1 benefit of continuous integration and "Deliver Early and Often" - you should not discover invalid business rules more than a day or two after the functionality is coded.

Answer 6

Close interaction with someone who is knowledgeable about the business. I find that simple flow charts work well -- these can represent use cases in a diagrammatic form that is easier for the user to understand.

It is also important to have early and frequent interaction with the user - determine all the data requirements at each point of the use case, where the data comes from, constraints on the data etc. Use cases using sample data are useful for detecting misunderstandings here.

It also helps to have an early prototype. Powerpoint is good for this, as it doesn't tempt you to start "coding" at an early phase.

Answer 7

The best way I know of to catch business problems early is to listen carefully, and ask lots of clarifying questions, up front. "Do you mean...?" and "what about...?" might slow a meeting down, but it can get a lot of information out onto the table quickly. It sounds like the QA and data quality people need to be in the room during these conversations.

But if it's the customer's QA and data quality people who're signing off on stuff that you later find isn't right, they have a problem, too, and as a vendor/contractor/consultant, it's not a problem for you to solve (beyond pointing it out).

Answer 8

If those business rules can (without too much effort) be expressed in code, "Design by Contract" might be usefull in your situation. Use assertions to make sure every part of the program plays by the rules.

Answer 9

Your story cards should have

• acceptance criteria

which will drive the creation of

• test driven unit tests (write the unit tests first)
• automated functional tests
• full regression test run at least daily (if not at every check in)

Also, all User Acceptance Test, designed by the business, should be captured in your automated functional tests.

If your developers use

• pair developing
• test driven development
• continuous integration
• refactoring

then such practices will drive defects to zero or near zero during UAT and in production. Defects found in UAT or production will be the exception. If you do not follow theses practice much of the teams velocity will be lost and spent fixing defects. We have found that if a defect found in development cost 1x, the it cost 2x to fix during functional test, 3x to fix during UAT and 4x to fix if found in production. As you can see, driving defect to the left (earlier in the development life cycle) more than pays for itself.