Agile Scrum with Test Driven Development (TDD)/BDD

I would like to share my new experience in Agile Development which follow the Test Driven Development model. Even after having longer experience in software testing always facing some new challenges when you adopt the new environment, new team and different approach of following development and testing life cycle. But new things always gives new challenges and new challenges always gives your opportunity to learn new things and make you more confident day by day.

First let me brief about Agile Methodology Scrum


In the Scrum team Product Owner, BA, QA, Dev will involved

Epic – Epic define as web application or software or tool or library to develop. For epic we create number of user stories in the product backlog.

Product backlog – prioritize user stories and push stories in Sprint Backlog and define the sprint.

Estimate Sprint – Sprint can be 1 week and maximum of 4 weeks. Estimate the story points. Story points represent the complexity ex. 1 story point for configuration changed, 2 story points for small code change, 3 for small code change, 5 story points for learning, implementation+ Unit Testing, 8 for investigation+ learning, implementation+ Unit Testing, 13 for initial setup for development and so on.

Deliverables – Once sprint is started, during the sprint do standup every day and get status from each development for developing stories. In the standup each developer will quickly share progress, any showstoppers or any dependency with other team members.

Production – In the development environment developer take copy of master development and start developing their assigned stories. At end of development review their code from other developer then marge the code with master code base. marge master code into test environment and start integration, regression and acceptance testing.

In the end once all testcases are successful then deploy delivers into production environment

So, in Production environment the software is not fully development but its working software with limited set of features so at every sprint we get working software with limited features.

End of sprint conduct retrospective What went well, wrong, what shouldn’t be continue or not so it always looks for suggestion for improvement

When the product back log is empty in that case you will get complete fully developed software


  • Transparency
  • Early Delivery
  • Easy Estimation
  • Product Backlog Refining/Refactoring
  • Features Prioritization
  • Quality improvement


  • Many Developer, One Master Codebase
  • Conflicts/Errors/Bugs
  • External and Internal Dependencies
  • Rework at various stages
  • Inability to design for future requirements
  • Partially ready to use product
  • Quality, Cost, Time and Scope

Approaches like TDD/BDD are used to understand the requirements clearly without any ambiguities and help to write tests in a way that makes code execution successful. These methods enable testers to think of solutions using a bottom up approach that helps prevention of defects in the later stages.This approach also helps clarify any ambiguities in the requirements early on in the software development lifecycle, before coding actually begins.With an increased level of understanding of the features and requirements, developers know what exactly needs to be coded, as also what needs to be included or excluded in the code, thereby preventing leakage of defects into the code in the later phases of development lifecycle.

However, it has been realized that implementation of TDD/BDD practices in the initially slowing down the software development process. but it helps in the maintenance of the code, increases the defect removal efficiency, and also reduces the time to market of the product. The TDD/BDD approach is also best suited for applications where the requirements undergo progressive elaboration. The frequently tested code has lesser defects and enables faster delivery of working software to the clients.

A seamless implementation of both approaches identifies defects early on in the SDLC process, reduce risks, and reduce cost of rework which is a significant cost in software development process. Requirement traceability is also enhanced when test cases are traced back to the requirements giving a picture of test coverage functionally.

Major Benefits

  • Reduce issues/surprises/incidents in the production
  • Help teams stay focused on Continuous Delivery
  • Help teams stay focused on Continuous Delivery

About samp79

Professional Automation Tester
This entry was posted in Agile. Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s