TestingGeek

As testers, we ask a lot of questions. Sometimes, we need to answer a lot of questions too. Few days ago, I was asked the question:

"What is smoke and sanity testing and how is it connected with high level test cases?"

I asked why he wanted to know the answer and pasted the link to blog post by Michael Bolton:
http://www.developsense.com/blog/2011/11/smoke-testing-vs-sanity-testing/

I told them that it is much more important to practice testing and improve one's testing skills than know answers to such questions. When I mentioned about BBST, I was asked if BBST meant Behavior Based Software Testing. I was disappointed and emailed the tester my first book - 'What If... A collection of tips on software testing'. To my surprise, the tester had already bought this book. I was even more disappointed.

The next day, I received this email from the tester:

We have bug bashes in our company. In every release, the tester invites other testers to test his/her feature. Fresh eyes, different experience usually helps in bringing new test ideas and bugs to the forefront. I usually participate in such bug bashes as it exposes me to different features and test ideas. It is a good opportunity to practice testing and a good break from regular testing too.

In one such testing session, I found a bug where the button was tapped even though I did not tap the button. On further investigation, I realized that the focus of the button was much more than the button area. Let me highlight the issue with the help of the following image.

On the left image, we have a problem. The button's perimeter is displayed by red color.
But when the user taps or clicks anywhere within the green rectangle, the button is still clicked.

On the right image, the focus of the button is limited to the area highlighted by red color. On tapping or clicking outside the red area, the button is not activated.

How do we usually test such buttons?

• Clicking on the button
• Changing the state of the button - enabled/disabled
• Test the default state of the button
• Combining the button action with other actions

I was having a Skype discussion on asking the right questions when someone asks us to test a product. We realized that there were many questions and thought of creating a mindmap to build a mnemonic for easy remembering. It is not mandatory that we ask all the questions but it is a good idea to consider all of the categories.

Here is the mindmap and the mnemonic. Thanks to Michael Bolton. http://www.developsense.com/blog/2010/11/context-free-questions-for-testing/

Context-free questions PCM - TRP - DOT - TED - FIAT P: Permission  C: Clients M: Mission T: Time R: Reports P: Products D: Data O: Oracles T: Thinking T: Testers E: Experts D: Developers F: Feelings I: Information A: Avoid T: Tools

I left Bangalore on 1st Feb on a 2-day trip to Hyderabad. The purpose of the visit was to interact with my Hyderabadi tester friends and also take a break. Anurag Raghuvanshi received me at the Kacheguda station. The train was delayed by half an hour. We took the MMTC train to Hi-Tech city.

Anurag & myself discussed about various testing challenges including

• building awareness about testing 
• continuous learning 
• relationship with programmers especially when they are not in the same time zone
• counting bugs

Junglee Search Bar

Test Ideas

Then we had a pretty long de-brief. It was a two hour long de-brief where we discussed the following:

• Why did I record the session
• How to use Comparable Products heuristic
• What was the test idea behind using script tag attack
• Special cases discovered in the session
• Persistent XSS Attack
• Http codes
• Difference between SupportDetails.com and .net

Plan for a new project

Skype Training from Jan 31st

It's been a while since the last weekend testing session conducted five sessions back to back. Testers who were interested to join were disappointed. Weekend Testing site was not at all updated for a long time. There were multiple emails which did not receive any reply. Multiple comments were not published. So, why this post?

This post is to convey two points:

I am sorry for the unintended break
I got a new job, got busy and can give many more excuses but the truth is I did not facilitate the sessions. I am sorry for it and I promise to dedicate time for Weekend Testing once again.

Weekend Testing is back and is here to stay
This Sunday onwards, we will have sessions regularly - hopefully, every weekend.
The site contents have been simplified

• Removed unused content/options
• Removed registration link - I don't see a need for testers to register. Also, the % of spam users seems to be greater than testers.
• Just the required content is present.

Site: http://www.drawastickman.com/episode1

2012 is almost over. This year has been a very good year for me. I want to highlight five good things from my 2012 experiences.

Two more books in What If... series.
When I wrote my first book, I did not realize that I could write three more. The first book took more than three months for me to complete. The response by the readers and testing community gave me the confidence to complete each of the next three books in three days each. I have testers emails and chat messages thanking me for the book. It was well received. Thanks to the readers, I plan to write more and not restrict to just two books per year.

If you have not bought my books yet, here is the post with the details:
http://enjoytesting.blogspot.in/2012/12/release-of-my-4th-book-on-software_26.html

