Test driven Development (TDD)

In age of agile framework TDD is very important because what we are going to implement is more valuable than how we are going to implement. It doesn’t mean that I am advocating of missing the how, it is really important but when we start to work on any feature/component/part/product we must know In and out of that, and to ensure that I advise to go with TDD.

TDD is a grouping of TFD (Test First development) and Re-factoring, so we can depict it as below:

      Test à Code à Re-factor

 

Now it’s easy to understand that in agile framework development team (in agile known as feature team) job is to first write the tests before writing the code. So before implementation all tests should fail and after implementation tests should pass, and even if tests fails, code should be re-factored and tests again to ensure it passes. They should add more tests after re-factoring to make sure that it won’t miss any functional testing.

To go with TDD, feature team and any management involved should have the mindset accordingly as quality of development is the key agenda of this philosophy and need focused team who should understand well the requirements.

Let me elaborate that how to approach of writing tests before code modules exists.

In agile framework, feature team members chooses the feature to implement and feature team is getting involved to understand the requirement as well, so they know that what feature they are going to implement. They should start writing Unit tests considering that what input would be for your feature and what output feature will produce. You can write all the possible tests considering the feature module as a black-box (abstract). Since module is not implemented all tests should fail, and now start writing the feature implementation code, and again run all the tests and all should pass, re-factor the code if required and again test and so on.

JUnit can be used for Java based development, Selenium can be used for java based web development, DBUnit can be used for DB development, Fitnesse can be use for User acceptance testing etc. You can use mocking for unit testing as per your requirement.

Benefit:

      The aim behind TDD is to motivate feature team (development team) to understand the requirement well before writing any code which ensures fast development and minimal bug. Another aim is that it is always easy to trace any error or bug in initial stage as number of lines of code is less and can be re-factored that time itself.

Find below blogs written for me for writing TDD:

http://javawitharun.blogspot.hk/2014/05/fitnesse-with-java-user-acceptance.html

      http://javawitharun.blogspot.hk/2014/05/selenium-web-automation-testing.html

http://javawitharun.blogspot.hk/2014/03/mocking-with-java-easymock.html

http://javawitharun.blogspot.hk/2013/04/junit-how-to-create-runtime-junit-test.html

Scrum of Scrum (when multiple teams are there)

To co-ordinate with different teams there is an activity called ‘scrum of scrum’, this is a meeting in which one or two member of each team do scrum meeting (same as daily scrum). This may occur on daily or thrice per a week.

This is to focus on below items:

o   What team has done?

o   What is the plan for today?

o   Any hurdles/dependencies and how to overcome that?

Even there are multiple teams but there must be one product backlog and one product owner. There may be scrum master per each team but there must be one main scrum master.

There must be one Sprint backlog per each team. There must be single Sprint review meeting, and single Sprint retrospective meeting for all.

User Stories (In Scrum Methodology)

User stories are short and precise description of a new feature or bug which is either part of Sprint backlog or product backlog. User stories are generally getting written on sticky notes and arranged on boards/walls to use during daily scrum meeting and these sticky cards are getting moved from one state to another state for e.g. coding to testing.

Sprint Retrospective (In Scrum Methodology)

As we all agreed that there is always a scope for betterment no matter how good our approach and execution, same applied with implementation of scrum-process. So Sprint retrospective meeting is to understand the issues with processes and what are the processes changes are required to make better product?

In Sprint retrospective meeting, participants are feature team, Scrum master and product-owner.

This is the last item of a sprint. There are 3 things each team member must talk about:

o   What team should start?

o   What team should stop?

o   What team should continue?

So it’s all about to reform the processes to make better product.

Team should do brainstorming if required. At the end of meeting team should agree that what are the changes they are going to adopt in next sprint.

Sprint Review (In Scrum Methodology)

After completion of each sprint the whole team should conduct a sprint review meeting. This is to demo the features implemented by feature team, so the features must be coded, tested and functional.

The meeting preparation should not take much time, no need of power-point presentation materials or any fancy tools to demonstrate. It should be the natural outcome of sprint and must be represented the same.

Sprint review meetings must be open for all including Product-owner, Scrum-master, Feature team, customer or any body wants to learn about the product.

If any defect identified, its product-owner’s responsibility to add that defect in product backlog and prioritize it.