/var/log/mind

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.

Google just launched “Knol” today (announced here on their blog). Back in january, I had written up a blog post - Will the knol be a knowall ?, so I was immediately curious to get a first hand experience. Here’s my fresh off the oven first impressions of Google Knol in no particular order.

• Current topics focused on healthcare : Most existing content seems to be focused on health care topics (at least the featured ones seem to).
• Anyone can author a knol : If you have a google id, you can start writing up a knol. The blurb suggests that knols are authoritative but there doesn’t seem to be any verification required for authoritativeness. If you can write a blog post or a wiki page - you can write your own knol.
• Multiple knols can refer to the same topic : While any person can author a knol, multiple authors can create different knols all referring to the same topic.
• Collaborative editing is supported (not the default): It is possible to create a knol and then invite additional authors / reviewers.
• Name Verification is supported : Google has provided for name verification for the author. However for now it seems to be enabled only for US residents.
• Nice user interface : The UI actually seems much nicer looking than most other google assets. It of course continues to offer nice usability like all google properties do.

I went ahead and wrote up my first knol Comparing and Contrasting Knols, Wikis and Blogs, just to get the feel of writing a knol. Here are my observations on a knol after writing one.

• If you can write a blog or a wiki you can write a knol. : It doesn’t take any more editing skill set to write a knol than it takes to write a blog post or a wiki. (Hardly surprising).
• The focus is similar to writing an article : When you are writing a knol, somehow one feels pushed to write a relatively comprehensive article. Its possible to write a knol of a few lines / one paragraph, but I just suspect we won’t see too many of them.
• Revisioning is supported : Revisioning is automatic and supported. Readers can actually go back and read your earlier revisions or even run a diff across them. (Hmmm .. can’t casually write something stupid and then just go back and update it with something lesser stupid).
• Separate field for adding references : There’s a separate field for adding references / citation. In Wikis / blogs - we just do it inline I guess. Kind of brings a more formal flavor to writing which requires these to be listed at the end.
• Its like a time independent blog, or strongly individualized wiki : If you are writing a blog, but seem to be essentially writing long articles which are of an enduring nature, maybe a knol might be a more useful platform. Similarly if a number of authors are collectively contributing many articles on your wiki but each maintaining a set of articles independently, again a knol might be a useful thing to look at.

Implications on corporate environments
Finally to come to my favourite topic of attempting to visualise how knols could get used in corporate intranets. I really couldn’t think of knols adding much more to corporate intranets than wikis could. The existing format for wikis and blogs is in my opinion quite adequate for internal and possibly collaborative publishing requirements of corporate intranets. However I suspect that knols actually might be a nice way to publish external facing content from subject matter experts. I think corporates could look at implementing knols on their external facing web sites which could contain content authored by their CXOs or domain experts. The focus on author and his capabilities is likely to be better suited to this environment and may allow the content to be projected with a sense of strength that a casual wiki or perhaps even a blog is unlikely to be able to project. But for that someone needs to start writing a knol engine first.

Just realised, have been blogging for more than 6 months now (actually I had started another blog ages ago .. but that tapered off soon then). Over this period, I believe I learnt or adopted a few practices. Just sharing them here. Feel free to comment. YMMV.

1. Treat your readers like a jury not as customers :By jury, I mean a jury as in a academic thesis not as in a court. Whats the difference ?
   • With customers you sell, with a jury you defend your perspective. You may think you are selling your views, but a jury doesn’t shell out any money to buy them. This makes a typical sales process a much more harder and onerous task than just defending. Most readers aren’t out to buy, they are out to learn more and interact more.
   • With customers you assume they may not know all about your product, so you focus on educating them in general towards making a pitch. With a jury you assume they already know far more than you do in general, but you attempt to educate them and draw them into a discussion into something specific that you have spent your time on, on something specific that you are presenting.
   • In a defense, the onus is on you to provide credible backing evidence. In a sales pitch the onus is on the customer to verify your pitch. Most readers would prefer to not carry the additional overhead of having to verify your statements. If you have provided the rationale for your statements clearly and supported it with available evidence if relevant, you have made the readers job much easier. You have increased the chances of the reader wanting to come back to your blog.
   
   
   
2. Make a strong statement. Avoid taking strong positions : Allow me to define this. By position I mean making absolutist statements without providing a sufficient context or a frame of reference or assuming ones own frame of reference as the only valid one. There is a wide diversity of readers out there. Some are into client side, some into server side. Some are into high usability, some into high speed processing. Some are doing graphics algorithms, some others are into CRUD and business validations. A large majority of your readers are likely to have a different frame of reference than yours. If they can’t understand where you are coming from, they will assume you are coming from the same context that they do. And they are likely to feel confused when what you say doesn’t end up matching their world view. A statement like “I found X more suitable than Y under a context Z” rather than a position like “X is better than Y” is more helpful since :
   • You get to describe your context. Your statement is a statement within a context. It is not treated as a blanket position. Readers with different contexts and divergent views can sometimes trace the differences to the context. Such readers can still suggest alternative views within other contexts easily without appearing to contradict you. Readers with similar contexts and divergent views can still choose to take you on.
   • You have lesser chances of being misinterpreted. You don’t want to get caught in an interview a year down the road when you are changing your job from writing a forms based application to one where you might be required to build say a graphics processing engine, where your interviewer might have just read your blog, and your posts actually do not make sense in the newer context.
   • When you make a strong statement without taking a strong position, readers record their agreement / disagreement with the post rather than you or your blog in general. I personally find that a much more comforting thought than readers choosing to agree / disagree with the blog in general.



