How I Became a Tester

Last month I was asked to conduct an online webinar on how I became a mobile tester. It didn’t work out because of my crazy work schedule and miscommunication with the event organizers.  However I had an opportunity to work on my topic with James Bach. I got some helpful guidance, questions and tips from him and then decided to turn the content into a blog post.

I want to mention that James is probably the toughest mentor that I have trained with. But he is also the most approachable, sincere, committed, consistent teacher, in addition to being extremely smart and helpful. I came to him originally without any formal testing background or training. I feel I am a better tester since I started training with him and the fact that he is just a Skype away gives me a lot of confidence when I come across difficult situations in my professional endeavors. I have met many other role models and mentors in our global testing community but imho there is no one like him and I am grateful that I found him.

How did you get into testing? Why did testing attract you?

What initially attracted me to testing was the never-ending process of puzzle solving. I enjoy the creativity involved when you have to come up with a scheme of different ideas and approaches to dig into a program and find what’s broken or what may potentially cause a problem.

The first bug (exploit) that I found initially got me into trouble, though it turned out to be a blessing in disguise. As a Jr. database developer I was asked to help test an order management system workflow - drawing pictures and maps and thinking about ‘what if’ scenarios. While creating a new order as a user I was required to populate specific fields on each screen in the order flow (for product order, product order type, service order, etc.). As I was going from screen to screen, validation seemed to be working properly even when required field values were either missing or data was entered incorrectly. There was also a navigation bar at the top of the web page that allowed the user to go from screen to screen, bypassing some screens that had already been reviewed. I was curious whether I would be able to place an order while bypassing some of the screens. Apparently yes – even though they went through with errors.

I checked for the orders in the database. There were records of all of my test product and service orders with some of the required fields being null. I mentioned this to my team lead but he didn’t take it seriously and advised to conduct further investigation. So I drew a matrix of different order combinations (by service, type, provider, and many other combinations), went though the system and identified screens and fields for which validation at the final stage was not present. The assumption was that the user would go from screen to screen and populate all the required fields either himself or when prompted.  I checked the code and even though I was too junior to fully understand the validation and conditional logic, I noted parts of the code where I thought validation was missing.  

I logged a bug and alerted our QA Manager. I completed my investigation and proceeded to the next task – testing order search. After searching for a couple of my buggy orders I noticed some excitement and discussions where people were complaining that the search page is broken because someone MANAGED to submit orders with missing required fields. Since the first few digits of the Order ID were the same for each order, relative search (or search by wild card) did not work as the tool was trying to return all the orders (numbers) that were submitted with errors. Eventually our test web app server crashed as most of the team was searching for orders at the same time and unless the exact value was entered in the order field, nothing was returned.

There were about 40-60 developers on the team and each was trying to code, unit test and help out with system integration testing as we were short of resources. Strange errors were popping up when a search was run by provider name and using other parameters. I realized what I did and felt completely mortified. I was a junior developer. We had 2 days before the upgrade release. No one noticed this bug in production and here I was poking my nose into things I wasn’t supposed to and I didn’t even know anything about testing. I remember that my dev team lead emerged out of nowhere and started yelling at me. My fellow developers looked at me as if I was a villain. I was almost in tears but something inside of me rebelled and I blurted out the following – ‘Well, someone should have thought about it when they worked on system engineering and design. Eventually the user will try to look for a shortcut and create a real problem’. There was silence. I don't remember all the details but I remember that my dev team lead saying something like ‘you are cursed to be a tester’.

I remember that the best minds on the team were ordered by the project manager to conduct a major rework and fix the problem. I was the most hated person on the team. Though as time went by people started treating me with a lot more respect and the PM and other teammates started asking me for recommendations on testing ideas.

What surprised you about testing?

•       What a challenging process it is, especially bug advocacy

•      How much it is not understood by many in the Information Technology field

•       The disparity in skill levels of testers at the same pay grade

What do you think makes you able to see bugs that others don't see?

•       I am not afraid to try new things, take risks and explore (I try to turn all of my senses and really feel the program as if it is a living organism)

•       I try to come up with “out of the box” testing approaches

•      I became a better tester after learning about context-driven testing

What specifically do you do to train yourself?

•       Learn about testing strategy and bug reporting

•       I read books, blogs and articles on testing, design and the mobile industry

•       I talk with other testers and developers

•       Took courses through the Association for Software Testing.

  

What role does community play?

The testing community provides moral support and constructive criticism.

Is there any part of what you do that requires discipline?
Every part of testing requires discipline. You need to stay focused on your testing objectives, scope, missions and targets as well as time, priorities and ego management.

What was difficult or surprising about mobile testing? (These are just a few things that came to mind but my answers are by all means not complete. Please feel free to comment.)

Difficult

- Testing in a fragmented environment with so many unknowns and challenges (e.g., connectivity – switching from network to network; variety of device models and OS versions, various apps running in the background that may conflict with the app being tested)
- Dealing with stakeholders who think in “Website” terms/architecture vs. mobile.
- Working with people who don’t understand what testing involves and who think that testing/validation/evaluation can be done in 5 minutes. 
- I can also relate to the Top 7 Quality Issues with Mobile described in the 'Test Automation of Android, iPhone and iPad Apps with Zap-Fix' article at http://www.mobileappstesting.com/

Surprising
- Never thought it could be addictive (Yes, this is a picture of my purse with test gadgets ;) ).

Although I was not able to conduct a webinar on this topic, I decided to make a blog post out of it in the hope that it may help some people get started in testing and maybe make some people laugh.

I have done my first webinar for the uTest uMentor program on Introduction to Mobile App Testing. I realize that I have a long way to go but it was my first stab at it. Hope you find some ideas helpful.

http://help.utest.com/testers/crash-courses/webinars/mobileapptesting