The testing team is blamed while raising defects when the release is near

Quality assurance
Software development
Software testing

We are in the last stage of our testing cycle and we are raising defects. However the developers are blaming us that why didn't we find them earlier and why now when the release is near??

I told the, I can't run the regression blindly and some part of the testing is devoted to exploratory testing, otherwise we will not be able to find defects. This is what we have practiced in all the cycles.

Now when I identify a defect I get scared on if I should this raise or not. I know that this is no fault of mine.

Please advice.


Answer Wiki

Thanks. We'll let you know when a new response is added.

Tell the development team that if they had done it right in the first place there wouldn’t be any faults to find this close to release.

If they really don’t want you to find faults, stop testing.

Discuss This Question: 7  Replies

There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.
  • carlosdl
    The time to correct bugs must be included in the project plan. This situation seems to imply that no time for bug corrections was planned, or that the project is delayed and the team was hoping/assuming that no bugs were going to be found, which is always a mistake. Experience from previous projects with the same team could help the project manager make a better estimation of how much time he/she should schedule for this task. And of course, you must report (and document) all bugs/defects. Your reputation is at stake. It is better a delayed product than a defective one.
    85,865 pointsBadges:
  • Sunsetrider
    This is not the time to point fingers. You must say 'we' have found these issues and 'we' need to work together to get them resolved. In large 'systems' development, there should always be a plan for testing. Usually, it consists of unit testing (application programs), integrated testing (multiple function streams), and again, depending on the size of the project, system testing (bringing up system, testing applications, stopping system, backups, etc.). All of the 'testing' functions can be used during each test phase (modular testing). You have a responsibility to your employer, as well as yourself, to sometimes take the rough road and face the storm(s) by yourself. Your integrity is perhaps your most important asset. Good Luck
    860 pointsBadges:
  • TheFinder
    They should be thanking God or more local the test team for them finding the faults, just think of what it would be for the company if they didn't find them. lol.
    1,940 pointsBadges:
  • Allnash
    Testing never stops!!! (In the real world or work place it happens when the PM or Test Manger makes a call) So as a Tester you have to do testing (what ever type of testing) and raise the issues/bugs. Remember no one likes if finger pointed (Not even you). So get all the information in the bug. If possible approach and tell the developer that you were doing so and so different from the previous time which resulted in the bug being discovered. Be polite and help as much as you can to resolve the issue.
    10 pointsBadges:
  • Kccrosser
    There are several ways where the test organization can create friction with development: 1. Lack of a test plan results in ad-hoc testing, where problems are found at random, often near the end of the release cycle as testers become more motivated by the deadline. 2. Detailed testing doesn't start until late, resulting in late discovery of defects that could have been found earlier. 3. Found defects are not reported promptly, so they "appear" late in the release cycle. A good test organization will avoid these pitfalls by developing and following a formal test plan, testing as early as possible, and reporting found defects in a timely manner. The product test plan must be done concurrent with (and as part of) the development plan. Most "defects" should be weeded out before they get to the actual test team - unit testing by the developer, and integration testing by the development team should uncover problems and fix them before formal testing begins. Has anyone categorized the defects? It is often very useful to understand what caused a defect, so the root cause can be addressed for the future: Missing/ambiguous/incorrect requirement definition? Functionality does not match documented requirements? Code bug? If the bugs could have been caught by the developers or if the code fails to perform per the specifications, then the developers have no one but themselves to blame.
    3,830 pointsBadges:
  • Batman47
    Don't be afraid to advise the Managers that the release needs to be delayed until the bugs have been worked out. IT needs to identify and correct all bugs before the users find them. Otherwise, you could have people in IT get fired when you go live. So, don't let emotions prevent you from doing your job. Great question to ask.
    1,050 pointsBadges:
  • Featured Member: Sunsetrider - ITKE Community Blog
    [...] The testing team is blamed while raising defects when the release is near [...]
    0 pointsBadges:

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

Thanks! We'll email you when relevant content is added and updated.


Share this item with your network: