To me, QA is about reporting what the current behavior of the application is,
for better or worse. This means reporting what works and what does not work.
Overall testing means to check every button to make sure that the application
behaves as expected. There are a lot of testing to do where bugs for a feature
can be found in various areas such as UI, Data, Functionality, Integration and
Environment. When you want to find crashers and critical bugs… that’s when you
have to worry about timing and sequence of events. [Edit: this also means to ensure what has worked stays working, what’s fixed is fixed and the fix involves everything around that might end up leading to the same bug.]
Testing does not require computer science knowledge; being a good tester doesn’t
require having computer science knowledge. What it does require is having a
scientific/methological mindset. What I mean by that is understanding what and
how to keep certain variables/conditions constant while testing one by one each
variable/condition thoroughly. Some variables/conditions could be lumped in the
same tests, and to understand that requires a deeper understanding. Having the
same vocabulary as the developers helps with that and having a computer science
background of being able to read code and understand the developers/code gives a
huge advantage in being a tester. You do not need a degree in order to have a
computer science background, but it helps to prove that you do have one. It also
helps to have some experience in trying to program. Why? Because it helps you
understand where you might encounter bugs as a coder and understand where
certain weak points may be in code.
Side note: one of the best testers I know doesn’t have a computer science
degree, but had learned how to program on the side by himself. He also has over
12 years of experience working on the same code base that he does QA on. One of
the things I noticed that a good QA person does is he does not assume; based on
what is said or done, he reports what occurs in the application by testing and
verifying the results.
When are the most critical paths that you have to worry about? When you create,
add/insert, delete, destroy something. Something can be anything, ie, an
object, a window, an array, a pointer, or a mutex. This is something I noticed
back in college when I was trying to create various sort options such as
insertion sort, bubble sort, etc. Classic Comp Sci programming of various
algorithms. The biggest thing I noticed was when I made a mistake on how to
insert or delete a pointer… it could cause the program to blow up. Worst was
when you were dealing with recursion and the operating system doesn’t have
memory management. [Pascal programming on Mac OS 8.6] Nightmare. That was in
high school. heh.
For example some of the testing that devs may miss is starting from a new
account. Starting from a blank new slate and then running the application. You
may run into initialization issues at that point.
Simple cases may work, finding the harder bug requires a better understanding of
behind the actions and when things occur and how.
An example would be sync running and looking at the bookmarks section within
Native Fennec. Two different processes running, one adding items to the
database, one viewing the database. This is where 2 applications are looking at
the same file. (Just a FYI that bug got fixed).
The more intimate the knowledge of how things works, the better your
understanding of where things could intertwine and muck up…. the better your
chances of finding critical bugs that causes crashes or otherwise.
Filed under: mobifx, mobile, Planet, QA, QMO, Uncategorized Tagged: QMO