I joined Fiberlink
Everyone keeps changing companies. I did after five years and six months of working at efi. There was no formal interview conducted. They liked my work, called for a chat and offered me the job. I was very impressed when I saw that they were using cheatsheet by Elisabeth Hendrickson. I could sense the passion they had towards exploratory testing and they were talking about exploratory testing. I knew that it would be fun working with them as they seemed to be passionate about software testing.

Its been eleven months and I am still enjoying. I got the Best New Joinee award and every day teaches me something cool.

Online training on software testing through Skype
I started training over Skype and there was a good response. I met many testers online. And some of them are really good. After completing four batches, I think that I should continue this exercise in 2013 as well. I do train testers on a 1-1 basis. If you are interested, ping me.

Workshop on software testing
Once I conducted the online training, I realized that I can do it onsite too. Thanks to Chennai Bug debug and Hyderabad testers meet, I conducted a one day workshop at Chennai & Hyderabad. Testers liked the presentation style and the content. I learnt a lot about conducting courses.

RTI event
I went to Rapid Testing Intensive event at Orcas Island for a week. The most hectic course I have attended after BBST and the best place I have visited till now. A superb combo. I can safely say that I have restarted my journey as a software tester after attending this course.

With the five points listed above, I end the year 2012 on a very happy note.
I look forward to 2013.

I did not have many expectations when I started 2012. Its the same with 2013. I am prepared. Let's see what's in store!

I have released a book each on my mother's birthday followed by my sister's birthday and my birthday. Obviously, my father was feeling left out and I am releasing a book on his birthday. This is my fourth book on software testing.

Book 1: What If... A question every software tester must ask.


When I logged my first bug, I thought – ‘What if’ this bug was found after release? Years passed, many products were released, and I gained a lot of varied experiences.  I made a few embarrassing mistakes too. There were few instances where I wished that someone had warned me beforehand. So, I started preparing a book of tips targeted at software testers. Special care has been taken to keep each of the 22 chapters short and to the point. Emphasis is on ready-to-use tips which would give you instant results.

Book 4: What If... 50+ tips to improve tester-programmer relationship



This book brings into picture a very important person - the programmer & the programming team. Each one of us might have the experience of working with at least one tough programmer. Some programmers are very friendly and help us with finding bugs. Some of them are very strict with their deliverables and do not respond to any queries outside office hours. Some hardly talk to you unless you ask them a question. There are different types of programmers and bring in variety to our testing challenges. As I write this book, I have completed over six years of software testing and interacting with multiple programmers across different projects within and outside the company. With a rich experience of working with tough programmers, I write this book to help you.

My special thanks to my family members (for having a gap between the birthdays), my friends for accepting me as I am, my friends on twitter, facebook who keep encouraging my work, the programmers who keep challenging me, those who bought my first three books, those who provided me feedback and those who continue to believe in me :)
And of course, my love and thanks to my father who continues to encourage me in everything I do.

How to buy the books:
If you want to buy all the four books, please transfer INR 525 to my bank account or USD 13 by Paypal.

Account Details:
AJAY BALAMURUGADAS
Account No: 00531610015960
Bank: HDFC Bank
IFSC Code: HDFC0000053

Paypal email: ajay184f@gmail.com

If you want to buy just the fourth book, here is the link: http://imojo.in/UZBvi5

:) The Moment...

Dec 05th 2012

Thanks to the organizers and the team behind this event.

Last night when I came back from office, I saw the email from www.99tests.com about a one day contest on Android mobile. I joined the contest and observed that the max limit of bugs per tester was 15 instead of 25 (for 3 day contests). For every duplicate bug one logs, there is a -1 point. So, one has to be careful before logging bugs. And when I joined the contest, there were already 50+ bugs logged. I like to spend the initial few minutes of any contest, trying to understand the purpose of the application, the focus areas by the other testers and the validation strategy by the contest owner.

I wanted to go through every bug logged and at the same time understand the application quickly. I started with few bugs and then an idea struck me. Why not map the bugs and categorize the features too as parent nodes?

This is what I got after 25 mins:

Mindmap of Bugs This way, I went through every bug and still made a high level model of the entire application. I liked it and after three hours of testing, I got the 7th position with 100% valid bugs. I logged 6 bugs. Maybe, there is a better approach but I liked the approach of mapping out the bugs before testing. What do you think? Do you have a better way?

