Before I go talking about exploratory testing, I will say that there are certain things that you do have to prep yourself up for when exploratory testing and reading about this on my blog. These are my opinions, not necessarily what’s reflected at any company. Note : if I do get an order to do something from my boss or higher, I do it.
a) Open your mind. I dislike how some people think that doing the same thing over and over for years on end makes you a better person for the job. Sure, you might excel in the things that you do everyday, and ya, sure… there needs to be some regression testing… Evidence shows that you won’t find as much new bugs, and more over, in terms of technology, eventually you might get out dated. You’re doing it to yourself. Trying to push down new working ideas, just because you like nothing to change will out date yourself. Eventually something new will take hold. My dad had stated there are two fields especially where you have to keep up because the pace is fast. Technology and Medicine. I believe he’s right. I try to push myself to learn new things all the time (regardless of it being in Technology or not).
Exploratory testing is about learning as you go, and you have to keep pushing yourself to learn new things and try different things. For the most part people concentrate on doing regression testings in most places I’ve been at and wonder why they can’t find new bugs. Then they do the same thing over again. Why? Because so far there hasn’t been a successful way of measuring quality, so as far as I’ve seen QA folk continue to do what management has asked them to do which is do regression. Because it’s understandable and it can be metricated and measured. It has to be done… because we don’t want to be embarrassed due to bugs we already had fixed and regressed. Sure. I get that. Statistics shows that going over the same thing over and over again though is going to yield a lower result unless something changes. Scientific approach is to keep all things constant except one change to see if it affects the outcome.
b) Which brings me to my second point. Be detailed oriented and have a scientific mindset. Sure you can do a bunch of various things and find a bug; having said that try reproducing the bug… because the developers might have to in order to figure out the code path. Having a scientific mindset of tracking what you did exactly when you did it to get to a bug helps. If you forget… reset the device or computer or whatever you are working on to a point you know. Generally speaking, rebooting is the best due to possible corruption in memory, but you could also quit the app and then reopen it.
Yes, people talk about being methodological and having a scientific mindset when it comes to doing QA. So I’m going to attempt to give an example, since people often talk in broad terms and think oh yes, that’s good…. when it’s hard to really see if they know what they are talking about because they speak so generically. (I admit I am guilty of this as well).
One of the ways that I do testing is that I’m looking for something specific. Whether it’s validate a requirement, or figure out a bug… I am targeting a result. I try to keep my environment in a state that I understand, meaning that I may reboot first, then do my steps to execute. When I execute, I take mental note of each step I do, from clicking a button to swiping to any other action that I do on the device or application. When I reach the goal, I then try to tack on one at a time a different approach or a different gesture, which I might think may lead to a bug. During the time I do each step, I try to note if I see any bugs along the way. I do not look at just the target, but also what’s going on at the same time. All this I mentally keep track of from test to test until I forget which state I’m in or if I run across a bug. I reset the device and then retest from there if it’s a bug that I’ve encountered to verify the bug steps to make sure I have the repro steps down correctly. I clear my head of all those other steps and repeat.
c) When I stated keep aware rather than focusing on the target, that is exactly what I mean. When you get to adulthood, you try to go straight for the target but you end up having blindfolds to everything else and end up missing things. This has to do with human cognitive behavior: try seeing how many times the basketball passes between the white shirted folks in this video : http://www.youtube.com/watch?v=hwCzasHBXNc
This is a classic case of human cognitive behavior from what I understand.
d) the knowledge of disciplines helps :
Computer science being a big thing. Whether or not you did or didn’t get a degree in it doesn’t matter as much as knowing the background as most of the theories from college still do apply. Not just the self teaching discipline. This might be different from other degrees, I can assure you that it is true of computer science though. When I went to university, there was no such thing as a QA discipline. Developers wrote their programs and debugged their own code. Everyone in university was a developer. From there it actually helped to understand where bugs come from. Not only that, there wasn’t necessarily classes to teach you exactly how to do things. You had to figure things out on your own. What they did teach you is fundamental concepts. Knowing concepts is great, but you do have to apply them. One of my industrial engineering teachers told me, “There’s booksmart and there’s street smart; booksmart are the people that are great at concepts, street smart are people that are good with practice. Be both as it’s rare that most people are both.” I took a class in CPU design, compiler design, databases, networking, etc… and from each of those classes, there are concepts that I use currently in my job. My work experience from tech support gives me, as I often hear from the customers themselves what annoys them the most. After awhile, I got sick and tired of hearing it from them because not much changes, I decided that I wanted to be able to fix the situation… being in QA helps with that… It might not necessarily be the end goal. Just to note, I do learn some things from other people as well such as photography from my friends (and the basic concept from bmoss,… I ended up using the concept at work and placed my black bag on the desk where the sun shines from the most and glares into my eyes.. and that helped reduce the glare)
I also studied art some in high school as well as some in college. I self teach and dabble in cognitive behavior as well as graphic design and music. Concepts can be directly applied to visual and audio implementations. Being aware of various languages help and the difference between them for L10n.
Basically the more you know, the more it can help… as knowing more context helps with being a QA person.
e) Changing your mindset:
When I was in tech support, I had this notion of, the product is working right, the customer’s issue is the only problem with the product. The main idea was to help the customer resolve their issue any which way you can. Work arounds were only acceptable if the customer accepts them, but you try to figure out as many work arounds that might be appealing to the customer if you could not resolve their issue directly. When I was in tech support, I was always within the 10 % of the highest satisfaction numbers and the lowest call back rate. One of the biggest ways of achieving that was just to put yourself in their shoes. They are calling because they need help. The second biggest thing is that you have to set their expectations, sometimes I set it way lower… and then surpass it. Surpassing is easy if there’s gotchas that you can warn them about ahead of time that you know they will run into. If I was in their shoes calling tech support… 1) I would not want to be calling tech support in the first place… and 2) I don’t want to have to call back… if the tech support gave me tips to help me from calling back… I would give them higher ratings.
Anyways, that was tech support. I didn’t find much bugs when I initially started QA. Why? Because a workaround is a bug. Think about that.
QA mindset, “this application is full of bugs and I need to find the critical ones that endusers are going to hit”
There is not enough time to fix every single bugs in a product cycle. You have to focus on the important ones that people are most likely going to hit and work your way down.
f) Understanding the architecture and the product that you are working on. Having an insight on how things are put together helps. In mechanical engineering and industrial engineering, you hear about how if you bend something enough times, it will eventually break. You also do calculations to make sure things don’t break due to pressures etc, and you reinforce the weak points. The analogy to software is the same for the QA perspective. You target where things might break, from experience (from having written bad code yourself or other QA means such as reading past bugs, etc.)
g) reduce interruptions. Sometimes just concentrating on things for a couple of hours helps… beyond that most meetings that I have been to so far are just discussions that are like making sausages. It’s just messy and not directed. The ones I do find important are the ones that either a) plan for the future on the projects that I work for, or talk about b) current development on the projects that I work on or c) some of the bug triages. All of the ones I find important have a set agenda, clear cut direction and focus, and a list of action items of what actions people need to take next.
Filed under: Uncategorized 
