Category: agile

Rinse and Repeat with TDD

Posted by Dhananjay Nene – November 25, 2009

I must confess having had a awed love relationship with TDD (Test Driven Development). This is the style where you first write the test cases and then write the code to make them pass. I’ve always felt awed by it. I have always firmly believed that it is the right way to offer sustainable quality. As someone who hasn’t been particularly awed by separate QA teams, I have always imagined TDD to be the silver bullet to offer controlled, sustained, high quality. Well, the silver bullet is a bit of an exaggeration, but sounded nice while I was on a roll :) . A number of times I wrote automated test cases post facto. But when the rubber met the road – I didn’t ever implement TDD.

Its probably a function of style. I like to write a piece of code and then keep on testing it against different scenarios and often keep on remoulding it substantially. My focus is at this stage on the code structure – the design aspects. Trying to do it with TDD always created a mess. The amount of intense refactoring I do always meant I soon got tired of also simultaneously refactoring the test cases and gave up on them soon.

Anyways, I finally think I found a formula that works – at least for me. I do not write production code in the first pass. I just write prototype code. I keep on playing with it, shaping it, challenging it, cajoling it, recasting it. Until I’m satisfied with the overall structure and internal design. Now when thats done, I rewrite it. Completely. Umm, I copy/paste maybe 40-50% of the code. But this time I write it on a completely new fresh set of files. And I write the test cases before I write the code. I find I can now really write tons of test cases and code quite rapidly. And with the tremendous satisfaction that at the end of the day, I now have the control harness to be able to keep on adding new features without having to continuously worry if I broke something else. With substantially detailed test cases, now I can actually feel quite confident that if I did break something – I’ll get to know it. Not next month, not next week, not even tomorrow – in the next few minutes.

So this approach seems to be working for me – the initial efforts have delivered great results and I’m quite satisfied. Now just wondering what to call it – for lack of a better term I shall term it “Rinse and Repeat with TDD”.

So if TDD works for you – great. You have one of the most important coding disciplines nailed down. But if you’re wanting to try to do TDD but haven’t been able to successfully implement it – you may just want to check out the Rinse and Repeat with TDD style. Who knows, you might find it useful too.

Agility and/or Process Maturity : How do I perceive these terms and why these should not be confused

Posted by Dhananjay Nene – March 23, 2009

Agility and Process Maturity are two very different terms to me. I have been rather pleased with the results I have found after having started working with agile methodologies more than 4 years ago. That makes me a candidate for being a biased blogger. But it still does allow me the ability to state my views clearly on the topic after that explicit disclaimer.

Process Maturity (especially CMM and ISO oriented maturity) focus on ensuring consistent, measured and self improving quality of output. This is achieved through multiple checks and balances, and detailed documentation of processes, and regular audits to identify points of weakness and their redressal. At least to the extent I have been exposed to them, people are looked at as cogs in the assembly line (replaceable and faceless) and focus is on ensuring that the assembly line works at a consistent pace even as people move around from job to job (or from assembly line to assembly line). Thus the focus is on setting expectations at modest levels and ensuring that these expectations can be met even as various events occur which introduce risk into the process, since the process methodology and documentation is geared to help address many of these risks.

Agility on the other hand probably stemmed from some of the concerns around the non-people-centricity and heavy-documentation-focus of these process maturity models. It instead ended up focusing on Individuals and their Interactions and on accepting the necessity of Change and thus adopting it wholeheartedly as an aspect that is inevitable and thus best accepted as a feature rather than a bug. Thus rather than slowing down the delivery, it attempts to substantially speed it up by removing many process steps which may seem to be impediments to progress. While substantially reducing most control and measurement points such as documentation, reviews, audits, they replaced them with steps which allowed quality to be maintained by introducing higher skills and discipline into the people (test driven development, pair programming, daily scrum).

Thus if a development team tells me they follow a process maturity model, assuming they are being completely honest in that statement, it tells me that as a customer I can expect them to set a pace and generally largely stick to it with incremental improvements while shielding me from having to deal with many of the internal risks they battle with.

If on the other hand a development team tells me they follow the agility model and again assuming they are being completely honest, it tells me they have a lot of respect in their own capabilities and to their ability to adaptively deal with internal risk through better earlier risk detection and redressal (Test Driven Development / Continuous Integration etc.) rather than through process oriented controls such as Documents / Audits / Reviews etc. I would also generally expect a much much higher productivity and quality from the team but with a higher statistical variance.

