This is about a week and a half late, but still useful - last week was too busy to really say much.
At our review of the evolution of our Agile process, it came up that we're suffering from not having the developers do unit testing. Now, this was a problem before - they were always "too busy" to add it in - but based on my experience with an Agile roll-out at my last company, unit testing was a vital part of the process. This, however, didn't come up in our training. In fact, little was said at all about test driven development and what it means.
Just like last time, it looks like people are misreading TDD. The developers in one team have decided that creating automation in Selenium - basically, automation that works on the UI - they will have satisfied the requirements of having development that is tested with automation. It's kind of hard to explain the logic here but my understanding TDD requires setting up unit tests - which are almost always below the layer of the UI - and creating these tests before you start coding (I'm not sure if you have to define them or actually script them beforehand as I haven't done t hem myself). UI tests usually can't be written until way after the supporting code is created, and Selenium, like most tools of this sort, is so fragile that just tiny changes to the UI will break its scripts, so the code can't really be written until after the coding is done. So what we get is not coding driven by well-written unit tests; we're getting coding and then a pass at creating super-fragile automation that tests the GUI after the real work has been done.
A second problem that came up is that we have a huge body of code written (using WebInject) that tests our current code base, and this is the code that is run when we do our automated regression passes. The developers are now supposed to be adding to our automation to include elements that test the new areas they develop; but somehow some of them have decided that they can use a different program for the automation than that which we have been using in a standardized fashion for a few years. While we might migrate to a new platform, we would have to convert all of our other tests in order for this to happen; and the thought of running two different automation platforms at the same time just seems rather silly. It was determined that to better handle this we needed to train the developers in how to use WebInject. While we may change platforms in the future, we need to make sure we're actually meeting our current automation needs until a choice is made to do the change.
Finally, there were some issues with where the QA piece fit into the user stories. For one of the QA team's Scrum group, they had decided to have the QA story be just one card that lasted for the whole sprint. We generally agreed that that was a bad plan, as it meant you could never tell when the QA was done, or if the QA was done for an individual item. Better choices were thought to be having a separate QA story for each development story, or using colored dots/magnets on a story to indicate when "QA script written/Coding Done/QA complete" had happened, or alternately to move a coded story into a whiteboard column to show that it was ready for QA.
Next up: cross-functional team communication and developing communities of practice.
Subscribe to:
Post Comments (Atom)
You're right; that's not TDD. TDD uses tools that are (generally) written in the same language as the code under test; for example, for PHP code, we use PHPUnit (or simpletest), for Java, it's jUnit. Tests need to be done at the object level (not the UI) and test the behaviour of components of the system (most commonly the classes within the application's Model, although it's possible, albeit tricky, to also test the Controllers in an MVC system).
ReplyDelete"True" TDD involves writing the tests before the code that runs them; this is a tricky concept, and usually you write a test a few seconds before the code that runs it; the test defines what the code must do. There's room for UT that's not TDD, and indeed it's useful, but it's retrofitting, not driving.
Equally, selenium may indeed be regression testing (I'm not hugely familiar with it) but it's not unit testing; AFAICT it's testing the whole ("does this car go?") rather than the unit ("Is the carburettor providing a mixture within tolerances?").
Also fitting the card to the sprint is indeed doing it backwards, but more on that later.
thanks for using WebInject. Glad it is helpful.
ReplyDelete-Corey