How do I get started with TDD ?

When one of our team is trying Test Driven Development, we were looking at ways to get us started. Because TDD is totally opposite to how we are used to doing things, when looking for some inspiration, my manager gave me this http://nsbrief.com/40-graham-lee

This interview with Graham Lee goes on for 1 hour 20mins, but it not just pure TDD, it has also about Objective C,etc. So , i thought why not extract TDD specific part plus some of my input, so not everyone has to sit and listen for so long.

TDD – There is no code to test, why are you writing the test in the first place?

it helps to make sure you understand the problem you are trying to solve

it is a useful design tool. Your unit test will be a blue print for the class you are going to write

You will start to feel like you are coding backwards

It forces you to think about how you are going to use this class in the first place before you write a line of code, its a different process

How to get into TDD ?

Its really practice that helps you to understand

‘It was taught as a training course, it didn’t make any sense , why i was testing code’ – more of hands on instead of training helps you get up to speed.

Try to apply on few projects, first it will slow you down, it will be frustrating because you will be thinking in a different way than you used to.

After you written some classes in test driven way, it starts to become more natural

Best way to start TDD is with a bug fix, when you finish, you got your regression test in place as well

Writing unit test before code

Write notes on empty unit tests based on the requirement,  write like a To-Do list inside the unit test class and it really comes down to fill in the blanks – turning each to-do items to java statements

Always have them fail, never make them just pass by default or skip

Don’t give up until you finish all of the tests

Starts to think about problems,  how do you prove that you have solved this problem?, how do you write a test that demonstrate that you have completed this task?

You unit test could cover only 80% of you class and still pass, how do you prove that it covers 100% ? Creating the above to-do list will be helpful.

Why TDD instead of BDD ?

TDD – you only write code that you only need

You could still write test/automation to cover this scenarios that you are going to write, so why still we need TDD ?

programmers are naturally lazy, while we can write cases for thing we don’t actually need to cover, its becomes useless

you don’t have to restrict TDD to unit test, using cucumber you can make it appear as TDD

To some level they have the same kind of philosophy

Committing code ?

Should you commit all your passing test or wait until it becomes green

With CD, only option is to check-in unit test which passes, otherwise it will break the build.

In case of more than one person working on related code, and one dependent on another, he/she may have to unshelve others’ code to test his/her code.

thats all folks!

Open Vs Close cubicle and its impact on QA in Agile environment

Open vs Closed cubicles and its impact on QA in Agile

Open Space & Closed Cubicles and its impact on QA in Agile

This post discusses about the pros and cons of a team working in closed/semi-open

or an open environment. is this a QA problem ?, will come to know shortly.

Since I graduated, I worked in different companies and each had their own working style and environment. In one of them each office space is a cubicle, which is not fully closed.Just raise yourself up by 4 inch from your seat, you can see the whole floor and at least people’s head. Stand up and you can confirm if the person at the end of the floor is at his cube or not. Lets call this type of cubes as semi-open.

In another company in silicon valley, the office space is cubicle as well, but the cubicles are almost like rooms with a narrow opening and you can’t see your neighbours even if you stand up and jump. To make matters worse, each cubicle has a movable metal shelf and some people arrange their shelf in such a way that its difficult to see them even if you stand in front of their cube entrance!. Lets call this type as fully closed. Another one, fully open environment as in my current company, lets call this fully open.

In fully closed type, the problem is, face to face communicate is hard if not impossible. As Agile is becoming the defacto model being followed for software development, where not just the communication but minute by minute communication within team members plays an important role in making this a super fast successful development model. Advantage is privacy to employees, but I think it was just like that from the beginning of the start-up era and continue to be like that until someone realised that its killing productivity. In a model where you don’t have a Product Requirement Document and functional spec, the frequency of communication between team members is/will and should be very high. In this way, closed cubicles and agile combination is like a train labeled as “super fast”, with a steam engine trying to pull loads of modern coaches. Last time I heard, the company I worked for, is planning to dismantle its close cubicles and replace them with open environment, one building at a time.

Quite opposite is the open environment, where same project related team members sit next to each other. Everything can be communicated by literally ‘giving a shout’. Well, the disadvantage is, people can be disturbed all the time and spreading of contagious diseases like cold and fever are very high as well.

Whatever the environment is, whenever there is a limitation in communication, whenever there is a wait before a communication can take place, the biggest impact is beard upon by the QA team. Before discussing the how part, I would like to give a pre-amble so that the reader can empathize with us. Lets take an average team, with 2 QA engineers, 6 dev engineers , 1 scrum master and 1 product owner. If you draw a one-to-many mapping within the team members, and imagine traffic flowing across these lines in both direction, the amount of traffic flowing from QA engineers to the rest of the team will be the highest. Why is this ?

During the period of an iteration, a scrum master’s communication with the team will be about helping them out from any blocks, most of the time its passive and equally it happens via email as well. A product owner’s role is to define the acceptance criteria and clear any clarification on that if necessary, again that’s passive. A CM engineer does where is requested from the team. A passive communication is when, instead of the main subject, the opposite member initiate the talk.  A developer works on one story at a time, and at most, he or she might have to talk to the product owner for clarification of the acceptance criteria. Most of these communication happens as part of the daily stand-up.

But a QA engineer will be working on more than one story at a time, say for example 3 which happens in agile. He needs to talk to 3 developers every time he finds a defect or want to clarify the way a feature behaves. If there is a defect every half an hour, then there is an active communication involved every half an hour with the corresponding developer and the product owner, in most cases. Besides that, there might be build and environmental issues that involves back and forth communication with CM engineer. Every time something needs to be tested in stage, a communication with CM engineer is a must. For every story, any addition/deletion to acceptance criteria involves communication with the product owner. Sometimes, it is necessary to communicate with marketing department as well.

Imagine if we have to wait and there is a delay involved in every aspect of the above mentioned communication, then we might as well move back to water-fall model. The argument here is, which kind of  setup  equip the team with the best environment for faster communication. One can argue that chat clients and phone are alternative to faster communication. It might be true to some extent, but they have their own limitations. The person you want to talk might not be online or not there to accept your call and not all type of discussions can happen via chat or telephone. But the open type environment encourage face to face communication which could happen at any time. You are always seeing the team and in touch with the team.

I think, for Agile, the environment should be open type to fully utilise the agility this model provides.