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!!