To be a Bug or not to be a Bug. What’s, How’s and Why’s of Bug Report

Being in a Software Testing field, process engineering, and now Application Security, I have been reading and documenting about Bug Reports but I have never came across such good, concise and precise definition of Bug Reporting.
What is Observation, Expectation, Reproducibility, and ultimately, what is Bug.

Have a look.

You’re using your computer and all of a sudden you notice something wrong. Something doesn’t seem to work correctly… it doesn’t do what you expect it to.

Is there something wrong with the hardware or with the software? Is there something wrong in your configuration or the way you’re using the computer? Are you expecting the wrong thing to happen?

You don’t know yet, but one thing is sure: What you saw didn’t match what you expected.

At this stage, this is an observation. Something looks wrong, so you start to troubleshoot.

Here’s an example of an observation:“While walking, I felt a pain in my right foot”.

Here’s an example of a valid expectation:“My shoe should not hurt my foot”.

Here’s an example of a reproducible issue:“Every time I walk, I feel a pain in my right foot”.

Here’s an example of an issue where the responsible component was identified:

“My Nike shoes hurt my right foot every time I walk. I feel no pain with other pairs of shoes, the same socks, the same places, the same amount of time.”

Server time out when php script takes too long to execute.

Most of the time, if the php script is process intensive on client end, by default, the APACHE server times out the script. If the script is timing out on server, one needs to add a small line on the top of the script.