One of the good things about working in a cool company like www.maas360.com is that the management cares about learning opportunity for its employees. It understands that if the company has to be at the top, the employees have to work on their skills. One of the easy ways is to provide access to resources which will help the employees - books, conferences, contests, tutorials, memberships and so on. This is very easy to do but very few companies encourage such learning opportunity.

As soon as I got to know about the book https://leanpub.com/testmobileapps by Jonathan Kohl, I wanted to read it. The request was approved and I got a chance to read the book on the same day.

As seen on the site, the book covers a wide range of topics necessary to know about mobile app testing.

What did I learn from this book:
Reading the book was a very good experience. Every page had something new. I liked the initial chapters a lot compared to the strategy, planning chapters. I wanted to read this book on my mobile phone - landscape mode using QuickOffice Reader. This experience helped me find some bugs in QuickOffice Reader application and I could also experience using a mobile app.

Examples of different types of bugs
I like the books where the authors don't just mention what to do but also highlight their experience when they followed their own advice. Jonathan Kohl does a great job in highlighting his experiences in testing different types of mobile apps and what kid of bugs he found. Some of his bug stories are like the detective puzzles and teach you a lot.

What's inside a mobile and how it can affect tests
To be honest, I knew very little about the mobile hardware before starting this book compared to now when I am writing this blog post. You regularly move your mobile but are you aware of which sensors are affected? Do you have any idea of how your test results are indirectly and to some extent, directly affected by the mobile hardware? This book has a dedicated chapter and is a good starter for someone like me.

Different Tours
Though there are many tours mentioned in this book, I like the Gesture tour. Pinch/Tap/Flick/Swipe/Press - Which gesture do you like? I tried few of the gestures and found bugs specific to them. There are many different types of tours mentioned in this book. Ok, he not only mentions them but also explains as to how to conduct each tour.

Testing Mnemonics for Mobiles
Jonathan Kohl - creator of I SLICED UP FUN mnemonic also explains about few other mnemonics in this book. As a tester, its good to know such mnemonics so that you can apply them as and when required instead of thinking of new tests every time.

Dealing with Intermittent bugs
This topic is not new to many testers. James Bach talks about such bugs here - www.satisfice.com/blog/archives/34 BBST course - Bug Advocacy section too highlights tips to tackle such bugs. www.testingeducation.org/BBST Jonathan Kohl talks about intermittent bugs found during testing mobile apps. Small distractions, movements, network changes, orientation differences - how can they affect the bugs - the topic covers them all.

The book is worth the cost. Hope Jonathan writes more such books and continue to help the testing community. Thanks Jonathan Kohl.

Give "time", some time. When your teacher gave you time, you did not complain. Now that you have become the teacher, you forgot that the student needs time?

Apply this to any practice we start. Just because few teams got to a great start, it doesn't mean that other teams should match the standard. Not everything can be measured objectively. And if one tries to measure, I have enough examples where the behavior can be tuned to meet the metric.

If you feel that this post doesn't make any sense and is very disconnected as a whole, its ok. I wanted to test blogger app.

Maybe, I should google for "learning mechanisms" or read on wikipedia.

I conducted a one day workshop on Nov 27th at Microsoft India Development Center (MSIDC), Hyderabad. Close to twenty five testers attended the workshop.

Highlights:

• Microsoft campus

• Presentation on Microsoft Test Manager (MTM) tool

• First mindmaps

• Feedback for me

• Check-out comments

Everyone had good things to say about the workshop. This is exactly the reason why I give them a blank notebook so that they can give their feedback in private. At the end of the workshop, each of the testers told me how they felt that their time was not wasted even though it was a saturday. One of them missed a movie and still did not feel bad :)

Thanks to the Hyderabad testers. My only suggestion is that if you are not sure of attending, don't block seats and prevents others from taking part.

If you want me to conduct a hands-on workshop in your city, email me [ajay184f@gmail.com] Till next time, Thank you.

Thank you Hyderabad

Image Credits: http://www.graphicsgrotto.com/clipartpictures/comments/thankyou/

At the end of Session 1 & Session 2, we preapred two mindmaps about the product & the testing plan.
The corkboard image is also put up below.
Thanks to Anurag & Raghavendra.

Consider this for testing

What to test

Testing Notes

