No bugs- Well built app or inefficient QA?

As a QA, when you first start to test an application, the expectation that you have is there would be many bugs and that you are there to uncover them! Did I just read your mind? Well, just like you and I, most of the QA would love to log as much bugs as possible in the shortest duration. No matter if the bug is valid, invalid, or even duplicate, a bug is a bug and it brings in so much of happiness for a QA to uncover it!

Testing a crowdsourced project is different!

Little did I know about crowd sourcing opportunities when I quit my full time job few years back. Crowd sourcing was fairly a new term then, at least in this part of the world. Google search helped me identify few crowd sourcing websites offering work to India. I did few data annotation work that earned me few dollars. But I always wanted to get back to do what I love the most. After registering with many sites, one day I received an invite mail for a testing project.

Reject a Build? Talk to the dev team first!

Few years back, when I was in a Project Initiation meeting and was discussing the ways of increasing the efficiency of QA, our Onsite Manager all of a sudden asked me a question, “Can your team write functional test cases based on requirement and can we start development based on the test cases?” The idea was a Test case driven development. Both I and the lead developer were fine with the idea. The development team was more than happy as they felt that our QA team would then stop logging functional bugs J . The Initiation meeting concluded with the resolution to follow a Test case driven Development for the first time.

I attended all meetings with the stake holders, held many rounds of discussions to understand the requirements, got all my doubts cleared, and started working on the test cases with my QA Team.  It was fairly simple for my team as our task was to prepare the functional or high level test cases which the dev team would use as reference. It was a purchase requisition application; we wrote test cases for creating a requisition, submitting it, sequence of approvals, search, reports and configuration screen for adding, removing items. The dev team developed a mock-up of the screens using the test case as reference, and got approval for starting the development work. When the dev team was busy coding, we were busy writing test cases for all pages in the application.

Finally we were given a build for testing; we started with a smoke testing of the application. Huh, the first create landed us on a server error page!!!  Who is to be blamed for this? We rejected the build, rightly so because we wouldn't be able to do anything with that!  Few rounds of email exchanges, and then came the final email from the Project manager, the application failed because there was no test case for capturing the server/DB configuration changes!! Both dev and QA were held responsible for the mess!  I was shocked because the QA team was asked to write test cases for functional requirements, how could the dev team depend on us for server or DB configurations?? A simple 10 minute work for the dev team to change the settings in DB would have helped us to continue with testing, but both Dev and QA team were busy in proving that none of us were responsible. Finally a meeting was set up by the Onsite Manager, with all stake holders, and each of us were given a to-do lists. After a day we could start our testing effort. The testing went on well and we were happy that dev had developed the application based on our test cases. One test case for changing the DB settings would have helped all of us and the stake holders would have appreciated our work for ensuring that we covered all features in our test cases. A quick chat with dev team or the dev lead instead of a build reject would have helped both teams to showcase a successful project, and that was a great miss, that I regret even today! A lesson learnt- Talk to dev team, before you escalate!!

Httpwatch -my first tool to find how a webpage loads

The first time I used this HTTP watch tool was about 6-7 years back. Everything seemed ok in the application that our team had tested. The application was good to go live and we were fairly confident about the success of it, except for its performance. We didn't want too much of testing effort to be put on load testing as we were running short of time and resources. All we wanted was to know how soon the web page loads for the frequently used pages in the application. So a quick Google search, and we landed upon this tool. I had my own apprehensions about using the tool as I was not sure if that was the right one for our use. I decided to try it out and installed it. There are two versions. HTTP watch Basic and HTTP watch professional. I installed the basic version.

Now what is this HTTP watch? For beginners like me in simple terms, it helps one understand how the webpage loads, provides details on various  parameters like the elapsed time, response time, the cookies, the HTTP information to monitor etc. For example, a user visits a site, the page load time is really long and the user is annoyed, leaves the page. This is where the HTTP watch helps the dev and QA. It helps one to know how much time it actually takes for the page to load, gives the exact time and the details of all parameters, which helps in easy debugging.
The extension integrates with most frequently used browsers like FF and IE and provides info on Cookies, query strings, HTTP/HTTPS traffic updates etc.

Here for example, take the site www.google.com, you want to know the response time of the page. 

Step 1: Complete the Installation of the plugin.

Step 2: In FF, you see the extension under the Tools Menu and for IE, do a right click and you see the extension.

Step 3: Enable the extension and you see the pane.

Step 4: Now click on Record button, and type the URL , in this case www.google.com
Step 5: This is what you see in the HTTP pane.

Step 6: You get to see details as shown in the pic above.


This is a a simple tool doing simple things, and I have been using this tool for many of my projects.

Regression Testing --Assumptions are worst enemies

