Tag Archives: Software Testing

The Ultimate Cheat Sheet on Bug reporting

Software TestingUltimate goal of bug reporting is to make an application more stable and allow developers to fix it without any trouble.  Bug reporting is a skill and art that needs to be practiced regularly. Efficient bug reporting depends on your understanding of business requirements, scenarios you tested, ability to differentiate between an average bug and good bug, details you capture and how simply you present to developers.

There are noticeable differences between developers and testers over bug reporting. Every now and then bug is rejected by developers as irreproducible and it doesn’t go well with testers since they can reproduce it. This is one of the minor differences that raise several misconceptions about software testing.

I work closely with QA and development teams in IT industry and have created an ultimate cheat sheet on bug reporting. Points mentioned in this cheat sheet are tried and tested and have been approved by several project managers and clients. These points and template will certainly enhance the efficiency of your bug reporting skills.

Art of Bug Reporting:
Art of Bug Reporting
There is certain type of result that is expected in every bug reported by a QA team.  As a tester, bug reporting is more of a documentation of your findings due to which it should be very simple. Developers, project managers or even a layman should be able to understand and reproduce that bug.

Simplest 4 point format which I and my team use in for bug reporting. Bug description should include:

  • Scenario: List all steps that tester took that will help others to replicate the bug. These steps can also include basic information such as name of browser on which you tested, clearing cache etc.
  • Expected result: The final result which is expected based on business requirement and which end user will see by following above steps.
  • Actual result: The result which is currently visible to user and which could be correct or incorrect.
  • Additional Data: Any additional information, observation or special instruction which is useful for team to replicate it, including which browser and OS used, relevant screenshots, any video recording that captures any intermittent bugs, adding references to the specifications etc.

Once you have described the bug based on this template, you will notice that not only that you have captured required information relevant to reproduce the bug, you have also answered any potential question from developers. You will also find it relatively easy to fill following important fields of any bug tracking tool:

  • Bug Title: This has to be one liner, crisp and precise. You have already covered details in bug description
  • Product Name: It will be name of the product, project or module you are testing
  • Version: Version of build, module or product
  • Operating System: Windows, Mac, Linux etc. along with their versions
  • Priority: It is generally set from P1 to P5. P1 means Bug needs to be fixed on highest priority and P5 means Fix the bug as time permits
  • Severity: Business impact of bug. There are 6 types of severity and one needs to be selected:
    1. Blocker: Further testing cannot proceed
    2. Critical: Application crash, Loss of data etc.
    3. Major: Major loss of function
    4. Minor: Minor loss of function
    5. Trivial: UI enhancements
    6. Enhancement: New feature or Change request
  • Status: Bug status which shows whether it is new, fixed, reopened, verified or won’t fix
  • Assign To: This is critical – Be very sure which developer is responsible for this. If you don’t know whom to assign, leave it blank so that manager can assign to developer. In this case, add manager email in CC so that he gets notified.

I have experienced a huge improvement in quality of bugs reported, higher bug closing rate and overall coordination effort using this bug reporting template and process. Yes, initially it seems a time consuming process but this is a key for any good but report. This is main communication between developers, testers and project managers which can be easily tracked in case of any disputes.

I am sure this ultimate cheat sheet of bug reporting will be remain handy for all QA managers and project managers as quality bug reporting saves lot of time that goes in explaining and reproducing bugs, maintaining good relationship between testers and developers.

This article is based on my learning and experience. I believe there could be more changes, scenarios based on which we can customized bug reporting template and process.

Do you have recommendations or examples which could be helpful for others? Share with us – we are open for learning.

25 Common Misconceptions about Software Testing

Misconceptions about software testingTeams involved with developing, managing, and maintaining software often have misconceptions about software testing. Potential workers and new testers feel lot of frustration due to these common misconceptions and misbeliefs and make them unhappy about their work. Companies have lost their clients when they failed to counter these myths, understand the importance of software testing, QA project plan and difference between goal and mindset of testing which is different for developer and for tester.

I’ve worked closely with IT industry in past 10 years and especially with software testing business units. I have seen how management formulates the career growth plans for developers and testers based on these misconceptions. They promote a strong belief that software testing job is inferior to software development job. I have seen projects falling apart due to these misconceptions and partiality of management towards developers. They don’t understand that both software development and testing are equally valuable for the quality of the software product and they are interlinked for project success.

I have listed few common misconceptions about software testing which are popular in IT industry. Few of these can raise series of arguments, but objectively these are very common misconceptions and practices that are followed in mid and small level software vendors across globe. In my case, I hear point 1, 2, 16, 22 and 24 on daily basis. Let me know yours.

  1. Software testing is no brainier job and doesn’t require any specific skills. I found this interesting image to convey exactly what management and software developers feel about testers.Tester Profile
  2. Testing efforts are standard 20% of overall development estimates.
  3. Involving testers in early stage of project is just a formality and can be skipped.
  4. Testers are required to act as business analyst and understand the project flow by themselves without participating in any kickoff meeting and project discussions.
  5. Testers shouldn’t give recommendation as it causes unnecessary project delays.
  6. In entire team, only testers are required to have excellent communication skills as they report bugs.
  7. Developers make good testers and both have same goals in deliverable.
  8. Website, desktop or mobile testing is less prestigious then software development.
  9. Manual Testing is inferior to Automation Testing.
  10. Unit testing should be done by tester not by developer.
  11. Testing team is a liability and an expense to company as only small amount of testing is required to validate the development.
  12. Testing process is only meant for corporate website and marketing collateral.
  13. To save time, testing can be done on developer’s machine.
  14. Testing with agile methodology means less documentation.
  15. Testers should follow developers work schedule.
  16. Testers don’t get along with developers. Myth which is majorly promoted by management as their divide and rule policy. This is one myth which can tarnish any project if not proactively controlled by project managers.
  17. Involving developer will speed up the implementation of test automation.
  18. Automation testers do not have to bother themselves with manual testing.
  19. Automated testing requires minimum of tester’s activity and attention.
  20. Testers are mad, bug hunters and they are the forever skeptics.
  21. Testers do not need any professional training and certifications. They can train themselves while working on their projects.
  22. Exhaustive testing can make software Bug Free.
  23. Software Testing has nothing to do with creativity, all they do is write or design test cases.
  24. Quality testing means number of test cases executed by tester in a day.
  25. Test case Reviews are a one-time effort.