Flush Out the Darkness!
When I was a kid, we were overrun by an unexpected and altogether unwelcome invasion of cockroaches. I discovered a couple in a place we kept paper shopping bags and I thought I got them all. Alas, deception runs deep when it comes to getting rid of bugs. Assumption is the “Mother of all Screw-ups”?. Maybe you should make a poster out of this phrase and hang it in your QA lab. (I even went through the bother of making a slight alteration to that quote to make it “enterprise ready”.)
Bugs, system deficiencies or functional issues, whatever you want to call them, are a natural part of the development life-cycle. Embrace them young Padawan, if you do, much stronger and knowledgeable become you will. Part of technology development you are.
An added benefit of identifying, reporting, tracking, deploying and retesting a system for bugs, (don’t call them system deficiencies – it makes the developers feel bad) is that you can become more technically competent. When a bug is fixed, review the section entitled “Developer Summarize Fix”, if you have questions, ask the person who fixed the bug. There are a couple of fun reasons for expanding your knowledge of the system. The first is to develop your own technical knowledge, and the second is to answer questions your testers may have. It’s not that they will understand you completely, but I find testers are excited at the prospect of listening to a technical answer. It’s a good way to show you respect them. It’s a great confidence builder.
There are two typical ways to collect bugs. The first is during your initial Black Box Testing. In this case, have the testers fill-out the test scripts. When something breaks, they have a place to note the unexpected system behavior. During this kind of testing, I usually give the test script to the developer and let them fix the bug using that document. There is a lot going on while testing a system and no one has time to transfer stuff from one form to the other.
When, the system fails after it has received sign-off you must first determine if you are dealing with a bug or feature. It could be that the system was not designed to respond to a specific path because the Use Case failed to map out an error response for that path. You’ll have to do some quick detective work at this point.
Interview the person who reported the issue or talk with the tech support person who recorded the complaint. Watch as they create the “error”. If they can replicate the problem, you do have an issue. Try the same execution path in your QA environment. If the error also occurs there, check if the system is failing because it is trying to do something it was not designed to do. If you have been with the system for a while, you should know the answer to this question right away. If the behavior is not a bug, then have the user fill-out a Change Request and allow the document to work its way through the normal development cycle set-up by your company. If you are unfamiliar with the system, you should identify who on the team created the application or module in question and ask them. Writing code is a lot like giving birth. One does not easily forget one’s toil and pain.
If you cannot replicate the error in your QA environment then you probably have something out of sync. At this point you should insure that all the deployment prerequisites were truly met by checking with the team that does your deployment. If the prerequisites are met, then you may have to hold a quick meeting between the deployment team and the developer. (I assume the QA environment you used for this test is the one that is exactly like the production environment except of course on a smaller scale.)
If the developer is not available, you may have to check your Use Cases. If they are managed properly, it should not take long to find and review the requirements and execution paths. If the error was created by following an unforeseen error path, then write up a bug report and have the system return a message that finalizes the path with an error message. An execution path may never end without anything happening. Your application should never react like a dead couch potato. If the execution path leads to an error where no error should occur, you do have a bug. At this point assign the bug a ticket number and a developer to crush it.
If, after giving it your best, you still can’t determine if you have a bug or feature on your hands, handle it like a bug. Mark my words, someone will set you straight right away. It never fails! You may have to smooth things over with the developer by buying them a soda or something – but you will at least get some momentum behind the issue, and that is well worth the price of a soda.
The form itself is rather simple, but it may appear to be organized backward. I placed the developer check list on the first page, because this is the one you should examine first. Ensure all the relative steps have been checked. If not, the fix is not ready to be tested. Ensure the developer has not forgotten to give you any files or scripts. If you deployed everything according to the developer’s recommendation, and it doesn’t work, then most likely someone missed a file or script.
I placed the “Test Procedures” and “Deployment Procedures” in the QA section, because it is usually your responsibility to know the best way to do this. If not, get some input from the developer. In some cases a fix must be tested or deployed in a special way. Usually, you will be the one to inform the Help Desk the fix is ready and how best to deploy it.
Test the fix as you generally do any code. Follow the execution path described in the “Procedure” section of the final page. If the issue described in the “Problem Description” section does not reoccur, the bug is officially fixed. If you have some extra time on your hands (As if that’s likely to happen.) you can play around a bit; deviating from the execution path described to see if anything else blows-up. CAUTION: This idea is only for the strong of heart.