Foyzul Hassan: Comment Sensibly

746 views

Published on

Published in: Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
746
On SlideShare
0
From Embeds
0
Number of Embeds
91
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Foyzul Hassan: Comment Sensibly

  1. 1. Comment Sensibly… Foyzul Hassan <shakil_03@yahoo.com>
  2. 2. It’s Not a Bug Why It’s not a bug: <ul><li>Developer is confident that this is not bug. </li></ul><ul><li>Improper bug reporting by QA/Testing Eng. </li></ul><ul><li>Lack of analysis about the bug. </li></ul><ul><li>Improper Requirement or Documentation. </li></ul>What should we do: <ul><li>Analyze the bug in depth. </li></ul><ul><li>Report the bug with more clear description and steps. </li></ul><ul><li>Validate requirement. </li></ul><ul><li>Think in terms of usability. </li></ul>
  3. 3. Example of It’s not a bug Developer X designed a PDF report. And the report shows information correctly. But the problem is it takes 5min to open the report. QA team reported it as a bug. Developer commented that “It’s not a bug.Because it has to process huge data”. But in terms of usability it’s a problem. Because it’s very annoying to wait for 5min to see the report. So, what we need is to analyze the code so that report generation time will become less.
  4. 4. Can Not Reproduce Why Can Not Reproduce: <ul><li>Bug description and steps are not clear enough. </li></ul><ul><li>Developer does not like to follow the steps to produce the bug. </li></ul><ul><li>Development and Testing PC environment difference. </li></ul><ul><li>Developer and QA working on different revision of source code. </li></ul><ul><li>It’s really mysterious bug. </li></ul>What should we do: <ul><li>Bug description and steps should be clear. </li></ul><ul><li>Try to follow the steps to produce the bug. </li></ul><ul><li>Testing environment should be same as user environment. </li></ul><ul><li>During bug report mention source code revision. </li></ul><ul><li>Try to add screen shot, exception log for mysterious bug. </li></ul>
  5. 5. Example of Can Not Reproduce It’s a very common scenario that a installer running well on development PC but can not run on testing PC.And reason can be third party dll or a environment variable.Because in developer PC dll and environment variables are added manually for debugging purpose.But in testing PC installer fails to install as the dll and environment variables are not added to the installer.
  6. 6. It will never happen Why It will never happen: <ul><li>Developer may think that user will never do this or it’s less important bug. </li></ul><ul><li>QA Eng. may present the bug in unrealistic manner. </li></ul><ul><li>Management may think this type of bug will not embarrass them. </li></ul>What should we do: <ul><li>Think the bug in prospect to the user. </li></ul><ul><li>QA Eng. should represent a bug in a realistic manner. </li></ul><ul><li>Try to describe the severity of the bug so that management and developer take it seriously. </li></ul>
  7. 7. Example of It will never happen In a web based application it takes a long time to complete transaction.And during transaction in progress QA Eng. unplugged network cable to check database atomicity in disconnected mode and report it as a bug as it lost atomicity. Developer may comment that “It will never”. As a QA Eng we should describe the bug in a realistic manner and should describe the severity of the bug .
  8. 8. Lot of changes required to fix the bug Why Lot of changes required to fix the bug: <ul><li>Developer may think that it as a time consuming or less priority bug. </li></ul><ul><li>Fixing this bug may open another bug. </li></ul><ul><li>Design document may not be clear enough so that it’s difficult to make changes. </li></ul><ul><li>Lot of changes may require to fix the bug. </li></ul>What should we do: <ul><li>Try to describe the severity of the bug. </li></ul><ul><li>Changes should be documented so that risk areas can be identified. </li></ul><ul><li>Try to maintain design document. </li></ul>
  9. 9. Example of Lot of changes required to fix the bug Suppose in a database project date format of a field is not according the requirement. And this field is used in various tables. So, after reporting this as a bug, developer may comment that lot of changes required to fix the bug. But date format in different country may differ and at user end this bug may create a bad impact.
  10. 10. It’s according to the document Why It’s according to the document: <ul><li>Developer or QA may not understand the requirement well. </li></ul><ul><li>Document can be ambiguous. </li></ul><ul><li>Document can be modified according to the implementation. </li></ul><ul><li>Document may become outdated. </li></ul>What should we do: <ul><li>Both developer & QA should have well understanding about requirement and requirement doc. </li></ul><ul><li>Try to figure out miss concepts in the document. </li></ul><ul><li>Validate requirement in terms of usability and business logic. </li></ul><ul><li>If document is outdated then try to get requirement from a person who knows the requirement well and update the document. </li></ul>
  11. 11. Example of It’s according to the document In requirement document it is given that “Add a new field to the Customer table that will hold customer's yearly turn over. And this field should be NOT NULL”. And developer made changes according to that. But problem may appear for old data as it has no such field. So, we should validate document.
  12. 12. Questions

×