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.