Interim build to testing team worked for us

Intent of my blog

This blog is about my personal experience of giving interim build to QA team. So far now it has worked great for us.

Content

Few months back my team decided that we will be following some agile practices. So we decided to list down the practices that we will follow.We tried tdd but it failed. The only practice from that list which we have successfully followed is giving interim build to testing team during an iteration.
We follow 1 month iteration of which 3 weeks is for development and 1 week for testing. Till few months we give build to QA team only when we have done all development which means 3 weeks they were not doing any testing but were creating test scenarios and understanding user stories.As we were not following tdd ,during the testing lot of bugs were raised which were programmatic error like NullPointerException or sometimes the understanding of user story was different which leads to QA week to be  a very tiring week(fixing lot of defects).Also this also leads to lot of tension and pressure on the team.

Interim Build became the SilverBullet

From the last few iterations we have started giving interim build to QA usually one or two between the development cycle.This has helped our team a lot:-

  1. Programmatic errors are resolved during the development cycle so cost of fixing the defect is quite low.
  2. Testing Team is doing testing during the development cycle.It helps testing team in understanding the application better rather than just reading documentation.
  3. Quality of defects raised by QA team during the QA week increased because they were able to do more functional testing rather than finding NullPointerException or validation issues.
  4. Pressure on developers and QA team reduced during the QA cycle.
  5. High Quality of Application

These are some of the benifits which we got by giving interim builds to QA team.

Please share your thoughts also.

Advertisements

Why my attempt to apply tdd failed?

Intent of my Blog

The intent of this blog is to write down the reasons for my failure to apply test driven development in my current project. Uncle Bob Martin in his interview on infoq said that “Developer is not professional if he does not practice test driven development”. We tried following tdd but failed (are we not professionals 😦 )!!

Brief Background

We had a major release few months back and till that time we were not following Test Driven Development so when the talks for the subsequent releases started we thought that we should follow tdd.I was given the responsibility to come up with strategy on how we will be applying tdd in our project. So i started with reading kent beck book Test Driven Development: By Example. I also read lots of articles  on infoq and testdriven.com to get a good and thorough understanding of tdd and was convinced that we should apply “TDD”.I gave a presentation-cum-coding demo to my team and after my demo we all were convinced that we will be applying TDD.

Ist Iteration using TDD :-Whenever you start some new thing you are excited, the same was the case with us.So before writing any class or any piece of code we used to write a test for the same. We were developing our code in an incremental manner, letting the design evolve as tdd gurus says and we were seeing small benefits like fixing programming errors like NullPointerException were caught in the early stages before the code goes to the QA team for testing.
For the next two weeks i was on leave and when i came Iteration 2 had started and tdd was no where…. So what went wrong………………

I asked my team why now we are not using tdd and the answer was that client changed the contract of one the web service that we published in iteration 1 although we had taken the feedback from him on the previous contract but somehow later he felt that this was not correct and we have to re-implement the web service with new contract and because of pressure of time we commented out all the tests and wrote the code without tests.

I started thinking about our failure to apply tdd because i think time pressure is not the only reason why teams fail to apply tdd there are many reasons. So i am writing down some reasons(in no particular order) which i think led to us not apply tdd:-

  1. Time:- Developers think that writing test cases before writing code requires more time and most often under pressure circumstances time is more important than writing test cases.
  2. Boring to write test cases first:– Its very difficult to get into the habit of writing test first than code so developers are reluctant to write test first.
  3. Client Support:- When we told our client that we will be applying tdd in our code, the response was that tdd doesn’t provide better results and in a longer run developers don’t maintain the test and they become irrelevant after some iteration.Client cares about money not test cases.
  4. Writing Exhaustive test cases :- I think tdd will make sense when you are able to cover most of the scenarios in your test class. More often what happens is that developers just write the basic test and test class doesnt evolve to incorporate all the test cases as a result developer thinks that when the number of bugs getting raised is not decreasing why should i write test.
  5. Patience :- I think it is very important that we should not expect everything to go fine and everyone to become tdd guru in one iteration. So we should give tdd few iterations before we can judge whether its useful or not.
  6. Poor Examples :- The example with which tdd is often taught are very simple as compared to the one you face in real life scenarios.So it becomes difficult to follow tdd when there is some real complex problem come.
  7. Legacy Code

In short, i can say that applying tdd requires a complete change in mindset you have start fresh.These are some of the reasons that i could think of at this point of time why applying tdd failed.
Please share your views also.