AuraQ has vast experience helping organisations find the gaps that can be filled to enhance their business. This could be to improve efficiency, integrate legacy systems or deliver new portals and strategic applications to create competitive advantage. Contact us to request a free, no obligation Gap Analysis.
Fantastic bugs and where to find them
“It’s not a bug it’s a feature!”
Bugs are introduced into a system, or application, in a number of ways. If they are not caught early in the development cycle they can waste a great deal of working hours to try to replicate and fix later down the line. The severity of a bug can also range from relatively harmless, such as visual issues on an online form, to extremely severe, such as causing an entire system outage.
Image from: https://www.videezy.com/free-video/analog-static
As such, many rigorous tests are usually performed any time a change is being made to an existing system, or a new system is being developed, to try to find any bugs at an early stage. This usually includes Developer Testing, Quality Assurance Testing and User Approval Testing being performed before a change is rolled out to a live environment.
There are many different ways to test even simple changes, but first you have to be aware of the scope of the change, and how it fits into the grand scheme of the system as a whole. Knowing this will help you try to spot where an issue could occur and help you locate some of the more obvious bugs relating to the change and the connected components.
Common testing steps –
1. Make a test plan to indicate what tests will be performed.
2. Test the system under lots of different conditions, and under lots of scenarios based on your plan.
3. Find an issue/error through testing.
4. Investigate logs and error messages to gather evidence of issue.
5. Attempt to replicate.
6. Report the error with relevant evidence and instructions on how to replicate.
Now, knowing the system and testing with this in mind is one thing, but sometimes to find the more obscure bugs you will need to switch your mind-set to someone who has never used the system before.
Image from: http://dinesql.blogspot.co.uk/2015/10/types-of-database-end-users.html
Testing with this mind-set will enable you to perform certain tests in different ways, such as entering information out of sequence and using the system in ways you may not consider right. This is especially important as you can never wholly predict the full possibilities of what a user could do and ultimately, will help locate bugs which are never obvious.
“It has gone live now, so it’s supports job!”
Once a change is at the end of its life cycle, it will be fully integrated with the live system and now it’s the end users turn to find any issues. This is the least desirable place to find bugs in the system, as if they haven’t been caught by previous stages then it could reflect badly on the developers and the testers. Alternatively, some bugs will never be found until the live environment variables are put in place and the change is fully integrated. This can be for a number of reasons:
- Sizable amounts of data being dealt with– some live systems can hold millions of records, meaning that a lack of optimisation is frequently caught at this stage.
- Credential differences– usernames, email addresses, limited characters all can cause issues if no strict ruling is in place.
- Live environment architectural discrepancies– the live environment can be formed of many different components to that of any development or test systems.
- Level of security– live systems (especially databases) can be locked down and treated differently.
At this point, most of the liaising will be with various support members and end users, meaning that finding and fixing bugs can have added difficulties when attempting to diagnose issues.
Image From: https://sites.psu.edu/deconstruction/2015/09/15/assumptions/
Your capability to diagnose system bugs efficiently is dependent on your ability to question your own assumptions. You will assume you know the answer and will be completely correct up until you realign yourself with the system itself. The moments you do not have that willingness to admit you might be wrong amounts to the time you spend checking the wrong parts of the system.
This is true for developers, testers and analysts, where simple assumptions like –“I’m on the right server”, “I’m observing the correct form”, “the client’s claims are to be followed exactly and never strayed from” and “the issue can’t possibly be that…” Are examples of the biggest pitfalls that waste precious working hours.
Never fear, as there will always be tools at your disposal that assist in moving past such assumptions such as system logs, debuggers, error messages and colleagues. But having the confidence to leave your assumptions at the door will save time, effort and ultimately, help you get to the source quicker.
Related Blogs
Drag