Fun with bugs! - MoT Bloggers Club May 2021

 The MoT's Bloggers Club always gives me good inspiration for blogging topics. This one is about bugs!


A few different "fun" bug-related scenarios come to mind, so I'll jump strait to the point!

The Environmental "Bug"

This is kind of a false positive bug - it is a bug that is not a bug, per se. We all probably seen something like this, a feature that works in Test but not in the Acceptance environment, for example or if our regression tests suddenly start failing, but there were no code changes introduced to the system under test - rather there was a change in the infrastructure causing our tests to fail. These issues can be very frustrating and hard to pinpoint. The best way to avoid them is to avoid secrecy and to be fully transparent since any change, no matter how innocent may seem can cause unexpected complication in a large complex system.


Bug Ping Pong

Now this is not the case where some Stakeholder decides that the reported defect is not important enough so it gets ignored. No, this is much worse and it happens in companies that lack the culture of quality. Often when a bad developer doesn't know how do fix something, or does not have the time, they will claim that a certain bug should no longer be an issue since there was a change in a partially related part of the system that probably resolved this issue as well. Sadly that is rarely the case and this tends to lead to pointless re-testing and ping-ponging of the bug, where the tester returns it back saying that it is still a  valid issue, the developer claims that it is fixed again and the cycle where everyone's time is just needlessly waster goes on and on. If you work in a company where these kind of situations keep happening and the management is not doing anything to improve this, the best thing is to bid your farewell and look for new opportunities.

Dumb Bugs

Somewhat similar to the previous example, as these kinds of issues can be avoided with a minimum of common sense. These kind of bugs arise from bad/unclear requirements which get blindly accepted and implemented instead of being challenged and improved upon early in the design stages. Usually, when you report a bug like this you get a robotic reply in Jira this is working "as designed" - such as a bad UX solution that is most certain to annoy future users which will result in lot of tickets being reported in production. To prevent this, testers (designers, BAs, developers, as well and others) should be involved in the earliest stages of the software development - it should not be done by a single person! I have not witnessed this when working with good developers, but subpar programmers who just code what is asked without critically thinking will usually behave like this and it can be infuriating!


These are the bugs that I have found to be the most fun, what are yours?










Comments

Post a Comment

Popular posts from this blog

10 Tips for Designing Better Test Cases

Image
For most testers, designing, executing, and maintaining test cases are regular activities, this is especially true for new testers and those in the early stages of their career. This post is inspired by some documentation I worked on, in an effort to standardize the testing process in one of my previous jobs. Bear in mind that in each company the approach to handling test cases can differ significantly, old-school (Waterfall-like) enterprises might favor very long and detailed test cases, where each step required to execute the test cases is described in great detail, to more Agile environment where testing is moving at a faster pace, so test cases in Agile are shorter and more concise. There is a great course at the MoT on this topic called  Optimising Manual Test Scripts For An Agile Environment , by Match Archer, the course is not too long and it's full of useful info, I'd highly recommend it. There is also a third alternative - no test cases at all! This has been a trend in
Read more

TestRigor - Review

Image
Full honest disclaimer: I haven’t used many no-code automation tools, and the ones I’ve used have always been just out of curiosity, and I never went deep into any of those tools until now. I’m a QA who’s mainly focused on working with coded test automation frameworks and never had much time to look into such tools. So when the folks from testRigor approached me with a question if I would like to try out their tool, I was curious although a bit skeptical.   While in the past I disregarded any no-code automation tools, as I didn’t have a need for them, in more recent years I’ve become more open to the idea of giving such tools a try. There is a time and place for everything, and coding a complete automation framework can be a waste of resources - unless you produce it exceptionally specific in terms of testing. Hence, you need to utilize all the customization that is available to you. One of the reasons I changed my mind about tools like this one, was the fact that a couple of people in
Read more

How to Pass AZ-900 Azure Fundamentals Certification Exam

Image
I recently passed this exam, after some light-core studying, over maybe three to four weeks, I wasn't preparing all that intensively but considering what is recommended by a lot of people. I prepared more than I needed to prepare, I like to play it safe. A lot of people have been asking me how I prepared for the exam so that gave me the idea to put together this blog post with a few tips. Since this is an entry-level exam it's not too hard, compared to more specialized certification exams. It covers the basic cloud literacy and basic knowledge about Microsoft Azure, its services, and products. If you're new to IT or planning a change of career, this might give you a nice boost of confidence, if this is the case it makes take you a bit more to get acquainted with all the terms that will be new to you, but a few weeks of studying should suffice. On average, one or two weeks should be ample enough to prepare for this exam. The exam topics (at the time I'm writing this) are
Read more