Exploratory testing and bug hunting fun

-
Being Developer In Test specialist, I do lots of coding, automating, meeting, refactoring, code reviewing and other related things these days. I do enjoy most of my daily activities, and I didn't think that being forced to do some manual testing stuff can be anything interesting to me.


Chances turned, though, that I was the only QA-focused specialist in a team and we had to provide quality feedback on a product that had had little (close to not at all) unit test coverage. Being inspired by James Bach's and Michael Bolton's Rapid Software Testing methodology, I devised exploratory test session plan for the application, distributed activities between team members and did my best to find any possible issues in the application we worked on.

Being overwhelmed by regular work activities, I couldn't even imagine how fun this bug hunt could be! I found quite a few issues, and I felt being House, M.D., detective Columbo, or somebody of a similar fashion. I was chasing after one hint to another, learning a product, trying to intuitively find bug's den. Some assumptions were correct, others were absolutely wrong. Nevertheless, overall activity was extremely joyful for me (can't tell what others thought, but nobody kicked me so I hope they were at least neutral ;).

At that point, I cannot tell if it was me practising testing skills all those years what made me succeed, or application just so buggy that it was extremely easy to find one (new sessions will definitely help me in finding an answer to this question). What I can tell, that hunting bugs is fun, and Exploratory Testing is probably something that makes it THAT fun activity for me.

There's nothing interesting about going through the very same test case again and again. But silently (and joyfully screaming from time to time) chasing bug culprits one by one is absolutely different story, trust me.

The other, rather funny thing about that experience was that such exploratory sessions from my perspective were ten thousand times more efficient in terms of learning product we test in comparison to knowledge transfer session or reading documentation. Finding bugs there and seeing them fixed was nearly like seeing your baby growing. It was probably the perfect proof for me that I had chosen a proper profession.

Comments

Post a Comment

Popular posts from this blog

Test automation framework - do I need it at all?

-
Image
While there're lots of information published on the internet about how one should develop/buy a Test Automation solution, there's an elephant in the room - which is the fundamental question "Do I need to do it at all?". That is a good question. While I think that there’re some legitimate contexts where product/project/team can benefit from having a sophisticated test automation solution/framework, my general rule of thumb is “If you need a framework - you do it wrong” . There’re at least several decent papers showing the benefit of unit-testing ([1],[2], [3]), while I could not find any research proving that system level tests could bring better results. Please let me know if you can prove me wrong. There’s at least one half-scientific paper showing the benefits of unit tests in comparison to integration/system level tests [4] There’s a good paper bringing a notion of running/writing and maintaining test vs. the benefit of having/running it at...
Read more

Efficient test automation - Secret #1 | Test Club

-
Image
It seems everyone talks about efficient test automation, but not so many people have actually seen it! To cover this I decided to make several videos regarding the secrets of efficient test automation. Today we will talk about the first (and, arguably, the main) secret - realistic expectations. Very often, test automation projects or initiatives are started with the following unrealistic expectations: "Test automation will replace 'manual' testing" "Test automation will provide fast results and benefits" "Test automation efficiency depends solely on test automation engineers" Unfortunately, all those expectations are not realistic! Watch the video to know more!
Read more

An alternative to ubiquitous UI-level checking - Subcutaneous tests

-
Image
Let's assume a hypothetical situation - you were assigned to a project to help with the "test automation" initiative. You have a huge "test plan" as an input, containing hundreds (if not thousands) of "test cases" and you need to do something about it, quick. Problem statement Your first urge (if it is a Web application) may be to write some UI-level automated checks using tools like, you know, Selenium. In fact, there's a huge demand for such "Selenium test automators" in the industry these days. But please, please, don't do this. There're lots of things which make UI-level automated checking the least desirable approach: UI-level automated checks will be slow. There's just no way to avoid it. You can parallel them or do some other tweaks to speed them up somehow, but they still will be slow. UI-level automated checks will be flaky. Partly - because they're slow. Partly because Web browser and UI interface w...
Read more