One of the reasons I travel at my own cost to present workshops at other cities is that I get a chance to meet  other software testers. I arrived at Hyderabad on 27th October early morning around 5.30 am IST. The first tester I met in Hyderabad was Raghavendra who received me at the railway station. From there, we went to his room, got ready and left for the venue for the workshop. The experience at the workshop is for a different post. I missed my train and had to stay one more day at Hyderabad. Raghavendra was generous enough to accommodate me in his room for an additional day. His hospitality is definitely commendable - right from food, entertainment facilities, the unlimited energy when asking questions on software testing and so on. Thanks Raghavendra.

Raghavendra wanted me to explain my testing approach from scratch. He wanted to know how I test, what tools I use, what bugs I find and so on. Though we were tired after the workshop, we were awake till 11 pm IST discussing about software testing. The TV was on mute and we don't know when we dozed off. The notebooks were filled with lots of notes.

Plan for Sunday
Next day, as planned we got up early and I invited Anurag - a budding software tester whom I met online in my Skype training class and also at the workshop on Saturday. We planned to test a product for close to four or five hours and present a test report.

We started at 12.06 pm IST and decided to use corkboard.me to share notes.
The application to be tested was 'Flipkart'. We spent the next 45 minutes testing and noting the issues, tests, tips, notes.
Attached are the corkboard images before and after the 45 minute session.

When we started

After Testing Session 1

          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 ( http://bit.ly/SYpIlG ) my testing sessions, this too was recorded. The next step was to follow the advice given in BBST Bug Advocacy Course (Remember RIMGEA? ) 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

I received my Power Searching With Google certificate last week.

Sep 24 to Oct 10 2012

My next target is Coursera courses. There are plenty of them. I signed up for the Python course which started today. And the next course I want to do is the Think Again: How to Reason and Argue
This should take care of this year. Hopefully, these courses help me to become a better software tester.

Meanwhile, I created a video for Bug DeBug Facebook channel on how to get started with mind maps.
Its less than five minutes long. Get started on your mind maps.
And thanks to Sudhamshu, Bharath & everyone involved, the next workshop is on Oct 27th at Microsoft, Hyderabad.

The first batch started in the month of April. It was well-received and you can find the comments here.
Encouraged by the participants, I conducted the second & third batches too. I have learnt a lot from the three batches, the participants, the drop-outs, the assignments, the emails and the feedback. Few of them attended all three :) Thanks. While I conducted three batches, I also attended the online 'Power Searching With Google' course.

To complement the online course, I have started conducting onsite courses on Software Testing with Exploratory Testing as the main theme. The Chennai workshop was a first time experience of conducting a full day workshop. So, I am back after a month's break. Some of you were asking me about the fourth batch and here is your chance.

Course Contents:

• Mind maps - Introduction, Creation, Different types, Tools, Tips, Collaborative mind map.
• Testing Session - Bugs and Oracles, Mnemonics, Heuristics, Tips, Intermittent bugs.
• Tools - Screen Capture, Screen Recording, Note-taking, Shortcuts, tips to improve productivity.

What is different in fourth batch course content?
I have slightly modified the content and will be covering few topics in detail. This course will be slow and detail-oriented. I want to answer more questions in this course compared to the previous three batches.

How do I join?
Ping me on Skype [ajay184f is my Skype ID] and let me know that you are interested to attend the fourth batch of my hands on training on software testing.

Date & Time?
Every Monday, Wednesday & Friday starting October 10th till Nov 2nd.
Time: 10 pm IST to 11.15 pm IST
Cost: Its Free. I need your active participation, nothing more.

Any questions?
If you want me to conduct an onsite training in your city, email me [ ajay184f@gmail.com ]

Lets meet, test and share what we know :)

You can still take the course at www.powersearchingwithgoogle.com
Calendar is booked with lot of tasks :)
Next week - New batch of online training, this month - workshop at Hyderabad, till Dec - important features to be tested at office,  project to be submitted for my MS degree... Life is busy and I am loving it :) 

This is going to be a short post.

I conducted a one day workshop at Chennai on Sep 22nd.

Thank you Chennai

Key points:

• Building a feature map and providing feedback.
• Few exercises on building a map, bug-hunting, recognizing oracles.
• Live demo of building a map, test session, using Rapid Reporter.
• Answering questions on software testing.
• Multiple tips to improve productivity & find bugs quicker.

Thanks to Mohan Deepak who gave me this link few minutes ago:
http://www.google.com/insidesearch/landing/powersearching.html

On first impressions, this looks good. I have set my eyes on this for the second week of October.
What about you?

Once again, thanks to Mohan Deepak
Update: Starts on Sep 24. So, hurry up :)

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!