Tuesday, 12 August 2014

Testing in troubled waters

System testers are like sleuths.

It thrills me when a tester talks about the curious incident of the test case in the night time (inspired by Sherlock Holmes' "The Silver Blaze") or the Second Crash ("The adventure of the Second Stain").

Good system testers have a keen nose for potential defects. It pays to create and sustain a team of such good testers in every project.

System testing in agile projects may better be based on the twin principles of preemption and collaboration. In most common flavors of Agile, system testing is also time boxed. The testers challenge is to provide the best guarantee of Quality in this time. In this premise, one can draw parallels between the requirements and motivation of Agile system testing and the emerging concept of Rapid Test.

Preemption and collaboration is achieved in many projects by an informal hand off from the development often referred to as the pre-test or early test increment. Testers may use this to get a feel about it. Testers may also give some feedback to developers informally. An effective practice for this from Rapid Test is called "Mention in passing".

It is suggested that a formal hand off point is also there in every sprint where the development transfers to test. Typically, you may reserve 10~30% of the time in each sprint for this formal test. Additionally, you can plan one in every three sprints or so as a Zero Feature sprint where the teams can pay off some technical debts. The system testers can catch up on automation and some exploratory testing in this time.

System Testing Defects should not be used as the measure of testing efficiency or development quality. It is better to use some shared incentives between the two teams because when you collaborate, you need share the pain and the gain. These shared incentives can be the number of customer defects (or the absence of it), timeliness of the software increments and possibly some measurement based on your value throughput.

Happy Testing! 

Monday, 4 August 2014

Tinkering and soccer mom management

I am greatly influenced by Nassim Taleb and his writing on Anti fragility. The skills of a software craftsman are like our muscles. Use them or lose them.

Tinkering is the practice of development in agile projects where the developers design and code a part of the problem (which the product is trying to solve), do some reflection (testing or staring at the code, whatever works for you) and consider some refactoring.

To begin tinkering, the developer may not need any further preparation than some collaborative workshop about the architecture and the top listed backlog items. The design will evolve as you develop.

It is suggested that each step while tinkering may give the developer an opportunity of deep learning. Compiling and dealing with the tricky and cryptic warnings, testing by exploring and the thrill of the first crash, building in target and so on. All of these can be the small mistakes that would build the resilience in our craft.

I suggest that we could also look out for the soccer mom patterns here. Soccer moms spoon feed their kids to win always. This may limit the kids ability to fail and learn when necessary. In projects also, any practice that tries to avoid all small mistakes may only facilitate bigger and costlier ones.

I think pairing in agile teams is like teaching to fish. The expert can touch base periodically, guide for the next step and then step back. It is OK for the learners to try and fail.

All agile team members should at least be empowered with the courage to fail.