When something works, share it!

November 12, 2013January 2, 2015 Augusto Evangelisti Agile Software development, Agile Team, Agile Testing, BDD, Lean Software Development, Software Development, Test Automation, Testing ATDD, BDD, collaboration, communication, spec by example

When I joined PaddyPower in October 2012 I was asked to improve quality without affecting throughput. I studied the teams for a couple of months and I came up with this model based on Gojko Adzic’s Specification By Example and a white paper on ATDD from Elisabeth Hendrickson.

One year after, the bugs are a distant memory and cycle time has been almost halved, so I thought sharing the approach might be useful to somebody out there.

Here we go!

Acceptance Test Driven Development

Acceptance Test Driven Development is about people, communication, collaboration and delivering business value.

ATDD is a software development methodology based on enhanced communication among its actors.

ATDD uses high communications processes and tools to help developers write tests in a business language understandable by all actors. Such tests help developers focus on what to code. The tests can be automated and represent the blueprint of the application being developed. The tests live with the code never getting out of date. Any deviation between tests and application is communicated to the team in the form of a failing test. ATDD sits very well with many agile software development approaches including Scrum and Kanban and with XP engineering practices.

The Actors

Activities Artifacts and Goal

Acceptance Test Driven Development can be described using 4 activities (Discuss, Distill, Develop, Demo) 4 artifacts (User Story, Examples, Tests, Working Software) and 1 goal (Business Value). Each activity takes as input an existing artifact and produces as output an evolved version of such artifact until the goal is reached as explained in the Business Value Evolution train picture below:

The starting artifact is a User story, during the Discuss activity such artifact is transformed in Examples, in the Distill activity we transform the Examples into Tests, Tests are transformed in to Working Software during the Develop activity and Working software demonstrates Business Value at the Demo activity.

For this process to be successful it is fundamental that none of the activities is performed in isolation (by a single actor) . As many actors as possible should participate to any of the activities, specific actors’ requirement for specific activities are described later in this document.

One Source Of Truth

The first 3 artifacts describe requirements, the fourth is the representation in software of such requirements and the last is the final business goal. The Tests will represent the one point of truth about what it is turned into software and business value. Once the Demo is completed the User story and the Examples can be disposed and the only source of truth will be in the Tests. This is due to the fact that in the transformation the team will have learned a lot more about the deliverable than what it is described in the user story or the Examples. The tests will be updated during all activities to quickly adapt to changes and new discoveries, it is not necessary to retrofit such changes into User Stories or Examples. Tests stay forever and describe the application.

It is imperative that the Tests are at all time visible to all the actors. This means for example that having them buried into source control is not an option because business people don’t use source control.

Actors on the Train

The picture below expands on the Business Value Evolution Train by showing which Actors participate in which activities.

Discuss

Required Artifact: User Story – We need a business requirement to start from. This doesn’t necessarily need to be in the format of a user story, and it can be expressed in any format. What is needed is a business value to be delivered.

Required Actors: At least 3 members of the Development team should participate, ideally a mix of testers developers and business analysts. Either one between Product Owner or Business Analyst need to participate to this activity.

Format: Meeting with access to a whiteboard

How it works: The Business Analyst has previously developed the user story through his conversations with the Product Owner, he will be able to explain to the other actors the user story’s business value. He will also be able to explain the conditions of satisfaction. Shared understanding of goals will guarantee the real goal is attained and not a consequence of somebody’s assumption

The conditions of satisfactions will be translated into examples, for example if the user story is about giving free delivery for customers that buy 5 books or more the initial examples might be:

5 books free delivery
4 books paid delivery

Questions will be asked and other examples might come out, for example

5 books outside Ireland paid delivery (if the product owner decides to give free delivery only for home users)
4 books and 2 CDs paid delivery
5 books and 1 washing machine free book delivery and paid w/m delivery

and so on…

By the end of the meeting the examples very likely will describe more scenarios than we thought when reading the user story for the first time and by trying to create concrete examples, few questions over the applicability of rules will be raised. If all questions have not been answered and the help of the Product Owner is required, the Business Analyst will get the answers from the Product Owner and have a quick catch up with the other actors to define the last examples. Having the product owner at the Discuss activity can make it more effective as most of the questions will be answered during the activity.

If the questions have unlocked some large uncovered areas and cannot be addressed by the Product Owner, more analysis will be required before we can proceed with the next activity.

Outcome1: Examples – Notice as the examples cover all the aspects of the user story plus those aspects that were not covered in the user story. If we add a 2 liner with the business value to the examples we have an improved version of the user story. The original user story is now out of date and can be expended.

Outcome2: The team have a common understanding of the business value of the user story

Outcome3: The discuss activity might highlight that the user story is too big to be delivered, in this case the activity will produce a list of user stories and the examples for the first one that is taken into development.

Distill

Required Artifact: Examples

Required Actors: Two members of the development team need to participate. At least one Developer needs to participate, ideally the developer that will be designing the code for this item. The second member should possibly be a tester or a Business Analyst, if they are not available, a second developer would do.

Format: Pair programming

How it works: Now that we have the examples written down, we can transform them into tests in a format that works with our test automation framework. There are a variety of test automation frameworks that support defining the tests in advance of the implementation including Jbehave and Cucumber. Tests will be written using the Given When Then format. Tests will cover all the examples that were identified as result of the Discuss activity. Extra tests could be added based on the improved understanding of the business goal.

Outcome1: Tests – The Tests cover all the aspects of the examples plus those aspects that were not covered in examples that were uncovered while writing the tests. The tests will also contain the 2 liner with the business value contained in the examples. Again we have an improved version of the examples.

Outcome2: The tests will be written in English so that every actor is able to understand and give feedback. The examples are now out of date and can be expended. The Tests represent the blueprint (documentation) for what we will eventually deliver. The tests will be highly visible and easily accessible at any time.

Develop

Required Artifact: Tests

Required Actors: Two Developers need to participate.

Format: Pair programming or Single developer writing code + Code Review

How it works: When implementing the code, the developers are following a test-first approach, they execute the tests and watch them fail. They will write the minimum amount of code required to get the acceptance tests Green. Once the acceptance tests are green he will manually verify that everything hangs together and will call another Developer or a Tester to perform Exploratory Testing. Once exploratory testing is completed and any defects fixed the user story is done and working software is ready to be delivered. While coding the developer might identify scenarios that were not identified earlier and add tests for them. Such tests need to be added to the previous set and shared with the rest of the actors. If the new scenarios identified represent a large amount of work a decision might be made that pushes the new uncovered scenarios to a subsequent user story or we could decide to deliver them.

Outcome: Working software + more comprehensive tests

Demo

Required Artifact: Working Software

Required Actors: The Product Owner and 2 members of the development team. Possibly the developer that wrote the software and the other actor that performed the exploratory testing.

Format: Meeting with large monitor

How it works: Before organising a Demo the development team needs to be sure the user story adheres to the definition of done. One very good practice is to create a demo script in which the demo facilitator writes down the steps to follow in order to demonstrate the user story business value to the product owner.
The demo should be an occasion for the development team to be proud of what was delivered.

The product owner will be able to use the Tests to validate all the required functionality has been delivered. At the end of a successful Demo, the product owner will accept the original User Story through the business value demonstrated by running the tests.

Outcome1: Business value

Benefits:

1) Shared understanding
2) Front load issue resolution => reducing defects detected at exploratory testing
3) Tests, for their nature, are specific and unambiguous. Using tests as requirements, developers will create their code based on specific and unambiguous requirements.
4) Developers can avail of the specificity of the requirements and avoid over-engineering
5) The tests are not written in a technical language and can be reviewed/discussed/improved by anybody with some business domain knowledge. Everybody can participate in designing the application by collaborating in defining the tests.
6) The tests are the one source of truth for the application’s behaviours. The acceptance tests live with the code and are executed in CI, they will always be up to date unless the application diverges. The tests are the application documentation. With new functionality come new tests or old tests get adapted to fit the new behaviours.
7) Increased communication builds trust and alliances between the actors
8) Increases transparency; the tests content and results are shared, easily accessible and have high visibility among all actors.

Pleasant Side Effects:

1) Acceptance tests are automated and as such they grow into a comprehensive regression suite
2) Can help Impact analysis. If we want to assess the impact of a change on our application we can simulate that change and verify what pre-existing behaviours it affects by reading the acceptance test results.
3) In the not so uncommon scenario of a re-write, if the original application was written using ATDD it is now possible to recreate the old functionality that needs to be transferred by reusing the Acceptance Tests

Acceptance Tests add no value and can be counter productive when…

1) When we write Acceptance Tests for anything but new deliverables
2) When we write Acceptance Tests to create a regression suite of an existing application
3) When we confuse Acceptance Tests with the tool for writing Acceptance Tests
4) When we write Acceptance Tests that do not give fast feedback
5) When we write Acceptance Tests that are brittle and difficult to maintain
6) When we write Acceptance Tests that contain variables and parameters
7) When we write Acceptance Tests that contain unnecessary detail
8) When we write Acceptance Tests that do not focus on what the change is but on how to exercise such change
9) When we write Acceptance Tests that test the application using the UI when the change is not in the UI
10) When we write Acceptance Tests in isolation and we hide them in source control
11) When we write Acceptance Tests as workflows/scripts

Finally, if you want to learn how to write better acceptance tests have a look at https://mysoftwarequality.wordpress.com/2012/12/14/how-to-transform-bad-acceptance-tests-into-awesome-ones/

The real value of BDD

November 9, 2013 Augusto Evangelisti Agile Software development, BDD, Software Development ATDD, BDD, collaboration, communication, spec by example, value

I have been working with agile teams for a few years now and I have used a flavour or another of BDD almost since the very start of my journey. Like everybody I used it badly at the start, misunderstood it and made a mess of it for a good while. Unlike others I have no problems admitting it. Mistake after mistake, fuck up after fuck up I learned a lot of things and today I believe I have developed a decent approach that I will try to improve. Through these years of many failures and small successes one thing clearly emerged for me and it is I believe the true value of BDD.

To me BDD is about communication, collaboration and delivering business value.

The most important part of it? The discussions you have with your team just before you write the tests.

The inherited automation, the derived documentation, the shared knowledge, the reduction in gold plating are side effects and it’s nice to have them, but the real value is in the conversations. The conversations where the team explores new grounds, the conversation where if you want to add value, it doesn’t matter how senior or technical or business savvy you are, what it counts is how much you care about your customer.

Signoff by High Five

November 6, 2013November 9, 2013 Augusto Evangelisti Agile Software development, Agile Team, Random Thoughts, Software Development asscovering, cover your ass, CYA, signoff, useless, zero

I hate the word SIGNOFF.

I thought that once I got away from the horrors of waterfall software development it would disappear forever. But no, the menacing SIGNOFF has made it into agile software development teams. I was at Agile Testing Days in Berlin last week and I had an incredible time talking and listening to passionate people. On the other hand, I was surprised to hear how many people still talk in term of SIGNOFFS.

Overheard in Berlin:

“The user stories need to be signed off before you can start working on them”

“…then after our signoff we can deliver the software…”

And so on

This is my definition of a signoff:

“A point in time where my responsibility ends, so for errors up to then you can blame me, after that it’s your fault and I don’t give a rats arse.”

That’s what it is, it is a Cover Your Ass activity. There is no other reason why you would want to signoff on something unless you are trying to cover your own ass and blame somebody else. The fans of the Cover Your Ass manifesto are also the ones that would sing off on anything.

What’s the value of a signoff to our customers?

Signoff by High Five at the Dublin Java User Group

0 – Zero – Nil

What’s the value to the development team?

Less than zero because signoffs cause finger pointing and blame games

So, why the hell do we do signoffs?

I don’t know.

One thing I know is that the agile manifesto (among other things) says:

Customer collaboration over Contract Negotiation

That in my head translates into

Shared activities over Signoffs

In my team we have started a new trend, it’s called “Signoff by High Five”, it works like this: You get 3 people (possibly the 3 amigos) and you get them working on a task, for example writing a user story. They work together and when

they are finished they go: are we happy? Yes! “High Five!”

At this point you don’t need to have a document with a checklist and a signature of somebody to blame, you simply need 3 people agreeing and one simple “High Five”.

We also do this when we do exploratory testing together, at a certain point we look at each other and we know there is nothing more that we can do to add value then it’s “High Five!”

Sometimes we do that at the end of a demo, the high five there means the story is accepted.

So what happens if there is a problem and a bug appears on software we had wrongly high fived? Not much, we just worry about repairing the issue as soon as possible and delivering the missing value to our customer, no need for arguing over who fucked it up and how we can punish him. What we do is deliver value, that’s what we care about.

How Ignorant am I?

November 2, 2013 Augusto Evangelisti Random Thoughts, Software Development ignorance

Students know that they don't know — Students know that they don’t know

When I know that I don’t know something, it’s a really easy situation, I can study and research to remove the ignorance factor and eventually I will know that thing I didn’t know. This is called first order ignorance, I know what I don’t know.

Homer doesn't know what he doesn't know — Homer doesn’t know what he doesn’t know

The second order of ignorance is a bit more tricky, in fact it can be described with “I don’t know what I don’t know”. For example you are estimating a piece of work and what can happen is that your estimates cannot cater for what you don’t know that you don’t know. Being a bit moire specific, say you are estimating writing a new feature that allows your customers to buy tickets for the cinema. You probably know that you need customers, you need a movie, you need a movie theater and a date. What you might not know is that for instance some of the movie theaters are roofless and attendance might depend on whether the sky is full of stars or there is a full blown storm over the screen. Not knowing this you won’t initially estimate the work required for reimbursing the customers that stayed at home during the storm. You will more than likely find out about this either while you are working on the software thanks to an occasional “WTF? moment” or if you are unlucky when you get people knocking at your door because they want their money back. There are quite a lot of things that we can do to try to limit the negative impact of second order ignorance, like doing risk assessment, or breaking down the complexity in many small stories. This won’t guarantee you remove it but will help in many cases. One thing that we always need to keep in mind is that “we don’t know what we don’t know” so deep inside we know that estimates are only there as a placeholder for people that are obsessed with dates, but deep inside we know that they have no real value.

This guys was very confident, an example of third level ignorant

Then there is a third order of ignorance, and I would describe it as “I don’t know that I don’t know what I don’t know”, basically “false confidence”. This can be extremely dangerous because third level ignorant people make a lot of confident statements because they have no clue that there might be something they don’t know, but when it hits, like Homer once said “Forget it Marge, It’s Chinatown!”

If you want to see the original work on the 5 levels of ignorance see http://c2.com/cgi/wiki?OrdersOfIgnorance

Things that make me happy

October 16, 2013 Augusto Evangelisti Agile Software development, Agile Team, BDD, Software Development ATDD, BDD, coaching, training, workshop

…doing a workshop on ATDD to new hires that are enthusiastic and participate actively making the experience fulfilling.

Myself and my colleague Mary Walshe gave our now traditional ATDD workshop to PaddyPower’s latest new hires and the atmosphere was great, everybody wanted to participate and learn, it just felt great.

Even more satisfying is seeing their answers to the “what did you learn today?” question on post its. They really got it!

I am a lucky man, I enjoy my job.

Stop moaning – Be the change!

October 10, 2013 Augusto Evangelisti Humour, Random Thoughts, Software Development, Testing change, moan, whimp

People moan, it’s a natural thing. It is a way of reacting to difficult situations where we are not able to change outcomes. By moaning, we feel some relief in sharing our discomfort with our friends, family and colleagues.

I confess; I have a problem with moaners because I don’t believe there is anything positive about it and it doesn’t really cut it for me. If I am not happy about something and moan about it, I normally become angrier rather than feeling any better. If I am really unhappy about something I would rather rant for 5 minutes, than moan all my life.

I am sorry to say it, but testers are in my experience the worst category of moaners in IT, maybe at pair with tech support people, but I’ll focus on testers here because I am one.

Testers moan about developers that don’t understand the customers, moan about business analysts that can’t write requirements, moan about managers that don’t give them enough resources, moan because they talk and people don’t listen, moan because sometimes they are paid less than developers, moan because the environment is not working, moan because they find bugs, moan because they don’t find bugs, moan because the application is delivered late to them, moan because the quality of the application is not to their standard and find just about another thousand reasons to moan about.

While I can understand moaning coming from a junior or mid-level tester that has say 1 to 8 years’ experience, I cannot understand, accept or condone a tester calling himself a “senior practitioner” that moans about any of the above.

Senior practitioners are like moaning rock stars, they have all they need but keep on moaning

One simple reason: a real test practitioner is able to face up to every single one of the moaning causing issues and is well able to change them.

Dear senior test practitioner, It is not acceptable that if management doesn’t give you enough resources, you are not able to influence them into understanding that they are making a mistake and need to release more resources, it is not acceptable that the developers don’t understand the needs of the customers and you are not able to come up with a solution that can minimize or even completely resolve the issue.

It’s NOT acceptable.

If you want to call yourself a senior practitioner, then act like one; influence and change the environment you are not happy with. What’s the point in moaning? You will bring down the rest of the team with your negative whiney attitude, won’t resolve anything and will piss off everybody else outside your team that is so unlucky to have to listen to you.

Senior Moaner – “Yes but management don’t understand!”

This is the ultimate answer of every senior moaner. The reality is different though, in fact 60% of the moaners didn’t even talk to managers to suggest a solution, 15% of them have tried and failed because they weren’t able to make their point and influence management, 20% have tried but management were right all along and they keep on moaning hiding the truth, finally 5% of them have tried repeatedly and appropriately to influence managers, but management are actually stupid and don’t understand.

Moaners Distribution among Senior Test Practitioners

Now look at that chart, where are you? If you are in the 5% that already did everything they could, but hit a rubber wall, then I suggest you change job before your moaning alienates you from the rest of your team mates, your wife and friends, in the other 95%, simply stop moaning, do something meaningful with your job, be brave and BE THE CHANGE you moan about!

5 Reasons why best practices are bad for you

September 28, 2013November 2, 2013 Augusto Evangelisti Humour, Random Thoughts, Software Development best practices, growing, kaizen, learning, life, obtuse, people, religion

Exhausted — That’s me after talking to a best practice guy

1st reason: The hardest conversation you will ever have is with somebody that blindly believes a practice applies to every context and it is always valid, no matter what. There are 2 ways out of the conversation, agree with your interlocutor or kill him. I don’t like either option (even though I am often tempted by the second) so I end up trying my utmost to use reasoning and examples, but I miserably fail in 99.99% of the cases, eventually become exhausted and retreat in a personal comatose space where I refuse to discuss the issue any longer. #WinByExhaustion

2nd reason: Think religion. If you are roman catholic like me, then the Bible is your best practice manual. The Bible thinks for you, you simply follow and if you doubt something then you are an infidel that should be excommunicated (who cares?) or worse silenced and sometimes burnt at the stake, don’t you love it? Some names come to mind including Galileo Galilei that was intelligent enough to refuse his own belief, but if you want a more detailed list have a peek here: http://en.wikipedia.org/wiki/List_of_people_burned_as_heretics.

Burn him at the stake! — Is this what you do to different thinkers?

The thing is, you cannot innovate if you believe in best practices, because according to the best practice you don’t need to innovate. Did the roman catholic church evolve? Did they innovate? Fuck no! They are stuck to the day that poor Jesus Christ (God bless his soul) died on the cross and his followers started writing about him. #NoInnovation

Obsession — They have them, they are very well hidden and they are too nice to use them against us: TRUTH

3rd reason: Best Practices are your #1 personal growth enemy. I see extremely intelligent people that have best practices so ingrained in their DNA that refuse to accept every valid reason, no matter what the evidence is. These people are the ones that will lag behind, because for example 20 years ago they might have said “what’s the fuss with this Internet thingy, business is run in factories and shops, you won’t make money with it, unless you are a porn site provider”. Today I hear financial experts saying “Forget about Bitcoin, money is money and people want it in their wallets and regulated banks”.
#GreatThinkingBro

4th reason: Best practices are the antithesis to kaizen, do I have to say more? #YoureStuck

5th reason: Best practices deny men the greatest pleasure of them all, discovery. The day that you switch your brain from following the best practice is the day you might discover something awesome about yourself. The day you start listening to the person you are talking to without having the mental block of the best practice that doesn’t allow you to agree with him. That day you will grow. The day you will say “eureka!”. The day you will discover you are FUNDAMENTALLY WRONG. I love those moments, they make my brain go at 200 miles an hour and in a day I grow more than in 10 years. #NoEureka!

To finish I wanted to thank a few people that helped me reach the “eureka!” moments, you are the reason why I have evolved and I am a better person today than I was before.

In no particular order:

Monica Campardo, Emmet Townsend, Diego Armando Maradona, Roberto Lo Giacco, Gojko Adzic (twice!), Don Gabriele, Aunty “Zia” Enrica, Lisa Crispin and Janet Gregory (books), Mary Coyle, Giacomo Leopardi (poems), My high school Maths teacher (I don’t remember his name but was known among students as “il Roscio” => “The ginger”), Eric Ries (books), Barry O’Reilly and the other guys in ThoughtWorks, Jayne McCormack, My Brother Duccio, Evariste Galois (books), Gianluca Perazzoli, Gerard M. Weinberg (books), My lovely sister in law Luana, My Nana (highest amount of times), Martin Fowler (blog), Gandhi (life and quotes), Auntie Ada, Massimo Troisi (movies), Roy Phillips, Roberto Benigni (movies), Dan North, The “Dude” in the Big Lebowsky

I thank you all with all my heart for proving me FUNDAMENTALLY WRONG that day, and inspiring me to become a better person. I might have forgotten one or two, sorry folks.

Do you want to be in the list? Prove me FUNDAMENTALLY WRONG and give me a “eureka!” moment, I will love you forever!

the dude teaches — The “Dude” proved me wrong when I thought I had to be a serious and stiff arsehole to be liked by people

The Cover Your Ass Manifesto

September 24, 2013September 25, 2013 Augusto Evangelisti Humour accuse, ass covering, blame, cover your ass, CYA, fire him, I am right, shift blame, you are wrong, your fault

We are uncovering better ways of covering our own ass by systematically documenting all we do and blaming others in the process.

Through this work we have come to value:

Being always right over delivering value
Accusing others over resolving a problem
Finger pointing over team support
Measuring anything to find somebody to blame over doing our job

That is, while there is value in the items on the right, we first cover our own ass and point fingers, then we rightfully go home and bitch about you.

Get in shape to become an Agile Tester

September 15, 2013September 20, 2013 Augusto Evangelisti Agile Software development, Agile Team, Agile Testing, Testing activity, cross functional, crossfunctional, skills, specialist, t-shape, t-shaped, t-shaped people

The perfect Agile Team member as seen by Leonardo

Do you want to become a strong agile tester but you don’t know what to do and are scared by the challenge?

Worry no more you are in the right place. We are going to help you get in shape so you can become a strong agile tester and be a very valuable part of your team. We’ll get you into the shape of your life without taking any magic pills or spending half your day in the gym sweating and swearing. You will be able to eat all the food you want and even smoke and drink without losing your shape, just read this article and let your mind wonder.

FACT: There is only one shape that will make you an unbeatable agile tester, it’s called “T shaped Agile Tester”.

Let’s get you there!

What shape are you in now? If you are here trying to get better, chances are you are an I-shaped tester with one dimension only “TESTING”. You know a lot about testing, it has been the focus of your career; research and experience have made you a solid hard core tester. This is what you look like now:

