JuniorLearnsToCode

 Let me tell you a spooky story about an irreproducible bug. It took a place a long time ago, before seven companies, and seven projects, there stood an irreproducible bug! At the time this happened I was working on a fairly large enterprise project,. The whole system was made up of various applications, written in a few different languages, over time, by many different teams.  The core defect was a bit of an edge case, where just users with certain country codes would not get eCommerce promotional emails sent to them. It was a wild goose chase, I was the first to investigate the bugs, as I was in the application support team at the time, about 20 hours per week. I tried in different environments, but to no avail - I could not figure it out. Used a test harness to trick the dates, as it was a kind of email that gets sent 24 hours after registration. I got very stubborn about it and spent about 4 hours without getting up from my chair, trying to figure out the root cause. Why w...

Reporting bugs is an unavoidable part of SDLC and it is an integral part of any tester's job. It's usually done using bug-tracking software such as Jira, Rally, Bugzilla, Mantis, Azure DevOps, etc. In this post, I will share a few general (common-sense) tips on writing a clear and useful bug report. Well-written and understandable bug reports save time and can be a significant contribution to the quality of the product - especially if we prioritize those bugs which negatively impact the user experience and block the core functionalities of the application under test. So let's see what we can do to make our bug reports better.  Root Cause Analysis  Before reporting we need to make sure our defect is valid, we should check for human errors such as an outdated (no longer support) app version, configuration settings, user or systems settings - checking the logs can help us a lot here. Root cause analysis can be added in the form of testing notes to the defect ticket. If the tes...