Are “Hard to find bugs” the responsibility of the developer or the tester

bugbug reportdevelopment-processprocesstesting

May be it seems an open question (or non-constructive according to stackoverflow standards) …. but I am asking if there's something rigid according to Software process standards addressing this topic ?

If there are one or more "Hard to find bugs" that need complex scenarios, extensive testing, very big or special data set to show up … Is this the responsibility of the developer or the QA ?

Best Answer

There is no single standard software development process with clear defined responsibility for everything:

On one side this is unfortunately, because it makes life harder. You have to organize everything in every project and agree on roles and responsibilities. If software is build for a customer, this could be part of the contract. And it will not always be so clear who is to blame for what, nor if there's anybody to blame at all.
On the other side, this is fortunate: every project is somewhat unique, and you have the freedom to organize things as best suits its needs, and experiment innovative approaches.

So who is to blame ?

The customer could blame the project manager
The project manager might blame the quality assurance guy for not having found it, or the developper for having worked carelessly
The quality assurance engineer could blame the customer because nobody told him about the real test scenario, or didn't provide representative test data. The customer might blame in return the quality assurance guy, because he never asked or he didn't check representativity of data. So quality engineer will finally blame software developper for his bad quality.
The software developer could blame the quality engineer because he didn't verify well enough. He could blame the architect or he analyst, for not having mentioned some specific circumstances (if he'd known, he would have prevent it from happening). The business analyst could blame the customer, and so on...
In the end, everybody could blame everybody else, and it'll be up to the judge to settle the case

But wait a moment.. judge ? case ? Well, ... I hope that before arriving to such an unsatisfying end all the parties will realize that they are on the same boat !

Quality is a shared responsibility. So in the end there's no use blaming each other. Everybody has to contribute to come to an acceptable outcome.

The only one who could be blamed in the end is the project manager. Because it's his responsibility to make people work together. And he/she should ensure that quality assurance is properly organized above and across the organizational boundaries. He has plenty of ways to do so, starting with the setup of the project life cycle (e.g. agile vs.waterfall), the organization of the stakeholders involvement, and the choice of the validation approach (e.g.TDD or traditional V-model validation), and facilitating team throughout the project.

Related Solutions

Fix bugs, or wait for the customer to find them

This depends wildly on the situation, the bug, the customer, and the company. There is always a trade-off to consider between correcting the implementation and potentially introducing new bugs.

If I were to give a general guideline to determining what to do, I think it'd go something like this:

Log the defect in tracking system of choice. Discuss with management/coworkers if needed.
If it's a defect with potentially dire consequences (e.g. your example #2), run, scream, jump up and down till someone with authority notices and determine an appropriate course of action that will mitigate the risks associated with the bug fix. This may push your release date back, save lives, wash your windows, etc.
If it's a non-breaking defect, or a workaround exists, evaluate whether the risk of fixing it outweighs the benefit of the fix. In some situations it'll be better to wait for the customer to bring it up, since then you know you aren't spending time fixing/retesting things when it's not 100% required.

Mind you, this only applies when you're close to a release. If you're in full development mode, I'd just log the defect so it can be tracked, fix it, and call it done. If it's something that takes more than, say, half an hour to fix and verify, I'd go to the manager/team lead and see whether or not the defect should be fit into the current release cycle or scheduled for a later time.

Acceptance Testing – Writing Effective Acceptance Test Cases

In my acceptance suites I have stayed away from using technology specific controls i.e for web applications don't use css dont use html elements if you need to fill in a form do the specifics in the steps to setup the SUT not the actual acceptance tests

I use cucumber for my acceptance and have the following

Given A xxx 
And I am on the xxx page
And a clear email queue
And I should see "Total Payable xxxx"
And I supply my credit card details
When I the payment has been processed
Then my purchase should be complete
And I should receive an email
When I open the email with subject "xxx"
Then I should see the email delivered from "xx"
And there should be an attachment of type "application/pdf"
And attachment 1 should be named "xxxx"
And I should be on the xxx page
And I should see my receipt

this example is back by a web application but I can still use the test to test against a desktop application as the steps are used to setup the SUT not the acceptance tests

this test sits at the end of a purchase which goes

Generate -> Confirm -> Payment -> Print Receipt

the test above is for the payment step the other steps are setup in other tests due to the application being able to setup into these states with data or http actions in this case the payment has a given which does the confirm steps and the confirm does the generate steps so they are a bit brittle at the minute

Best Answer

Related Solutions

Fix bugs, or wait for the customer to find them

Acceptance Testing – Writing Effective Acceptance Test Cases

Related Topic