Learning from RTI - Recording my testing session

Can you replicate the bug again for me?

How many times have you answered the above question? It might be asked by testers, programmers, managers and anyone interested in the bug. Sometimes, even you will like to replicate the bug. So, lets consider that you discovered a bug, a good bug, a important bug!

Now, you need to replicate but you are not able to! Oh, what do you do now? Try again? Call for help?
You don't have the proof but you have seen it. You were smart enough to take a screen shot too immediately. But, no one is ready to believe you. No one can help you unless you identify the exact steps to replicate the bug. This has happened to me many times. After attending the Rapid Testing Intensive event, I learnt a valuable lesson:

Be ready for scrutiny with some proof of your testing activity.

James Bach recorded most of his testing sessions. In fact, Rob Sabourin had all of his sessions recorded with audio! I was impressed with his work. The first thing I did after returning to work was to install the Fast Stone Capture application. I wanted to test like the experts. I wanted to improve my test reports and testing efforts. I had Jing already installed on my machine but the limit for recording was 5 minutes only. I started recording my test sessions. The first few recordings were huge and covered some unnecessary stuff too.
When I say 'unnecessary stuff', I don't mean Facebook, Skype chats, Google Chat pings. What I meant to say was that it recorded whatever I typed in my testing notes, the time I was browsing through multiple folders, the emails I checked, the testing status blog I updated about the testing session.

Later, I realized that I could anytime pause the recording, complete the tasks and resume recording.

Now, for the benefits and questions part:

What did I gain:

• A proof of my every testing session: In previous releases, I always had the doubt if it was tested on build 17 or build 15. I can now go to the particular folder, watch the appropriate video - I save my videos with an appropriate name - and figure out if it was tested or not.
• Attachments to the bug reports: People are now able to figure out the issue better by going through the attachments. This has saved me a lot of time.
• A happy feeling: I am open for scrutiny once again. I have better answer to what I did in the given time and why a particular test took X amount of time. As a tester, I feel complete (read satisfied) now after this activity.
• Uninterrupted testing activity: If I notice any problem, I don't stop there and worry about taking a screenshot, calling a programmer or testing on a different environment. I either pause the recording and save immediately or note the time on the video. I will get back to it later.
• I learn from my testing sessions: I play back the recording in my disposable time and notice patterns of what I do well and how I waste time. The next testing session, I try to incorporate my learning. This is important - As Robin Sharma says - "Many of us are busy being busy". If we don't learn from our mistakes, how will we improve?  

Now for the questions:

• Is FastStone Capture a free tool? - No, its available for free trial for 30 days. Ask your company to buy the license. Use it for 30 days, demonstrate the value addition and if they still can't afford the 20 USD license, I am sorry. 
• What about the quality, size of the video? - I like what I got out of this tool. A very important point to note is that the tool saved a eight hour session successfully. I had left the recording open and forgot to stop it. It crashed after 8-10 hrs maybe BUT it gave me the option to SAVE the session. 
• Is it just a screen recording tool or can it be used for screen capture too? It has very good screenshot editing tools in built and many other options available too. As I use Jing for screenshot, PotShot for screenshot at periodic intervals, I don't use FastStone Capture a lot for Screencapture.
• Have you tried XYZ tool? I don't know :) Please let me know which tool you use?

This is the first post of a series of posts planned on my learning from Rapid Testing Intensive (RTI) and how I have implemented in my day to day testing activity.

As I mentioned on the last day of RTI, I feel like I am restarting journey as a software tester! 

Resource:EnjoyTesting

Bug Investigation - Never Give up...till you tried enough

After many days, I got my office laptop home to verify some bugs assigned to me. Some are disciplined enough to focus on only the bugs first. I belong to the category of people who are inquisitive enough to probe areas closer to the bug, find new bugs and log them. On verification of one such bug, I noticed something strange.

The Bug Appears
There was a popup and there was a browse button to choose a file to upload. I clicked on the Browse button but nothing seemed to happen. I clicked again and the file picker window opened. I was pretty confident that I had clicked on the Browse button the first time too.

Confidence doesn't help you unless you have proof especially in the case of bugs.
And as I have got into the habit of recording my testing sessions, this too was recorded. The next step was to follow the advice given in BBST Bug Advocacy Course on encountering a bug. I tried to identify the critical condition, recorded a shorter video and  logged the bug.

The next day morning, the programmer pinged me on Skype asking if I could still replicate the issue?
I could not :( 
Immediately, I noticed few differences.

• Firefox browser was updated [The issue I replicated was on a lower version]
• This build was deployed early morning whereas I had logged the issue on a previous build.
• The programmer was testing on a different account. 

The advantage of recording the sessions is that I don't need to remember every detail of the bug. The important, obvious details are recorded and my mind is free to remember some other information.
I replayed the video. The programmer was also watching it. I could not replicate the bug.

It is easy to assume that the different factors has a major effect and close the bug as non-reproducible.

The bug is Nailed
I did not give up. Points from James' blog post were crossing my mind. I observed the video more keenly. Immediately, a thought process started. The video showed 12:27 AM - which means - I tested at home - meaning - a different network - TATA PHOTON data card. Bingo! Is the bug caused by difference in network?

I always carry my data card with me - what if the office network is down - I don't want to depend on one factor alone. I immediately disconnected from the office network and connected the data card to the laptop.

The bug was reproduced. I was happy that a combination of factors helped me replicate the bug.

Proof (Recording), Resources (Data card), Observation (Time & inference about the network speed).
I wanted to share this story - its like the war story where you successfully defeated your enemy.

I would love to hear about your war-stories.
PS: Did you know how I searched for the blog post by James. Refer the image below. I applied something which I learnt in the Power Searching With Google course. What is the use if one doesn't learn and what is the use of learning if its not applied? :)

Power Searching With Google course lesson

Common mistakes in Testing

Mistakes in Testing:


1. The Role of Testing: who does the testing team serve, and how does it do that?
2. Planning the Testing Effort: how should the whole team’s work be organized?
3. Personnel Issues: who should test?
4. The Tester at Work: designing, writing, and maintaining individual tests.
5. Technology Rampant: quick technological fixes for hard problems.

Common mistakes that I see are:

• Communication: All team members need to be able to communicate with each other. A tester needs to know what to test, when to test, and the importance of what is to be tested
• Ability to change: Schedules & resources change so everyone on the team need to be able to understand that change is inevitable.
• Documentation: this is key especially in test steps, defect reports and findings reports. If you find a defect you have to be able to allow the next person to recreate it by providing them with detailed steps.
• Automation: Not everything can be automated nor should it be. Pick the tests that you find you are testing the most, smoke tests are great candidates for automation.
• Results: Don’t be fooled by the results. If a result shows that a test failed, investigate it before throwing up a flag.

Resource:  PDF called “Classic Testing Mistakes” by Brian Marick.