Ceteris Paribus, as a customer I would feel that the Agile Team is likely to introduce more schedule risks in situations of higher person turnover or lesser developer disciplines, while the team that focuses on Process Maturity is more likely to introduce schedule risks in situations of changes in requirements or in situations where a very quick time to market is called for.

What is obvious to me is that these methodologies have been defined with very different attitudes. If we play a “one word that comes to your mind” game with the terms, its “power” with “agility” and “control” with “process maturity”. Both are important and desirable and play a role, but the slider is positioned differently in each of the cases.

It has been rather obvious that agile processes have been occupying a greater mindshare over the past 5 years (the same thing happened with process maturity methodologies in the decade before that). I had been concerned that, as with many other trends in Software, the word Agile might also start getting abused where people start using it quite differently, to leverage on its momentum and the mindshare. It has been happening for a while, but the article Strategies for Scaling Agile Software Development The Agile Process Maturity Model just blew me off. I have only the greatest respect for Scott Ambler and especially for all his writings on Persistence. But in this article all the agile methodologies have been clubbed together as “Level 1 development” and many of the rather heavy weighted processes some of which probably led to the formation of the agile alliance in the first place are listed in the “Level 2 (disciplined) delivery”. I must clarify that agile software development covers all aspects of lifecycle including testing and measurement and agile software methodologies deliver as well (contrary to what the article “seems” to suggest) and rather than building discipline into processes, reviews and audits it builds discipline in the people that form a part of that process.

Since agility and process maturity are based on different attitudes I can’t see how one says I am going to put both the things together unless one intentionally and quite deliberately repositions the slider at a level with offers lesser power than agility and also dilutes process control compared to process maturity. But thats not the impression I got from the article. It seems to suggest that one can take these “level 1″ agile processes add “level 2″ disciplines to it and then add some uncertain “level 3″ elements to them to make things better than where they stand today, something that I am a little skeptical about.

So when a development team tells me they are following the “agile process maturity model (APMM)” I am likely to believe that they are either (a) too confused, (b) want to appear to leverage the agile momentum while using the strict control regime or (c) successfully figured out a way to move their slider somewhere in between with the risk that they lost some of the best elements of the two methodologies while attempting to lose the worst.

Having said that, it will be interesting to read Scott’s future articles on topic and to follow this trend. I have been proven wrong in the past, and it could happen again for me to have to eat my words. But moving that slider between power and control to attempt to achieve the best of both seems a little risky, and you can be sure I am unlikely to be an early adopter for the fear of getting severely burnt.

Update :I forgot to add that amongst the many items listed in Level 2, those such as (throwaway) sketching, whole team, test-driven development (TDD), continuous integration, daily standup meeting are accepted aspects of typical agile methodologies whereas those in the level 2 methodologies which agilists often avoid as actively managed and maintained charts are not even listed eg. in case of RUP – use case diagrams, class diagrams, sequence diagrams, state diagrams. So what is the contribution of other methodologies such as RUP in this case is largely unclear. I do not know the other Level 2 methodologies so can’t comment on the same.

Why merging development and testing makes sense in a TDD / agile environment

Posted by Dhananjay Nene – August 12, 2008

Interesting post in the Agile Journal, “Software Testing in an Agile Environment“. Great article and a reflection on how the software testing function would be influenced in an agile environment. IMHO, the author does a nice job, but perhaps could have gone a little bit further in terms of exploring how the development and testing functions could get merged within the same set of people, and this post attempts to do the same. Some comments I have are as follows.

But, for the QA professional an Agile approach causes discomfort – In the ideal world they would have a ‘finished’ product to verify against a finished specification. To be asked to validate a moving target against a changing backdrop is counterintuitive

This is no different than developers adapting themselves from a situation where they would’ve expected a set of clean requirements and/or design specifications. To be asked to develop a moving target against changing backdrop is counter-intuitive as well.

For some, the role of QA is now questionable citing Test Driven Development (TDD) as the key to testing. But, what is most important is that QA is directly involved in the agile scrums all the way through, to be an integral part of the team designing the tests, at the same time as the requirements and solutions evolve.

Absolutely.

1. “You only need to unit test – TDD testing is sufficient”

For the vast majority of commercial developments this simply isn’t true. Even strong proponents of agile development recognize the need for their armory to include a range of testing techniques.

Here the assumption is that TDD is in some way meant to constrain itself to unit testing. While most examples of TDD do show unit testing, I haven’t actually come across an opinion which says TDD is limited to unit testing. In fact this is one of the most important aspect to be understood if one needs to place QA in the right perspective in TDD environments.