All your research and experience has been targeted at giving you a strong TESTING body. Nobody can say you can’t test, but can you do anything else? Maybe a little but not too much because all you have been involved in has been testing, testing and more testing.

Now, listen to this; what happens when you are finished testing and can’t get anything more to test because your business analysts or product owners are behind and can’t cope with the work flow? Do you sit at your desk and research how to become a better tester? Do you simply say, “Tough shit, when I am busy nobody helps me” and carry on in your trip to testing stardoom? Yes I didn’t spell it wrong, I meant to say star-DOOM. Doom for your team that is stuck on an activity and can’t get things going because the only specialists are swamped. Wouldn’t it be better if you could sit with your BAs POs and help them do their job? Well for the teams economies it sure is.

But, how can you achieve that? Well, listen ,nothing easier. The first thing I would do is ask your BAs if they need any help. If they think you can’t help them because you don’t know what to do, then ask them to sit with them and try to learn what they are doing. I guarantee 100% that you will learn something from this activity and also earn the respect of your team mate.

What if the people to be stuck are the developers? They have been fighting with a complex technical issue and they haven’t been able to deliver anything to you in the last week. You’ve been bored to death and alternated trips to youtube to trips to the toilet and the coffee station. I bet that sitting with the developers you would have not only learned something, but you would have also enjoyed yourself helping and discovering that what they do is not as different from what you do. They would probably be able to give you some easy tasks that you can help them with and together with helping the team you would be learning new skills. This sounds good to me, how about you?

Then you could have gone back to your desk and researched the topic the developers were discussing getting some more knowledge and becoming more able to help them.

By helping and collaborating you are going to get better at the other 2 activities, analysis and development. You won’t be as good as them but not as useless as you were before. you will grow an extra dimension you didn’t have before and become T-shaped.

As you can see from the picture, by gaining experience on the other fields and researching them your legs are slowly opening making you more stable and broadening your ability to support the team. Once you start gaining some cross functional knowledge you will be able to open your arms and support the team, isn’t that great? Imagine how much more valuable you have become now that you can use your new knowledge to help the team remove bottlenecks. Imagine how much more employable you have become. An don’t discount the chance that by learning something different you might even find your real vocation!

You might say, yes, learning is fine and helping is good, but besides that and becoming more valuable, what’s in it for me? This is the easiest part and you will love it. The next time you are stuck with 100 things to test and no time, you can turn around and ask 2 people to help you, one BA and one developer, the ones you helped before! They can pair with you and help you unblock the current bottleneck and get the system unstuck.

Because there are not only T-shaped Agile Testers, but also T-shaped Agile Developers and T-shaped agile BAs and POs.

So stop being a boring I-shaped specialist that is going to be out of a job soon and become a T shaped Agile Tester, you will be more valuable to the team, more employable and best of all never stuck on your own testing like crazy because your colleagues don’t know how to help you! Welcome to the world of cross functional agile teams where there are no roles but activities!

P.S. Credits have to be given to the original inventor of the T-shaped Agile Tester, Leonardo Da Vinci. He initially called the concept “Vitruvian man” but soon came to realise that what he had created would change software development forever and renamed it to “Agile T-shaped team member”. You won’t find a reference of this fact in books, but I know it because he is my friend on Facebook and he mailed me last week to tell me how he wanted to use his concept to help Agile Teams. He is retired now and not much of a talker, so I told him I would help his idea spread.

P.P.S. The real credits for the T-shaped people concept go to the work of Adan Knight and Rob Lambert, see http://thesocialtester.co.uk/t-shaped-tester-square-shaped-team/ and http://thesocialtester.co.uk/t-shaped-testers-and-their-role-in-a-team/ for more details.

How I stopped logging bugs and started living happy

September 10, 2013November 27, 2014 Augusto Evangelisti Agile Software development, Agile Team, Agile Testing, Lean Software Development, Software Development, Test Automation, Testing lean, nobugs, zero bugs, zero tolerance

Because there is not such a thing as a best practice