How many of you are like me thinking regression testing is the easiest part of testing? Ha ! I dare not anymore! I was thinking on those lines until I encountered a major issue in the system that I tested  minutes before it was about to be moved to production. This happened years ago, when I was in the initial 'fresher phase' (<2 years)of my career. Things do not seem to be as good as they ought to be.  I was testing an application in one of my earlier companies. We did not have any formal team,and each of us were assigned a module to test. I was more than happy with the module that I had to test as it was full of bugs :) what more can a tester ask for ? everywhere you click you see an error, and nothing worked! I logged bugs in 100's and was pretty confident on my work. Then came the fixes, with a scintillating Ux. Logging 100 bugs is easy, but trust me, verifying 100's isn't that easy. I verified all bugs and completed few more rounds of testing, the bug count reduced gradually and everything seemed to be good and neat. With just a couple of hours before production,came the final build for regression. When there were literally no bugs in previous version, little did I realize that I would encounter any major issue.I assumed that what worked earlier, would work fine in that build as well.I could hardly think of any issues after working so hard the whole month, everything was looking good to me. Stuck in front of system and a piece of module for a long time, did take a toll on my thinking ability. I could not think of anything else, and literally signed off the testing for my module. The go-live process started and each of us were so confident about the modules that we tested. With just minutes to go, to get the help file, I logged into the system in QA environment. I wanted to check my module one last time. Ha! the submit doesn't work!!! what a crap, how can it be, immediately cleared all cache, changed browsers, did all things that I could do, the submit just doesn't happen! Group chat on, submit not working!!! Wow, the first thing that any user would do is try to submit something and it doesn't work! Go-live plan put on hold, investigation on,.. The last time I remember testing submit was one build back, ok, then bring back that build , test it on QA, it worked! The last build has this issue, so what was the reason, a simple suggestion for alignment changed the button position and the functionality stopped working! Would you believe it, yes, that was the issue, reverted back, and it worked again! All were happy, they all termed it as "Minor glitches" in production. But I just could not excuse myself for taking it so easy. My assumption of things would work the way it is supposed to, proved me wrong big time A lesson learnt .. Regression - Toughest part of any testing activity.

It is ok to log an invalid bug

Almost all testers would agree with me on one thing. It hurts when our bugs are marked as invalid or not reproducible or even a duplicate bug. Given the unpredictable nature of software it is quite natural that system behaves differently at times. What we see as an issue at one point of time, may not be seen at a later stage of product development cycle. That however shouldn't prevent a QA from logging that issue. You never know when that would resurface!! Having said that, there is difference between "Not a bug" and an "Invalid bug". " Not a bug " obviously means that it is not a bug at all and a feature of the software, Invalid bugs can either be not reproducible issues or when a functionality changes, the bug cease to exist or it could be anything else. Even the development team acknowledges it as a bug. A vast majority of the invalid bugs could be due to some simple missed things..

Few things that would help any tester avoid the ambiguous bugs are

• Check for the latest version of all files before you begin your testing.
• Check for DB, Server down time , that could lead to lot of not reproducible bugs.
• Check if the credentials that you use are valid.
• Check for all configurations.
• Check for browser, hardware compatibility of the software that you use.
• Check if you have all the prerequisites needed for the application that you intend to test.

When there is an issue, the first thing that any experienced QA would do is take a screenshot of it and then try to reproduce the issue. More important than finding a bug is actually describing it. Video screenshots would help a lot, given that it makes it easy for even the developers to just run the video and find out the issue. If that is not feasible, QA must make sure to describe each and every step that they actually followed. The development team should be able to reproduce the bug based on the steps given in the description. A good bug report can make the life easy for a QA and the developer. Even after all this if the bug is marked as invalid, then take it easy. Try to reproduce it and show them with proper steps. It is not a sin to log an invalid bug, and one does not have to feel sorry for it. Logging an invalid bug is also part of testing:)

Get set go..test!

When I started as a fresher, I honestly didn't know how to start on testing something!Luckily for me the first QA task was more checklist based. All I had to do was follow the checklist, and select the options Yes, No and then complete it. But when it came to regular software testing project, I was totally in a state of confusion. How do I begin my testing,where do I start and more importantly when do I start? Working with a development team as a lone tester, I had no choice but to figure out my own strategy.

This is how I began:

• Prepare a test strategy - Main purpose of testing was to log as much bugs as possible and not just to pass easy tests. Keeping this in mind, based on the requirements, prepared macro level test cases covering all functional scenarios and then prepared test cases at the micro level for individual functionality. In this way, I was able to cover the entire application. 
• Prepare a test plan - The main idea was to figure out the responsibilities, who does what? Since I was the lone tester, I took help of the development team for certain activities. This plan helped us estimate the time, the tasks for each person, the dependencies for each task etc. 
• Test cases- As mentioned in the Test strategy, as soon as the first set of requirements were available, I prepared the macro level test cases. Then based on the software progress, micro level test cases were also written. 
• Test Data- The test data was prepared along with the test cases. 
• Test Environment Set up - A separate QA server similar to the production environment was provided. 

