Skip to main content

"Cannot Reproduce" Can We Get Rid Of Persistent Bugs?

Found this article on 10 steps to aid in eliminating those persistent bugs... Thought it many come in useful for some of you testers out there!

Unreproducible bugs can easily make a tester’s existence painful. Too often testers find a bug, then report it and get the answer “This is not a bug – I can’t reproduce it.” Still, the bug may be there, awaiting its next victim.
Unreproducible bugs can be very much expensive because of their increased lifetime and investigation time. They may as well have a quite damaging effect on your product perception in case the users reporting such bugs are ignored. Therefore, testers should do better to prevent them.
Here are 10 things testers can do to reduce the number of unreproducible bugs even now.
  1. Regularly do stress testing of the system unless you want to run across some unexpected failures when it is heavily loaded.
  2. Test timeouts. Make tests which fake or mock dependencies for timeout code testing. If the timeout code works wrong, it can cause a bug appearing only under certain conditions of the system.
  3. Test with optimised and debug builds. It happens that a good debug build works right, but your system fails in some strange ways as soon as optimised.
  4. Test with constrained resources. It’s a good practice to simulate the reduced network bandwidth as well as minimise the number of data centers, threads, machines, processes, available disk space and memory.
  5. Test for longevity. There are some bugs that require a long time to expose themselves. For instance, persistent data can become corrupt over some time.
  6. Utilise dynamic analysis tools such as memory debuggers regularly. They help identify numerous categories of unreproducible threading and memory issues.
  7. Perform fuzz testing to check your system’s hardiness at the time of enduring bad data.
  8. Always test the error handling code. Usually this is best achieved by mocking and faking the component which triggers the error.
  9. Remember to test concurrent data access when it’s the system’s feature. And if it’s not, verify that your system rejects it.
  10. Save the test logs for later potential analysis.
These seemingly obvious and not so obvious software testing guidelines will help you reduce the chances of unreproducible bugs to occur in your project.

Comments

Popular posts from this blog

My Testbash Brighton 2017 Notes

This was my second Testbash... if you ever get the chance in the future these conferences are a must!
I took copious amounts of notes from the 9 talks and tried to highlight my key takeaways here... hope they make sense but please comment if you have any questions :-)
Amy Phillips - Continuous Delivery
A survival guide to joining a fast paced environment/project…
Where does testing fit within Continuous delivery:


As highlighted, basically from start to finish…
There are lots of things we can do when joining a project that is using Continuous Delivery but one of the main points from this talk was to do your research! There should be an element of "Continuous" in every aspect of the project.
·Learning the ling, what's the difference Continuous Delivery, Continuous Deployment, Continuous Integration, Continuous design, Continuous Improvements etc.? ·Understand what your role in the project is going to be ·Understand the teams values, What's going well and maybe what the team p…

Is TestBash an Invaluable experience?

Over the last few years, I’ve attended four single track conferences at TestBash Brighton and Manchester. Most recently, September 2018 and April 2019.

One of the most common questions I get after the conference is, Was it worth it? Especially now given, I’m a contractor, and I attend at my own expense.

In short, Yes It’s definitely worth the trip!

That leads me into my question; does a single-track conference work for me, or could I get more out of TestBash?

Of course, there are pros and cons, some talks may not be as engaging, but this is no disrespect to the speakers, for me, it’s because I probably favour certain subjects and I’m pretty sure others will think the same.

Do I make the most of what’s on offer at TestBash? It pains me to say, No! I don’t make the most of the events leading up to and post the single-track conference so I could get more from the week.

TestBash offers master classes on automation. A full day of workshops. Test.bash() with talks on automation and technica…

The way we work shouldn’t be ‘Alien’ anymore, Should it!?!?

It’s been a good while since I have written anything (Mainly because I’m not that good a writer) but given my 16 months in the public sector I thought it was time… 
For a good number of years now the DevOps trend has given rise of buzzwords and methods aiming to speed delivery and it’s now an assumption of mine that most organisations are au fait with the term ‘Continuous Delivery’.
I was wrong…
Within the organisation that I am currently placed I believe I have a high-functioning collaborative team who work flexibly and in continuous cycle. We also involve the users which is a huge benefit to the development teams, but that’s not saying we get everything right 100% of the time! Teams must continue to learn and evolve to remain productive.
Our team work in one of several delivery groups and with this comes multiple challenges; Silos No single environment strategy lack of communicationsVaried ways of working.  And thats just to name a few, which is interesting when all delivery groups …