You need to know what's on the cutting-edge of technology. Find out what's coming and the unique Warptest POV with just one click on the "Blog" tile.

All posts tagged Kata

Agile Actually Does Not Have Low Hanging Fruit…

Are you “doing” Agile? Scrum or Kanban? Doesn’t matter. Probably some of you aren’t actually implementing or running with Agile. Even if you believe you are.

Sorry to disappoint you but this boils down to realizing that Agile does in fact have no low hanging fruit.

Agile Low Hanging Fruit - Tree and Chicken

What Does That Even Mean?

Low hanging fruit, the easily reached, easily attainable target. Ever been up in a cherry picker? That sense as the hydraulics lift you into the air in that small metal basket. As the basket vibrates and you hold on and then … yep, you look down and realize just how fast you got that high up. Agile is like that. Implementing Scrum or Kanban the first time feels like that, especially for the matrix, CMMI and waterfall crowd. Where’s my safety net? Ironically, Agile is meta. The more iterations you do, the more confident you get.

Unless you fall prey to the illusion that certain activities within Agile are easy and you can cherry pick those and ignore the tough stuff. It becomes about performing ritual or kata for its own sake instead of a deeper understanding of why and how to do things, and do them right.

Kata is mindful and any martial artist will explain the benefits of understanding their purpose. Like many others, I’ve applied the kata concept to testing in the past.

Don’t do these. No really, don’t.

There is one more arguably, having tools that don’t integrate, communicate or display actionable information. Allowing technical debt to fester.

If any or all of these are happening with your Agile team then you fell into the illusory trap of low hanging fruit.

This slideshow requires JavaScript.

The Warptest POV

At this point you may be thinking all is lost or getting a bit annoyed. None of this is irreversible and the solution lies in the Principles behind the Agile Manifesto. If you have never read this and or don’t review it with your team, then this is the first change to make. Heck make this the default page in your team browsers, print it big for each work-space and read it aloud together.

See the photo above, I didn’t choose it just for the tree but also for the chicken below. I was sorry to see the chicken and pig analogy dropped (albeit for some evident reasons). The allegory has benefit but is loaded with negative connotation. Find another story that works for you.

Invest in your people. Train them and give them the knowledge and skills to succeed. We can’t just say to a team member, “Hey mate, you’re Scrum Master from now on.” They need to know what a Scrum Master does, how to do it and they will need guidance and help. A Certified Scrum Master course wouldn’t hurt either.

Make the changes that need making and do so fearlessly but not aggressively. Use honey, not vinegar.

Why is all this important? If you leave things as they are, stuck in some bastardized version of Agile then you are plotting your own failure. It won’t work and management will consider Agile a failure. This is a disservice to your efforts, your product and Agile itself.

The point of all this is to drive success. Some of the things you shouldn’t do are the end of a path taken that gives you short term, warm and fuzzy self-gratification instead of keeping your eye on strategic success.

This always makes me think of the scene in Arnold’s Conan the Barbarian where he and his companions are asked,

What is best in life?

Conan knows the answer and so should you. In the case of your team and product it’s adhering to a concrete definition of success. For me that is happy customers who come back for more of our product.

What’s your definition of success?

Testing Is Method Oriented…

When we interview new candidates we often ask them if the repetitive nature of retesting the same features would bother them.

Our aim in this repetition is to catch the errors, the bugs, the non-compliance to specification or expectation and report on it in a manner that allows the issue to be reproduced and resolved.

The mission statement I give to my testers, especially the new ones is, we are here to ensure the customer pays good money for a product that delivers satisfaction/ happiness and solves their problem.


Tell a non-martial artist about Kata (roughly translated as form) and you will probably end up demonstrating instead of explaining. Kata is intended as a means of focused, attentive walk through, a systematic approach to improving the execution of specific combat techniques either alone or in unison with fellow practitioners.

testing kata

As someone who has learnt Judo and Hapkido I can attest that performing Kata makes certain moves a reflexive response but also allows the person practicing the Kata to learn how the smallest change can deliver the largest improvement. I was lucky enough to study with a teacher who understood the bio-mechanics involved at this level and who saw the point of in-unison Kata in class as a time to observe and offer critique on each student’s Kata.


Most testing doesn’t offer the downtime for an exact allegory to Kata; having the team run through simulated test cycles is unrealistic. Observing and analyzing the nature and detail of Test Cases (STC) your testers create provides a Kata of sorts.

On a project in the last year I decided to run through the Test Cases and Coverage with the tester responsible for testing that module. Let’s call him Jim. Jim had been responsible for updating the Test Cases based on a major rewrite of the specifications. I asked Jim to walk me through the test cases and a pattern emerged.

I asked Jim how many times he had tested this particular module and he responded that this was the third time. While the focus of the testing was Business Logic Driven I saw no evidence of systematic testing of the UI. Knowing that a specific feature had just been changed to incorporate a search feature with results displayed in a grid UI element I asked Jim to show me the test cases involved in testing the new feature.

Jim walked me through the tests displaying extensive knowledge of the business logic and use cases behind the feature. Several questions occurred as I listened: –

UI Testing Kata STC

Was this a case where too much Kata was the cause? No, because Kata is not simply rote movement either in Martial Arts or Testing; it’s the progressive understanding of what lies behind the repetition and practice. I’ve referred to holistic testing in the context of Automated and Manual Testing but it equally applies to running through Test Cases while understanding that coverage can always be improved through self-observation.

I asked Jim to speak about how we arrived at this fix to his testing kata together at the next daily team meeting and he agreed to review this.

Testing - Brain Storm

After the team heard Jim’s review I suggested they consider if their testing kata had focused on one aspect whilst missing the fundamentals of another.

The Warptest POV

By providing a framework where the form and systematic approach to testing are monitored, evaluated and critiqued in a constructive manner you can ensure optimal test coverage.

Your testing team will be more prone to self-observation and attention to not just what they test but how they are doing it.

Instead of trying to abuse metrics to evaluate testing quality you are able to better improve on test cycles before they actually occur.

All this presumes that testing is not performed at an ad hoc level. It’s all about applying the right methodology to maturity of the App under test.

Are you ready to test?