Loading ...
Sorry, an error occurred while loading the content.

TDD for new team

Expand Messages
  • dwandarti
    Hi, I have one question about TDD for new team. I know TDD is a great tool to have deliveries with high quality, but what should we do until everybody learns
    Message 1 of 8 , Jun 27, 2014
    • 0 Attachment

      Hi, I have one question about TDD for new team.


      I know TDD is a great tool to have deliveries with high quality, but what should we do until everybody learns it. In your experience, how long does it takes in average for someone produce unit tests with quality?



      I've got a new project with a new team, and none of them knows TDD. Basically, all of them have no experiences with any similar to unit testing. They are trying to learn it, for real, but so far unit testing they are doing is quite poor. 


      There are some points they test to much, other points they forget. To make it harder, contract demands a test coverage percentage and it's been quite hard for them to focus on quality, not just quantity.


      thanks, Daniel

    • George Dinwiddie
      Daniel, ... Doesn t that depend on whose judgement of quality? How do your team members feel about the quality of their unit tests? ... Hmmm... Are you sure
      Message 2 of 8 , Jun 28, 2014
      • 0 Attachment
        Daniel,

        On 6/27/14, 8:47 PM, dwandarti@... [SCRUMDEVELOPMENT] wrote:
        >
        >
        > Hi, I have one question about TDD for new team.
        >
        >
        > I know TDD is a great tool to have deliveries with high quality, but
        > what should we do until everybody learns it. In your experience, how
        > long does it takes in average for someone produce unit tests with quality?

        Doesn't that depend on whose judgement of quality? How do your team
        members feel about the quality of their unit tests?

        > I've got a new project with a new team, and none of them knows TDD.
        > Basically, all of them have no experiences with any similar to unit
        > testing. They are trying to learn it, for real, but so far unit testing
        > they are doing is quite poor.
        >
        >
        > There are some points they test to much, other points they forget.

        Hmmm... Are you sure they're doing TDD and not Test-After?

        > To
        > make it harder, contract demands a test coverage percentage and it's
        > been quite hard for them to focus on quality, not just quantity.

        Ugh, test coverage targets invite poor testing. But if they're really
        doing TDD, it shouldn't be a problem.

        Are you practicing TDD, yourself?

        The best, easiest, fastest way for people to learn TDD in my experience
        is for them to pair with someone who is already experienced in TDD.
        Another good technique is to have sessions with the whole team where you
        look at some code and tests and discuss it.

        It's not hard if people want to learn it. It is hard if people aren't
        really interested but are being pushed into it.

        - George

        --
        ----------------------------------------------------------------------
        * George Dinwiddie * http://blog.gdinwiddie.com
        Software Development http://www.idiacomputing.com
        Consultant and Coach http://www.agilemaryland.org
        ----------------------------------------------------------------------
      • Cass Dalton
        The way I describe it to my teams is that they should write all the tests that make them confident that a new change won t break existing functionality. If
        Message 3 of 8 , Jun 28, 2014
        • 0 Attachment

          The way I describe it to my teams is that they should write all the tests that make them confident that a new change won't break existing functionality. If they see tests as just a path to a required metric, it will always be about quantity (you get what you measure).  But if they see tests as a tool that will allow them to spend more time developing and less time debugging and firefighting, they will be motivated to write good tests.  When a bug slips through the tests, use it as a learning opportunity to get better at writing tests that prevent bugs from escaping.  As the team starts to develop a zero tolerance for bugs, you will get your test coverage as a natural byproduct of development.

          -Cass

          On Jun 28, 2014 12:30 PM, "George Dinwiddie lists@... [SCRUMDEVELOPMENT]" <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
           

          Daniel,

          On 6/27/14, 8:47 PM, dwandarti@... [SCRUMDEVELOPMENT] wrote:
          >
          >
          > Hi, I have one question about TDD for new team.
          >
          >
          > I know TDD is a great tool to have deliveries with high quality, but
          > what should we do until everybody learns it. In your experience, how
          > long does it takes in average for someone produce unit tests with quality?

          Doesn't that depend on whose judgement of quality? How do your team
          members feel about the quality of their unit tests?

          > I've got a new project with a new team, and none of them knows TDD.
          > Basically, all of them have no experiences with any similar to unit
          > testing. They are trying to learn it, for real, but so far unit testing
          > they are doing is quite poor.
          >
          >
          > There are some points they test to much, other points they forget.

          Hmmm... Are you sure they're doing TDD and not Test-After?

          > To
          > make it harder, contract demands a test coverage percentage and it's
          > been quite hard for them to focus on quality, not just quantity.

          Ugh, test coverage targets invite poor testing. But if they're really
          doing TDD, it shouldn't be a problem.

          Are you practicing TDD, yourself?

          The best, easiest, fastest way for people to learn TDD in my experience
          is for them to pair with someone who is already experienced in TDD.
          Another good technique is to have sessions with the whole team where you
          look at some code and tests and discuss it.

          It's not hard if people want to learn it. It is hard if people aren't
          really interested but are being pushed into it.

          - George

          --
          ----------------------------------------------------------
          * George Dinwiddie * http://blog.gdinwiddie.com
          Software Development http://www.idiacomputing.com
          Consultant and Coach http://www.agilemaryland.org
          ----------------------------------------------------------

        • Ron Jeffries
          Daniel, ... Your question gives me concern for the teamÆs understanding of TDD. TDD will give you excellent test coverage if you actually do it. (This is
          Message 4 of 8 , Jun 28, 2014
          • 0 Attachment
            Daniel,

            On Jun 27, 2014, at 8:47 PM, dwandarti@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:

            I know TDD is a great tool to have deliveries with high quality, but what should we do until everybody learns it. In your experience, how long does it takes in average for someone produce unit tests with quality?

            I've got a new project with a new team, and none of them knows TDD. Basically, all of them have no experiences with any similar to unit testing. They are trying to learn it, for real, but so far unit testing they are doing is quite poor. 

            There are some points they test to much, other points they forget. To make it harder, contract demands a test coverage percentage and it's been quite hard for them to focus on quality, not ju st quantity.

            Your question gives me concern for the team’s understanding of TDD. TDD will give you excellent test coverage if you actually do it. (This is pretty true for any good idea — it only works if you use it.)

            But TDD isn’t about unit tests. It is, however, about quality. TDD is an approach to building software that lets the design emerge as you go, and it results in highly modular and well-structured code — if you actually do it.

            For someone of even moderate skill, I believe you go faster with TDD, because the design stays clean and you make fewer mistakes.

            However, very few people seem to learn TDD by reading about it and thinking about it. Some do, certainly, but it’s not common in my experience. It’s possible that you’d progress better with some training or help, if you can find a way to do that.

            Ron Jeffries
            I try to Zen through it and keep my voice very mellow and low.
            Inside I am screaming and have a machine gun.
            Yin and Yang I figure.
              -- Tom Jeffries

          • Adam Sroka
            I think it probably varies tremendously but my experience has been that at about 6-18 months of deliberate practice most people will be practicing TDD
            Message 5 of 8 , Jun 28, 2014
            • 0 Attachment
              I think it probably varies tremendously but my experience has been that at about 6-18 months of deliberate practice most people will be practicing TDD competently. The way to tell is to pair them with someone experienced and see how often they need to be reminded to write a test, or not refactor in the red, or not violate one of the basic principles. By about 6-18 months it will rarely, if ever, happen. The conversation will generally be about higher level domain and design concepts by that point and the TDD rhythm will just flow. 

              However, that is just the beginning of the journey for most people. Doing TDD well means constantly evolving and changing the code. That pushes most people's design skills past the envelope and bridges many different topics in computer science. You need to know the language you are using pretty well, have a pretty solid understanding of OO and/or other design paradigms, understand a bit about automated software testing, and have a modicum of business sense to do TDD effectively the way it is done in XP. 

              Some coaching, or at least some training, is probably a good idea. Training helps clear up the vocabulary and create a basic framework for ongoing practice. Coaching gets more into the specifics of your day-to-day operations, but takes a while and may be costly. 


              On Fri, Jun 27, 2014 at 5:47 PM, dwandarti@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
               

              Hi, I have one question about TDD for new team.


              I know TDD is a great tool to have deliveries with high quality, but what should we do until everybody learns it. In your experience, how long does it takes in average for someone produce unit tests with quality?



              I've got a new project with a new team, and none of them knows TDD. Basically, all of them have no experiences with any similar to unit testing. They are trying to learn it, for real, but so far unit testing they are doing is quite poor. 


              There are some points they test to much, other points they forget. To make it harder, contract demands a test coverage percentage and it's been quite hard for them to focus on quality, not just quantity.


              thanks, Daniel


            • dwandarti
              For sure they are not doing TDD the right way, probably testing later. I didn t say test coverage is good or bad, just that it makes them loosing their focus.
              Message 6 of 8 , Jun 30, 2014
              • 0 Attachment
                For sure they are not doing TDD the right way, probably testing later. I didn't say test coverage is good or bad, just that it makes them loosing their focus.

                The point is that besides reading and training, they are slow adopters for this technique. Meanwhile, quality is suffering. 

                Thank you, Daniel



                ---In SCRUMDEVELOPMENT@yahoogroups.com, <cassdalton73@...> wrote :

                The way I describe it to my teams is that they should write all the tests that make them confident that a new change won't break existing functionality. If they see tests as just a path to a required metric, it will always be about quantity (you get what you measure).  But if they see tests as a tool that will allow them to spend more time developing and less time debugging and firefighting, they will be motivated to write good tests.  When a bug slips through the tests, use it as a learning opportunity to get better at writing tests that prevent bugs from escaping.  As the team starts to develop a zero tolerance for bugs, you will get your test coverage as a natural byproduct of development.

                -Cass

                On Jun 28, 2014 12:30 PM, "George Dinwiddie lists@... [SCRUMDEVELOPMENT]" <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
                 

                Daniel,

                On 6/27/14, 8:47 PM, dwandarti@... [SCRUMDEVELOPMENT] wrote:
                >
                >
                > Hi, I have one question about TDD for new team.
                >
                >
                > I know TDD is a great tool to have deliveries with high quality, but
                > what should we do until everybody learns it. In your experience, how
                > long does it takes in average for someone produce unit tests with quality?

                Doesn't that depend on whose judgement of quality? How do your team
                members feel about the quality of their unit tests?

                > I've got a new project with a new team, and none of them knows TDD.
                > Basically, all of them have no experiences with any similar to unit
                > testing. They are trying to learn it, for real, but so far unit testing
                > they are doing is quite poor.
                >
                >
                > There are some points they test to much, other points they forget.

                Hmmm... Are you sure they're doing TDD and not Test-After?

                > To
                > make it harder, contract demands a test coverage percentage and it's
                > been quite hard for them to focus on quality, not just quantity.

                Ugh, test coverage targets invite poor testing. But if they're really
                doing TDD, it shouldn't be a problem.

                Are you practicing TDD, yourself?

                The best, easiest, fastest way for people to learn TDD in my experience
                is for them to pair with someone who is already experienced in TDD.
                Another good technique is to have sessions with the whole team where you
                look at some code and tests and discuss it.

                It's not hard if people want to learn it. It is hard if people aren't
                really interested but are being pushed into it.

                - George

                --
                ----------------------------------------------------------
                * George Dinwiddie * http://blog.gdinwiddie.com
                Software Development http://www.idiacomputing.com
                Consultant and Coach http://www.agilemaryland.org
                ----------------------------------------------------------

              • Adam Sroka
                On Monday, June 30, 2014, dwandarti@yahoo.com.br [SCRUMDEVELOPMENT]
                Message 7 of 8 , Jun 30, 2014
                • 0 Attachment
                  On Monday, June 30, 2014, dwandarti@... [SCRUMDEVELOPMENT] <SCRUMDEVELOPMENT@yahoogroups.com> wrote:
                   

                  For sure they are not doing TDD the right way, probably testing later. I didn't say test coverage is good or bad, just that it makes them loosing their focus.



                  If you know they aren't doing it right then you know the problem you have to solve. Try to identify the root cause and an experiment you could do to look for improvement. 

                  For sure one of the main problems with coverage metrics is that they steal the focus away from proper testing. As I've said before on this and other lists they can be useful as a tool to sell testing to management, but that is the only way I use them.  

                   
                  The point is that besides reading and training, they are slow adopters for this technique. Meanwhile, quality is suffering. 


                  I would be careful. There are at least a couple assumptions there that you could test. Why do they appear to be slow? What difficulties can you directly attribute to quality? How would it look different if they were doing it better? What are some things you could try to move in that direction? Etc. 

                • Michael Jesse
                  Any time you start something new you will always have the velocity slower in the beginning than later on. To me, it s no different than taking a change from a
                  Message 8 of 8 , Jul 2, 2014
                  • 0 Attachment
                    Any time you start something new you will always have the velocity slower in the beginning than later on.  To me, it's no different than taking a change from a retrospective and mature it into something that is part of the day to day operations.  Training TDD is important and to get it right.  I've written unit tests since 2004, so 10 years and I've done all kinds of bad things at the beginning.

                    I thought testing the things that are working would be great since now I know it won't break.  Unfortunately, those are the parts of the code that NEVER change and therefore it wasn't important at all to test.

                    You then try and get to 100% code coverage, but then again you are testing for things that never change and are probably working.  Now, I'm perfectly aware of contracts by state, federal and international agencies that demand 100% code coverage, so you need to change how you write the code so it doesn't feel like you are fighting against testing it thoroughly.  More design patterns and follow SOLID principles.

                    Writing unit tests for legacy code that has strange dependencies are the worst.

                    A good book for the developers to read is Working Effectively with Legacy Code by Michael Feathers.  It has some good ideas about how to work with changes to existing code and how to apply test harnesses.

                    This will force your development team to refactor/change the code and then make sure that the existing functionality still works.  This can easily slow down a project, but then again, you probably shouldn't have written the code in that manner anyways.

                    So if it appears that your team is slow, ask several questions.

                    • Is it legacy code dependencies making it difficult to test?  Suggestion: Write new code with unit tests in mind and see if you can do a swap with a new file, code assembly, or even program.
                    • Is it not knowing WHAT needs to be tested?  Suggestion: Go back to your requirements and make sure you have User Acceptance Testing documented correctly.  There should not be an issue in describing how it should work between the PO, DEV and QA members.  Create Design Sessions if necessary to make sure everyone knows what is expected before ANY coding and changes are made.
                    • Production Support is you bogged down.  Suggestion: Various ideas for this one.  I've seen companies have a dedicated team that does nothing but fight fires while another team fixes them.  Fix the issues that are most critical first (e.g. the system goes down often, fails to restart after a reboot, performance slows down quickly and then stops)

                    In all, TDD is not something you gain experience in very quickly.  It's not like making a peanut butter sandwich for lunch.  It's more like creating a menu for an entire restaurant and making sure the delivery of each meal is perfect each time, every day.

                  Your message has been successfully submitted and would be delivered to recipients shortly.