What started as a plan for single QA member continued even when the team grew in size. This simple plan worked for me and my team big time! 

How important is finding an UI bug?

There is often a debate among the testing community, which bugs have more value , a UI bug or a functional one? Most of the QA folks have this opinion of functional bugs being more important than a UI bug.In general UI bugs are more important for consumer applications and functional bugs for the enterprise applications.A functional bug is considered more important because that is what is expected out of the system and if it fails there is no point in having a system. Not everyone is tech savvy nor everyone will check for the functionality when you ask them to use it for the first time. Let us for example consider someone using an e-commerce website. When users click on the link,they would first look at it for its aesthetic appeal. It doesn't really matter to them if the site's functionality works fine, the transaction works fine etc etc.,  The first few seconds to minutes  the site should be appealing for the end user like showing the latest collections, the current offers,a catalog of the products listed etc. If this part has any issues, then it is going to screw up the organisation big time. If clicking on any of these links, takes the user to some 404 error or 500 error, then the user would no longer remain in the site and would move to some other sites. The next important thing is how good is the usability of the website. When I say usability, it means that how easily can someone use the website to perform any transaction. The functional part comes after all these. Adding/Removing any item to a cart, proceeding to checkout, making payments etc come under the functional part. All these are expected to work fine as they are the basic features of the e-commerce website. Any website that makes a user to stay on it for a long time is sure to have a good user interface.  Even minor  UI bugs can make or break opinion on any product.It is therefore very important that UI bugs be given equal importance when testing any application. 

Lesson Learnt: Art of passing the buck

This is one of the good lessons that I learnt from one of the project managers that I worked with.
It was a completely different work that had just come to our team, and I was selected for it. I was in the training period. I had all sorts of audio, video sessions, conference calls, everything that a normal IT person would use for having a KT session. The real work started. Since I was new to the task, a person in US was supposed to monitor my work for initial one-two months. After one-two weeks, I gained confidence about the work being done, and my peer in US had the equal confidence in me, that he stopped monitoring me on a daily basis. I would complete the task and keep it, and he has to change the status each day. The work would be done by me in his name, and he just has to change the status in simple terms. In that way, we would be covering India-US time zones. The US peer was actually working at the client place, and we were the offshore team. Things were going fine , until one day this happened. I just got a call and had to leave home for some urgent reason and there was one pending task. I wanted to mail my US peer about the task and leave home. But since it is all about dollars, my PM suggested that I complete the task asap and leave. Without checking too much, I just completed the task and left home. As usual, my US peer changed the status once he came online. Next day morning there were lot of escalation mails waiting for me in my mail box. I did not know what to do and how to deal that. In came my PM and I told him about the escalation. There were no smart phones or personal laptops even for PM's that time.He had to come to office as well to check his mails. He immediately called me, asked me if I changed the status. When I said no, he just smiled and said, this is simple, you don't worry. Go, have some coffee and cheer up!, I was shocked that he took it so lightly, then after 5-10 minutes he sent a mail. The mail stated that the onus lies on the person who changed the status as the training period is still on, and that we are not responsible for what happened. A typical response from an offshore PM. The client couldn't argue much as there was nothing incorrect about the statement. My US peer was at loss of words and he took the blame upon himself. I somehow felt really bad as someone else had to take the blame for the mistake that I did. But then I realized, just like taking up responsibility for mistakes, one should also learn to pass the buck when required.  

Work Begins and initial lessons learnt!

1. After training for a couple of days in few Ad servers and the process, I was assigned the first task, QA of tickets. Just like ad trafficking, QA also requires good knowledge of ad servers. Impressions, Ad size, Ad targetting, Type of Ad, many more to know. It was a good experience that doing QA for each ticket was a challenge by itself. Getting an issue was not so easy, but there is always a chance of missing something, and unlike other software , you do not get a second chance to test it. Testing is only once and therefore it requires an eye for checking even the minutest detail. Different regions have different terms, for one region what looks like a jpeg ad would be a xml ad in another region. This was a simple point during training. But I learnt it the hard way during my first QA week. Since there was resource shortage, right from day one, there was no one to even check if my testing was proper. I still remember my first big flaw. It was 234x60 size ad , that was supposed to be a xml in APAC region, was displayed as a JPEG ad. Both trafficker and QA passed it and the ad ran as JPEG. First escalation mail, and still I remember the shiver that I had that day. The person who trained me was the one to handle it. He just smiled at me and said , that's ok, this is how you learn things. I still remember those words and his smile. It was he who gave me the confidence, and made me believe in myself. It was that day , that I realized being a QA is no ordinary job. Though a QA doesn't do things like ad trafficking or coding,he/she can greatly influence things and the buck stops with the QA!!