TDD stands for test driven development. These tests could be white box or black box, unit or integration. Once it sinks in that TDD encompasses all forms of testing, it is easier to work out the workflow for the delivery teams. The most obvious implication is that the QA function needs to work very closely with development in deciding the tests of all types up front (prior to writing code). Given the agile proclivity for executable code and executable tests as the specification for code and unit tests, the same would apply to functional and acceptance tests as well. One issue here is usage of Record and Playback tools. I suspect these can no longer be used in a TDD environment simply because these assume the application under test is completely ready when writing the tests. (Record and Playback tools can be used as supporting tools additionally .. but they cannot meet the expectations of a Test Driven Development workflow). Coming back to executable tests whether these be coded in jUnit or HttpUnit or whatever one’s choice of tools, these can still be coded upfront and checked in before the code gets written to ensure that the code that eventually comes out meets the QA expectations.

Therein to me lies the biggest adaptations that testing functions shall need to adapt to. For most small to medium projects, in a TDD environment, the members (who perform both development and testing roles) write the tests and the code thus obviating the need of a separate testing department. Agile Environments will drive development and testing skills to be merged within the same set of people. While this increases the learning curve, it also substantially increases productivity since the entire communication stream between development team and testing team is largely eliminated, the occasional blame game between the two now just needs to get resolved within one persons mind.

However there are situations where I think classification of members into developers and testers might be called for eg. where a particular product needs to be tested on a v. wide range of hardware / software platforms independently, where writing the executable tests calls for a high level of capability and skill that is of a specialised nature etc. For such teams, their rhythm will now need to adapt. Instead of developers writing code and delivering it to testers, testers shall write tests and deliver these to developers who shall then need to write code to pass them. I believe this is the most important leap that the author of the article wasn’t able to make.

3. “Developers write the tests using open-source tools, so we no longer need testers, or automation tools”

Professional testers fulfill a different and equally valid role from their development colleagues.

Heres the tradeoff . Separating developers and testers has benefits of increased specialisation but levies high costs in terms of communication overheads, resolution of mismatched understandings, and crossing departmental boundaries in some cases. Merging the responsibility into one team member (development + testing) helps reduce all this costs even though the same person now needs to be trained in terms of having both the skillsets. Importantly, it clearly identifies where the buck stops (and eliminates the occasional ping pong between development and testing) resulting in developers verifying their own code with a much higher level of vigour resulting in a higher quality. I would submit there would be a large number of projects out there (but certainly not all) where merging these functions and removing the separation between developers and testers makes sense.

Often, TDD projects have at least as much test code as application code and, therefore, are themselves software applications. This test code needs to be maintained for the life of the target application.

All the more reason why development and testing responsibilities could get merged.

7. “Developers have adequate testing skills”

If testing was easy everybody would do it and we’d deliver perfect code every time. Sadly, many organizations that invest in increasing a developer’s coding skills and provide them with the latest integrated development toolsets, fail to see the need to develop the equivalent testing skills for their QA team, or provide them with the tools to do the job either effectively or efficiently.

Even better option – train team members to do both development and testing and equip them with the appropriate tools.

An independent testing team serves as an objective third-party, able to see “the big picture”, to validate the functionality and quality of the deliverable. While developers tend towards proving the system functions as required, a good tester will be detached enough to ask “what happens if…?” When you include business user testing as well, you are more likely to have a system that is fit for purpose.

Why would you want to have developers who cannot see the big picture. This is a training issue not a separation of function issue. Moreover I have always found it a bit strange that one can trust one person to write the code but not believe in him to be able to think through various combinations. I would argue that it is more cost effective to have the members simultaneously trained in “how to write code …” and “what happens if …” thinking.

10. “Developers and Testers – are like oil and water”

Since the dawn of time there has often been a “them and us” tension between developers and testers. This is usually a healthy symbiotic relationship which, when working correctly, provides a mutually beneficial relationship between the two groups resulting in a higher quality deliverable for the customer.

I would submit that this has been a high cost separation. Probably at least half (and perhaps many more) of the projects out there would benefit from these responsibilities getting merged in terms of increased productivity and quality. A small project should only have customers (or their representatives or proxies if not available directly) for specifying what is needed and conducting acceptance testing, and members (who have abilities to develop and test) who service these needs. Larger projects may choose to have a more classified team (domain experts, developers, tool builders, graphic designers, testers etc.), however such classification does and will make them lesser agile (as in the english word, not the methodology) to some extent.