3. Be prepared to update your blog soon :There is a large number of smart people out there, often a lot smarter than us, or having a difference experience set than us. As the comments start coming in, you start learning things you wish you knew before you wrote the post. If the comments indicate something useful and relevant to the post that you would’ve wanted to include in the post had you known about it earlier - go ahead, add it into the post. A convention I have seen is that all non trivial changes after the initial posting should be prefixed with the word “Update:” or “Updates:” so that readers can make out you’ve changed something after your initial post. A comment or two may be especially relevant. It helps to be able to review the comments regularly and update the post if relevant soon. If you are going to be traveling soon, either submit your post a little earlier or post it a little later - but post it when you know you will be able to review the comments and will have the flexibility to take 5 to 10 minutes off your regular work to update the blog if necessary.



4. Be prepared for surprises : Even if you write carefully you will end up making a small set of readers either happy or disappointed with you in a manner that will leave you puzzled. However hard you try there is a good likelihood someone is going to misquote you or take you on strongly in an unanticipated way. Some of this may be unavoidable and needs to be factored into your assumptions. However some of it will be avoidable, and do follow up such incidents to figure out if there are any learnings that you can apply the next time. A great way to do so is to write a mail back to the commenter or to the blogger who may have linked to your post and get a better understanding of his/her viewpoint.



5. Don’t title spam your readers : Every so often I come across a post with a provocative title, but which does not live up to the title at all. I prefer call this title spamming, since lot of the spam I receive has a provocative title, but often irrelevant content. Title is important. It influences readership strongly. But if you title spam regularly, it might help you get 2-3 posts higher readership, but its going to hurt in the longer run.



6. Understand how blog aggregators and networks work :It is important to understand the demographics of different blog aggregators. If you would like your blog to be read by larger number of people, be clear in your mind which demographics you are targeting when writing your post. Some aggregators like javablogs.com and artima.com will target specific programming languages and work off an RSS feed. Explore your blogging software and see if it offers category / tag based feeds. If it does use the categories / tags to ensure your rss feed registered with these aggregators sends only relevant posts to them. I use wordpress and it supports tag / category based RSS feeds. Networks like dzone.com, news.ycombinator.com, reddit.com, slashdot.org, digg.com have very different demographics. Don’t blanket post to all networks. Register your post with those networks where the readers are likely to find your post helpful. I have occasionally come across people wondering whether one should register one’s own posts to a network. My opinion is that it is an acceptable activity.



7. Ensure you have blog analytics enabled : Over a longer period of time you will start gleaning useful information about your readers. eg. what part of the world do they come from, which links do they come from (eg. you can get statistical information about the referrers such as google reader (RSS), blog aggregators, blog networks etc.). You can also get information about what searches led the search engines to your blog. I prefer wordpress.com stats plugin for wordpress and google analytics. The former is better at providing more immediate feedback, whereas the latter is more comprehensive.



8. Pay attention to search engines as well :Most blog aggregators and networks will drive substantial traffic to your blog for the first 24-48 hours. Search engines will send a small trickle initially. However there is a big difference. Traffic from aggregators and networks will dry up after a few days for any post. But traffic from search engines will keep on coming. Over a sustained period of time, search engines can start driving a substantial traffic to your blog. Read up about Search Engine Optimisation and see if you can help your blog. I would recommend however that you use such optimisation fairly and only to the extent that it is not misleading.

Yesterday this blog post was top of the charts in javablogs.com daily mail to me (Don’t bother clicking on the link since it seems to have been taken offline at least at the point in time I compose this post).

Quitting a job

I immediately got a little curious and looked up the same on google cache. - Quitting a job - from google cache

Here’s my quick learnings from the incident :

1. Group blogs probably need stronger access controls or code of conduct. Not sure (though I could attempt to speculate for myself) why it got taken off - it actually seemed quite innocuous.
2. Title Matters - I think the post was at the tops since the title evoked an emotive response.
3. Emotive issues override focused topics. Javablogs.com readers are supposed to be interested in reading posts on java - right ? Well this post beat the following popular posts by a handsome margin some of which would seem to be rather much more relevant to an audience primarily focused on java blog posts.
   • Which one do you prefer; Liferay or JBoss Portal?
   • Wow: a Java application with 25 megabytes of JAR files
   • Thanks Zed, Java evolution, Ruby and Scala Pimple Pimping
   • Death to Ant
   • James Gosling and MySQL’s Monty Widenius, David Axmark, and Brian Aker on Sun’s MySQL Acquisition