Critical Bugs and other thoughts part 2

One of the most common areas where there are issues are with memory allocations.

Deleting an object before it’s suppose to be deleted will lead to a crash and not deleting the object correctly may lead to what’s known as memory leaks.  Depending on the language used and how well the garbage collection is handled amongst other factors, this could lead to bloated applications that hog the memory while the application is running.

Another spot in regards to issues with memory is initialization.  Here are 2 examples.  One is with pointers, and if the pointer is not initialized with a known value, there is a chance that the pointer points to some part in the memory where it ends up picking a value that is not known and causes a random crash or wrong value.  It might only appear when the application runs for a while, or it might end up occurring when the application just starts up.  Another example: depending on the language an array starts with 0 or 1.  If the programmer forgets which one it starts with, an array may end up giving the wrong value at the extreme indexes (0, 1, max)

Adding objects could become complex as well.  Buffer overflow is one example of needing to be careful.

Memory gets more complicated when you’re dealing with caching, locking the memory temporarily for reading and multiple processes in a blackbox fashion.  Where are you getting the data from?  How are you able to determine this?

Other thoughts on QA and bug finding:

Human cognitive behavior is something that is most profound.  This video: shows the example of this.

This video is an example of a test to show selective attention.  When one becomes too focused on a task, they might not necessarily find a bug because their attention was too centered around a test case and the objective of the test case.  I have found that trying to do 1 off scenarios from the test cases can often lead to finding more bugs from the test cases than just running the test cases themselves.

QA mindset is different from at least a Tech Support mindset, though they have some similarities as well.

One of Einstein’s colleagues asked him for his telephone number one day. Einstein reached for a telephone directory and looked it up. “You don’t remember your own number?” the man asked, startled.  “No,” Einstein answered. “Why should I memorize something I can so easily get from a book?”

I think it should apply to all occupations that knowing your resources and where to look them up is an important factor in all jobs, but is very true in being QA and Tech Support.

Another similarity is to narrow down the bugs to it’s simplest form so that the engineers can take a look at the problem efficiently.

The difference lies in that from Tech Support, the job is to make the customer happy by either resolving the issue, or figuring out a solution around the issue with the mental attitude that the application is working correctly.  From a QA mindset, it’s reversed.  A work around is a bug, and the application is not working correctly and it’s their job to find it before the customer does.


About shizen008

Breaking things and getting in trouble for it since '74. Disclaimer: I am not responsible if I make your head explode reading this blog! The writings here are my own expression and not of any companies. I currently work on being a QA for B2G aka Firefox OS
This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s