Manual Testing
About Lesson

Customer gives requirements – developers are developing the s/w – testing team is writing test cases looking at the requirements

Developer develops the product – test engineer starts testing the product – he finds a defect – now the TE must send the defect to the development team.

He prepares a defect report and sends a mail to the Development lead saying “bug open”.

Development lead looks at the mail and at the bug and by looking at the bug . he comes to know to which development engineer developed that feature which had a bug – and sends the defect report to that particular developer and says “bug assigned”.

The development engineer fixes the bug – and sends a mail to the test engineer saying “bug fixed” – he also “cc mail” to the development lead.

Now the TE takes the new build in which the bug is fixed and re-tests it again – and if the bug is really fixed

  • then sends a mail to the developer saying “bug closed” and also “cc mail” to the development lead. Every bug will have an unique number.

If the defect is still there – it will be sent back as “bug reopen”.

“REJECT” BUG

 Now, when the TE sends a defect report – the Development Lead will look at it and reject the bug. Bug is rejected because,

  • Misunderstanding of requirements

 

  • While installing or configuring the product – wrongly configured or installed the product and we found a bug in the product – send it to development team – developer says “reject” because he looks at the defect report and comes to know that the Testing team has not installed the product 
  • Referring to old requirements

Chances are there that Testing team may be referring to old requirements while testing the product.

For ex, – in the 1st build – developers have given the product for testing in which a sales link button is there, test engineer does testing and reports any defects – in the 2nd build, customer has given a requirement change to the development team where-in he has asked them to remove the sales link button – but the testing team is not aware of this change – so when the development team gives the new build – obviously they would have removed the sales button – test engineer when he looks at the feature – he is referring to old requirements which has sales link button – but in the new requirements it has been removed which the test engineer is not aware of – so he reports a bug – development team then reply back saying “refer to new requirements in which sales link button has been removed”.

 

  • Because of extra features

Here, “help” button is a feature which has been developed by the developer as an extra feature not part of he requirements – obviously when the TE looks at the application and requirements, since Help feature is not there – he reports it as a bug – the developer rejects it saying “it is an extra feature and that he wont test it” – Test Engineer replies back by re-opening the bug saying “update the requirements” – updating the requirements requires lot of running around for the development team, talking to the customer and all that

“DUPLICATE” BUG

The TE finds a bug and sends a defect report and also assigns the bug report a number – let‟s say he sends a bug report numbered as Bug 25 – now the developer replies back by saying “Bug 25 is duplicate of Bug 10” i.e, another Test engineer has already sent that bug earlier and it is being fixed.

 

Why do we get duplicate bugs?

  • Because of common features – Lets say Test Engineer A and B are testing an application – Test EngineerA and B to test their features must Login to the application using valid username and password before they can go deep into the application and start testing their features – A enters valid username and password and clicks on Login button – it goes to a blank page – this is a bug – so A prepares a defect report for this bug and sends it to developer – After sometime, B also tries to login and finds the same bug – he also prepares a defect report and sends it to developer – but developer sends back defect report of B saying “it is a duplicate”.
  • B finds bug in A’s module – let’s say A and B are testing their respective features – A is doing functional testing and integration testing on all his features – Similarly B is also testing all his features – In one scenario, B needs to go to A‟s feature(say m12) and send data to B‟s feature(say m23) –when B clicks on m12, he finds a bug – although its feature of A, he can still prepare a defect report and send it to developers – and B sends the defect report to development team – now, A after testing all his features comes to his feature m12 – he also finds the same defect and sends a defect report – but the developers send it back saying “it is duplicate”.

 

 

Join the conversation