This is an anonymous post sent in by a member who does not want their name disclosed. Please be thoughtful with your responses, as these are usuall...
For further actions, you may consider blocking this person and/or reporting abuse
So finding bugs and getting rid of them are different tasks with different goals.
finding bugs
fixing bugs
Each bullet point above has multiple options on their own. For example writing tests for your code could range from unit tests, to more "realistic" testing where you simulate actual user actions.
I make a manual test checklist and automate what I can from there.
For backend - smoke and soak testing is really helpful, I use k6; they also have a nice explanation on load testing in general in the docs.
For the front-end - end to end testing, but it's slowest and hardest to setup imho, though it is really good for bug chasing.
And in terms of unit tests - fuzzy testing is really helpful.
I read Eric Lippert's "How to Debug Small Programs" and it's got some good advice.
His first piece of advice really hits home: "Turn on compiler warnings" (and read them).
If it's a runtime bug and there are no errors or warnings from the compiler, I'll check what exceptions are thrown. In .NET on Windows you can use the event viewer to see details of exceptions even in release software. For JavaScript, the browser console often has useful information.
If it's a behavioural bug, i.e. not crashing, just doing something unexpected or out of spec, I'll try and track down where in the code it is happening. This is why modular and OO design is so important. It helps prevent the code base from becoming a big ball of mud.
At this point it's important to write down your assumptions of what a particular piece of code is meant to do and figure out a way you can test those assumptions.
Eliminating variables is a great technique in a lot of cases. You can't always find yourself in a circumstance where this makes sense, but when you can just remove lines of code to isolate what the problem might be, you're cooking with gas. Eventually you'll stumble into the problem area and you can go from there.
When you have the opportunity to — it never hurts to write tests during the debugging process. Automated tests are good to have around where bugs were because there are probably nearby bugs, so if your debugging process includes testing, all the better!
A few different ways I've had bugs found in the past:
Once any bugs are found, it's usually a case of doing a few things to debug them and fix them:
It's varies depending on the type of software you're writing, it's different to do it for an API, website or when you program for let's say a chip or hardware device.
But in my case (for web and mobile apps), at work we do it in a couple of ways:
There is many ways for finding bugs but I found mutation testing to be the quickest path when in doubt. It's slow to execute the tests but also very practical although it will give you many false positive.
As for fixing bugs, understanding the code is a must and this take more time than writing the implementation from scratch. Debugger and log trace will help but it's not guaranteed. Replayability play a big role so rewriting that buggy parts in separate code or environment will help fixing the tough bugs.
Automated tests. Running all tests whenever introducing anything new. When you or your users eventually discover bugs that slipped past your existing tests, add test cases that reveal the bug before fixing it.
Use a code coverage tool. Look at the report and examine what your test cases don't cover. Ask yourself why your tests don't cover whatever they don't cover. Some of it might be stuff involving user interaction that is hard to automate testing. But if you find large complex branches not touched by your tests, you found a place where bugs might be lurking. Keep in mind high test coverage, even 100% coverage, doesn't guarantee no bugs. But it can be useful to find places where your tests neglect.
Use static analysis tools. There are several that integrate well with GitHub such as Snyk, Sonatype's Lift, and CodeQL. You can discover potentially errorprone code with tools like these.
Code reviews put extra sets of human eyes on your code.
Impressive article on testing and bug discovery in applications! If you're eager to enhance your bug-finding skills, I highly recommend checking out this insightful piece on how to find bugs in Android apps. You can find the article here: How to Find Bugs in Android Apps. Happy testing and happy bug hunting!
If you find a bug you burn down the code base?
Interesting solution, but effective!
There are some best practices for Software Testing mentioned in the ISTQB Foundation Level course.
The materials for that course are free and available online.
If I am reading this correctly, the latter states that you file every bug in the user story? We always create a Bug and link it to the User Story. This way you can track the bugs lifecycle