ATTENTION: This won’t work for everybody, all I claim is “it works in my context” and you might try to use it at your own risk.
WARNING: If you believe in best practices that should be applied to every context go away now, you might be harmed by this post

One day, a few years ago, I had a conversation with an inspirational man, he was at that time my CTO. He was talking about zero tolerance to bugs and how beneficial is to remove the annoyances of bug management from the development of software. I was listening but at that time I didn’t grasp completely the concept, because by then, I had never seen neither envisioned a situation where a development team could produce zero or for that matter even close to zero bugs. Since then a few years have passed and I have worked hard on his vision. Today I can say, yes he was right and a development team can deliver value with 0 bugs, I even learned that the project team doesn’t have to spend half of its time playing with a bug management tool to file, prioritise and shift waste.

Let me give you some context around my project and current practices:

Two co-located cross functional agile teams each with 4 developers, one tester, one business analyst, one product owner one dev-ops guy and a team lead also known as kanban facilitator (18 people)

Kanban Board — Kanban board visualizing our process. (Discuss, Distill, Develop and Demo are stolen from the great work of Elizabeth Hendrickson)

1. We use Kanban to visualize our process and we have the ability to deliver every time we complete a user story if we wanted.

2. User stories are small and we create them so that we can deliver them in less that 3 days

3. User stories are vertical, i.e. no big bang integration is required between the teams, each team works on the full codebase that spans across multiple applications

4. We follow an hybrid between ATDD and Specification By Example that I have specifically developed for our context

5. Developers code review every line of code before every push, we also do some pair programming mainly to train junior developers

6. Developers maintain a healthy 95% or more unit test code coverage, we also enforce all of Sonar coding rules

7. Some of the developers practice TDD

8. We use Jbehave and Thucydides to automate ~100% of our acceptance tests

9. We have an internally developed “platform on demand style” build and deployment pipeline that runs all our functional tests and performance/load tests that check variations against a known baseline

10. Every automated test runs after every push to trunk in such pipeline

11. Every push to trunk gets deployed automatically and can be manually promoted to exploratory testing stage and beyond

12. After all the acceptance tests pass for a user story, we do exploratory testing on it

13. After exploratory testing is complete, we demo to our product owners that subsequently do user acceptance testing before accepting the story

14. If a bug is found during exploratory testing or user acceptance testing the developer(s) that worked on that user story, drop everything else they might be doing and fix the bug, the card will NOT progress if a valid bug is not fixed.

15. If a build becomes red, the developer who causes the instability drops everything else and fixes the issue straight away. Build must be always green.

16. When a developer fixes a bug, he writes automated tests that cover such path

You noticed I mentioned bugs in 14 and 16. Yes, of course, we are humans and we make mistakes, this doesn’t mean that we need to celebrate the mistake and make it visible by logging it in bug tracking tools that we will need to run and maintain among with the waste stored into them when the poor bug has the life span of an unlucky butterfly.

When i find a bug while exploratory testing I simply go to the developer and tell him, look pal I think there might be an issue, come to my desk and I’ll show you. If he needs to go home and can’t fix it straight away, no problem, I will stick a red post it on the user story card on the physical Kanban board with 2 words describing the bug so nobody will forget. BTW that card is not going anywhere until the bug is fixed and buried. The red post it goes into the bin after the death of the bug.

The development approach we follow, allows us to have a very good understanding of the business value we deliver as we do group discussions to derive examples for each user story, when you add a bunch of excellent developers that follow good engineering practices you will find out that the bugs you discover when exploring the software are very few, once you act upon them immediately, no excuse, bugs become something that doesn’t really

bother you.

In this situation, logging and managing bugs is simply waste and we all live happy with no bug ping pong between developers and testers, no bug prioritization meetings, no bug triage meetings, no bug statistics, no need for bug trends to identify product release dates, and guess what we deliver bugless software that delights our customers.

EDIT: I am not alone! Have a look at the great work from Katrina here http://katrinatester.blogspot.co.uk/2014/11/different-ideas-for-defect-management.html