By Ronnie Mbuqe
The written instructions may not match the intended behaviour. Missing cases, mistaken assumptions and incorrect requirements can all produce failures.
Reproduce the issue with a specific input and expected result. That gives the investigation a testable question instead of a vague description such as 'sometimes broken'.
Thirty seconds became almost no delay, even though the number was right
A service returns 30 to mean seconds, while the browser reads it as milliseconds. Both sides can use valid code and still produce an incorrect wait. The missing information is the unit at the boundary.
We will reproduce the mismatch, identify its cause and check a corrected case. The objective is a debugging method you can apply beyond this one example: observe, trace, correct and verify.
Practical examples: What Is a Bug
Login
A login failure may come from an incorrect password, but it may also be an expired session, unavailable identity service, clock difference or cookie problem. Good debugging separates a valid rejection from a technical failure before changing code.
Incorrect
An incorrect total may originate in rounding, duplicated records, an outdated rule or a filter using the wrong date. Developers compare the expected calculation with each intermediate value instead of correcting only the number displayed on screen.
Broken
A broken button may be caused by JavaScript, validation, routing, permissions or a server error. Browser tools and server logs reveal whether the click happened, what request was sent and where the chain stopped.
Slow
Slowness is also a defect when it prevents useful work. The cause may be a large image, repeated API call, missing database index or external service. Measuring time at each layer identifies the bottleneck; guessing often optimises the wrong component.
Can a program run without crashing and still have a serious bug?
A crash is one visible failure mode.
Trace the explanation
Incorrect eligibility, duplicate charges and missing records can happen while every instruction executes successfully. Test the intended behaviour with concrete inputs and expected outcomes.
Source and further reading: Microsoft Learn
A wrong total can start with a correct formula and the wrong units
Suppose a service returns a duration in seconds, but the interface treats it as milliseconds. A value of 30 becomes a tiny delay instead of half a minute. Every multiplication in the code can be valid while the contract between two parts is wrong.
Write down what the number means at each boundary: source, name, unit, allowed range and missing-value behaviour. Then inspect a real example through those boundaries. This often finds a mismatch faster than changing the final display calculation.
Write the meaning beside every value in the trace
The sender provides duration=30 seconds. The receiver passes 30 to an operation expecting milliseconds. The resulting delay is 0.03 seconds, not the requested 30 seconds.
The conversion is seconds × 1,000, so 30 seconds becomes 30,000 milliseconds. Renaming a value to durationSeconds helps communicate the contract but does not perform the conversion by itself.
After the fix, test 30 seconds and a second value such as two seconds. Also test the allowed minimum and missing input under the application's rules. Hiding the timeout error would not establish that the waiting behaviour was corrected.
How many milliseconds should represent two seconds?
This checks a prediction about the worked example. It does not run server code, contact an API or change a booking.
2,000 milliseconds. The factor is 1,000 milliseconds per second, and the corrected value must reach the operation that expects it.Read the explanation without the checker
2,000 milliseconds. The factor is 1,000 milliseconds per second, and the corrected value must reach the operation that expects it.
Find a boundary involving dates, money or distance. Write down the expected unit, range and missing-value behaviour before assuming a displayed number is correct.
A report should include 12 bookings but a filter excludes 4 valid ones. How many bookings does it incorrectly display?
Trace the explanation
12 − 4 = 8. A neatly rendered report can still be incomplete. Check which rows were excluded and why, rather than assuming a plausible-looking total is correct.
Source and further reading: Microsoft Learn
Why is the first error you see not always the original cause?
One failure can trigger others: missing data can cause a calculation to fail, which then prevents a screen update. The last message may describe only the consequence.
Follow the sequence backwards and inspect the earliest unexpected state. Fixing a symptom without the triggering condition can leave the same bug ready to return.
Reproduce the failure before trying to make it disappear
A useful report gives the input, expected outcome, actual outcome and relevant conditions. 'Sometimes bookings fail' is difficult to test; 'after the session expires, submitting this date range returns an HTML login page where JSON is expected' points to a specific path.
After a fix, repeat the failing case and a nearby normal case. If the change only hides the message, the underlying record may still be wrong. Verification should establish the intended result and any important side effects, such as whether exactly one reservation was created.
Is adding a try/catch always a fix?
No. It may prevent a crash while concealing the failure. Catch an error where the program can recover or provide an honest outcome; retain suitable diagnostic information without exposing secrets.
Questions about What Is a Bug?
Are bugs always caused by bad developers?
No. Software can be complex. Bugs are normal, especially when systems grow or requirements change.
How do developers find bugs?
They reproduce the problem, read logs, test different cases and inspect the code.
What is the first step in debugging?
Make the failure reproducible if possible. Record the exact inputs, user state, time and expected result so you can compare a failing case with a working one.
What is an edge case?
It is an unusual but valid situation near the boundaries of normal input, such as an empty list, midnight, leap day or the maximum allowed value.
Why are logs useful?
Logs record what the system did at important points and can reveal timing, inputs and failures that are difficult to reproduce in a developer environment.
Why write a test after fixing a bug?
A regression test captures the failing scenario so a future code change is less likely to reintroduce the same defect unnoticed.
Debugging: reproduce, isolate, fix, verify
A bug is a difference between what software should do and what it actually does. The most efficient fix starts with a reliable description of that difference. “The page is broken” is too broad; “after selecting a date and clearing the filter, the grid still shows one result although the unfiltered list contains 28” gives a developer something to investigate.
1. Reproduce the failure
Record the steps, starting state, test data, expected result, actual result, and any error message. If the issue happens only sometimes, note the timing and conditions. Do not change several settings before you have a repeatable case.
2. Isolate the cause
Reduce the problem to the smallest example that still fails. Check whether the data is wrong, the user interface is stale, a request returned an unexpected result, or state was not reset. Logs and debugger watches help, but avoid logging passwords, tokens, or unnecessary personal information.
3. Make one focused change
Fix the cause rather than hiding the symptom. If a grid retains an old filtered data source, changing the displayed count may disguise the problem without restoring the correct rows. A focused change should explain why the failure occurred and avoid unrelated rewrites.
4. Verify the fix and nearby behaviour
Repeat the original failing steps, then test a normal case, a boundary case, and a related workflow. A bug fix can create a regression if it changes shared state or assumptions. Test in a safe development or staging environment before releasing to users.
A useful bug report template
Title: Clearing the filter leaves stale grid results
Steps: Apply a filter, then choose Clear Filters
Expected: All unfiltered records return
Actual: The grid still shows the previous filtered result
Evidence: Test data count, screenshot, safe log excerpt
Environment: Browser, build, and test environment
A good bug report is not about blame. It shortens the time needed to understand and verify a failure and creates a record that can help prevent the same problem later.
Further reading: MDN Web Docs: Learn web development.
A bug appears only when the input is zero. How would you turn that observation into a useful regression check?
One reasoned response
Record the exact zero case, its intended meaning and the expected result. Compare it with missing, positive and invalid values. Those cases test distinct decisions rather than repeating the implementation.
Source and further reading: Microsoft Learn
Reproduce the bug before changing code
A bug report is much more useful when another person can follow the same steps and see the same result. Record the starting state, exact actions, test data, expected behaviour and actual behaviour. Include the browser or application version when it matters, but remove passwords, personal data and other secrets from screenshots or logs.
A disciplined debugging sequence
- Reproduce: confirm the problem occurs consistently, or identify the conditions that make it occur.
- Isolate: reduce the case to the smallest set of steps, inputs or components that still fails.
- Form a hypothesis: state what you think is wrong and what evidence would support it.
- Change one thing: avoid several unrelated edits that make cause and effect unclear.
- Verify: test the original failure and nearby cases, then check that existing behaviour still works.
Example: a filter that will not clear
If a grid still shows one row after a filter is cleared, do not immediately rewrite the entire grid. Check whether the underlying data array contains all rows, whether the data source has its own filter, and whether paging or cached state is involved. Compare the displayed row count with the unfiltered collection. The first point where those values disagree narrows the search.
A fix is not complete merely because the screen looks right once. Record the steps, test the failure again, and test a nearby scenario that could regress. Clear evidence makes debugging faster for the next person too.
Sources
Sources and further reading
A closer lookA correct formula can use the wrong input
A price calculation multiplies quantity by unit price correctly, but quantity came from the previous item. The arithmetic passes an isolated test while the screen still charges the wrong amount.
Work through the distinction
Reproduce the complete sequence: select item A, change quantity, select item B and submit. Capture expected and actual values at each boundary. Tests should cover transitions and stale state, not only the formula with hand-picked inputs.
What kind of test exposes this problem?
Choose an answer to see feedback. You can try again.
Show the answer and explanation
A sequence that changes the selected item. Reproduce the complete sequence: select item A, change quantity, select item B and submit. Capture expected and actual values at each boundary. Tests should cover transitions and stale state, not only the formula with hand-picked inputs.