TDD - the good, bad and ugly part
Being an Agile Coach & TDD Consultant, I have helped many product companies during their Agile transformation journey. I have observed many interesting good, bad and ugly practices followed in industry in the name of TDD. I would like to share my experience with the audience and guide them towards the correct direction and help them extract the true benefit of TDD.
To give a simple example, using code-coverage as a metrics to measure the effectiveness of the Unit Test Cases is one of the common mistakes committed by many companies.
In my presentation, I would like to demonstrate hands-on and discuss, how to effectively follow TDD and what to watch out and avoid bad practices in TDD.
Outline/structure of the Session
1. Hands-on Demo to demonstrate what isn't TDD.
2. Hands-on Demo to demonstrate what is TDD.
3. Hands-on Demo to demonstrate, how not to measure the effectiveness of TDD.
4. Discuss best practices and suggest how to measure the effectiveness of TDD.
5. Discuss common mistakes and how to avoid them
Participants will learn,
1. What is TDD?
2. Bad & Ugly part of TDD
3. Good Practices in TDD
Program Managers, Project Managers, Project Leads, QA Leads, QA Engineers, Product Owner, Scrum Masters & Developers
schedule Submitted 2 years ago
People who liked this proposal, also liked:
Yogesh More / Meenakshi Koul - Fish for Thought: Hook on to the Agile mindset!
While adopting the Agile methodology, one of the critical aspects of this change is the mindset change. As is said, Agile is more about the mindset than the process to be followed. If the mind adjusts the process then follows. As with other organizations adopting to Agile, and adapting to it, we too have been through this change management & transformation. The biggest transformation needed is the agile mindset or agility in thinking & acting, and our experience has been that it takes a while to adjust to it. It needs a mindset and a cultural change in an organization to completely embrace and realize the full potential of Agile.
How does one achieve the mindset adjustment or get this cultural change in our teams & make it a habit? How does the leadership bring about this transformation in themselves and their teams, especially the teams with prior experience working on waterfall or iterative systems. The challenge to adapt is at all levels viz. at individual, team, and at the leadership level too.
One of the popular culture change tool and now a philosophy and training is the “FISH PHILOSOHY-Catch the Energy and Release the Potential”. In our experiments on the cultural change, we see this addressing certain aspects of ushering in the agile culture or the mindset within the teams. This is an attempt to bridge this transformation with the techniques of the Fish philosophy. The energy seen due the FISH philosophy at the work place is used as navigate this transformation and bring about the culture of Agile in thinking, then doing would follow easily.
Vivek Ganesan - Developer 2.0 - Redefine the Role of Developer to achieve Success for AllVivek GanesanAgile/DevOps Change AgentSolutionsIQ
schedule 2 years agoSold Out!
Gone are the days where developer was responsible for just writing clean code. Traditional definition of developer affects the individual developers more than it affects the organization. The developer tends to concentrate on getting better at just the area of coding and ends up not learning the nuances of building a successful product. As a Developer 2.0, the developer performs all of the following roles.
2. Devil's advocate
3. Code Reviewer
A developer can work in multiple stories but cannot do more than one of the above tasks for the same story. For example, the same person cannot be both the coder and Devil's advocate. A team at Gainsight worked with this improved definition of developers and saw higher product velocity, better awareness about product and increased responsiveness to issues. This session will take the audience through the improved definition of the role of developer and present some thought-provoking questions to the audience to make them realize that the traditional definition of role of developer is just not enough.