mysoftwarequality

Breaking people's balls since February 1970

Agile tester part 2, questions and answers

Warning: The opinions expressed in this post are mine only, please do not use them against any other group of people, but only against me, that is Augusto Evangelisti a.k.a. Gus.

After writing my most recent blog post “The Agile Tester, a Curious and Empathetic Animal” I received quite a lot of feedback for which I am very grateful. Feedback in the form of a conversation is the true fuel for learning and improvement.

To all of you that have mailed me, tweeted about my post, responded using the comments in my blog and talked to me face to face about it, thank you so much for helping me learn!

When i looked at the feedback I received, I saw 2 quite different trends. Looking closer I saw that the different feedback types came from different schools of thought.

Let me give you 2 examples for some context

This one from twitter

This one from one comment to my blog post

Michael Bolton: Something about this post troubles me, Gus. In order to test what was troubling me, I took the content and replaced each instance of “tester” with “programmer”. The result made perfect sense, of course, but it left me wondering: if I can replace “tester” with “programmer”, what distinguishes the tester from anyone else on the project? What is the special role, the particular set of activities, that the tester performs? Is there a difference between the programmer’s mindset and the tester’s mindset? What is the mission, the distinctive reason for having a tester on the team—whether that person has the title “tester” or something else? What is it that distinguishes testing work from all the other work? What testing-specific skills do testers bring to the table? What is testing?

I have answers of my own, of course. But I’m wondering what your answers might be.

I am using Lisa’s and Michael’s as examples of the feedback received because the former is a recognisable exponent of the agile testing community and the latter is a recognisable exponent of the context driven testing community. The other feedback that i received from people close to each of the 2 communities is extremely similar to theirs.

If a group of people finds troubling what the other group finds great, I smell something interesting and an opportunity for learning.

I’ll try answering Michael questions and look forward to his very own answers to learn something:

Question#1:  Something about this post troubles me, Gus. In order to test what was troubling me, I took the content and replaced each instance of “tester” with “programmer”. The result made perfect sense, of course, but it left me wondering: if I can replace “tester” with “programmer”, what distinguishes the tester from anyone else on the project? What is the special role, the particular set of activities, that the tester performs?

Michael, the distinction between different roles in agile teams is becoming more and more blurry. Agile teams value competencies more than roles. As an agile tester in my team I have core competencies that i use to support my team. These include but are not limited  to the ability to evaluate a product by learning about it through experimentation. I also use such competencies to coach and lead other members of my team that are not that strong in that area and help them grow towards an ideal form of generalising specialist. Finally I also perform tasks outside my main competency to support the team. In some cases I will need guidance from another member of the team whose core competency includes the ability of performing such task. I believe that this blurring of the roles increases agile team members accountability, in fact nobody in an agile team (developer, tester, business analyst, operations specialist, UX expert, et cetera) should ever say, “I’m X, doing Y is not my job” but they should instead ask their colleagues “how can I help you?”. Shared activities are key to learning and gaining competencies.

The main goal for any agile team member, regardless of his role is delivering customer value.

Question#2Is there a difference between the programmer’s mindset and the tester’s mindset?

Yes, there is a difference, I don’t think it constitutes an insurmountable obstacle. One of the teams I have worked with, knowing that I wouldn’t be available for a period of time, suggested they needed the tester’s mindset for certain activities and decided that to make sure they were focusing on the right things, they would wear a big red hat. This simple change helped them keep their focus and their mindset in the right place. It might not be prefect but it worked. It works also because I speak to them about the testers mindset when we work together, I give them examples of what I am thinking at specific times and why it is important to think about such things. Developers are very smart people, once they understand a practice has value and receive sufficient amount of coaching, they can learn to do almost anything.

Just to avoid misunderstandings, our developers wear the testers hat when performing testing activities with other developers, i.e. they don’t use the hat for their own code as maybe this could be asking too much.

 Question#3: What is the mission, the distinctive reason for having a tester on the team—whether that person has the title “tester” or something else?

The mission is to provide the team with the testing competencies it needs so that customer value can be delivered. The secondary purpose is to train and coach the team so that they can gain some of the competencies to support test activities. Coaching and training can be also formal but it is mainly delivered by working in pairs.

 Question#4: What is it that distinguishes testing work from all the other work?

Every activity the team engages in, is performed to deliver customer value, including test activities, but I am not sure I understood your question completely, could you please rephrase?

Question#5: What testing-specific skills do testers bring to the table?

See answer to question#1 re. competencies. My main competencies are exploration and learning.

Question#6: What is testing?

Testing to me is exploration and learning.

I test ideas to prevent defects, software to detect them and product owners assumptions to reduce waste.

 

I hope I have clarified some of your doubts and I am curious to hear your answers to your own questions.

 

 

The Agile Tester, a curious and empathetic animal

Agile testers at work

Agile testers at work

The agile tester (ˈadʒʌɪl/ ˈtɛstə/) is an mammal member of the family “Exploratoris”. He lives in the wild in small groups named cross-functional agile teams.

Skills

Besides communication and technical skills, his main traits are curiosity and empathy[1].

Curiosity helps the agile tester in finding opportunities to improve the product. The agile tester questions everything.

Empathy allows the agile tester to interact and collaborate with the other members of the agile team smoothly.

Mission

The agile tester has an overwhelming interest in delighting customers.

His customers are the product owner and the final users.

He strives in balancing his efforts between making his company successful and delighting the final users by delivering a continuous flow of value to both.

Life

The agile tester spends most of his time having numerous conversations with other members of the team [2].

He will often speak to and question the product owner and the final user in the quest of real value. The agile tester knows that if he doesn’t understand perfectly what the value to be delivered is, he won’t be able to do his job. He builds a strong understanding of the business context he lives in, to be able to help the product owner identify more valuable solutions. This aspect is extremely important to the agile tester, he strives to contribute to building a better product.

Often he will be found having a conversation with the product owner and a developer. This group of animals also known as “The 3 Amigos” [3] feed off each others knowledge, different perspective and passion for value to resolve all sort of problems and design lean solutions.

Other times he will be seen pair testing while coaching his partner developer or supporting a developer writing checks, or even writing some checks himself.

Some agile testers have been seen speaking to final users to better understand their experience with the application.

He is also sometimes found alone at his desk testing, softly talking to the application under test.

During the night the agile tester studies and researches his craft, sometimes he blogs and if you watch attentively you might spot a lone agile tester engaging in passionate testing conversations on twitter or in a bar in front of a beer.

Social life

The agile tester’s’ life would not be possible without the team. He works and lives with the team and for the team, the team is an organism that functions with the agile tester[4].

The agile tester is a pragmatic animal and doesn’t like the company of moaners that do nothing to improve their condition. The moaner is the nemesis of the agile tester [13]

The agile tester believes in sustainable development and will not work overtime except for very special circumstances. He will push for process changes to remove other overtime occurrences.

The agile tester and waste

In general the agile tester refuses the concept of waste.

He will not under any circumstance do something “because that’s  how we do things here” or “because the boss said so”. He will ask “why?”[5]. If he cannot get an answer that clearly explains what the value is, he won’t do it. He’d rather be fired than spend time doing things that don’t produce value.

On this subject he is known for using lean documentation, he generally enjoys documenting the application he is helping create through executable specifications[6].

He rejects the waste of bureaucracy and signoffs [7], in fact it is common seeing agile testers signing off by high five[8] in groups of Three Amigos rather than negotiate contracts.

The agile testers understands that producing, finding and fixing bugs is a wasteful activity and he will strive to help the agile team prevent them and do the thing right the first time as much as humanly possible[9]. The agile tester, not only understands this, but he coaches the developers members of the team on this concept and trains them in learning  techniques that help them prevent bugs.

The agile tester believes that his skills are wasted performing regression checks, in fact he employs tools for this menial task[10].

The agile tester prefers cards and conversations to large documents. He plans his activity just in time and helps build the next parts of the product using discovery.

Some agile testers believe predicting the future is a waste of time and prefer building predictable process rather than estimating, they have been known for insistently using the tag #NoEstimates

Some extremist agile testers even got to the point to say that bug management is waste and have removed bug management tools from their organizations with a positive impact[11].

Education

The agile tester is a continuous learner.

He believes in agile principles and he studies the impacts of agile software development on his industry trying to learn new approaches to improve his own company and the whole agile community.

He believes that continuous improvement (as in kaizen) means everybody in the agile team is empowered to drive it. He helps other team members bring out their solutions and support them in convincing the team to try and measure results.

He does not believe in best practices but in good practices that can be improved[12]

NEW! Continue reading with Agile Tester part 2, questions and answers !

References:

[1] Get In Shape to become a better Agile Tester

[2] [6] [9] When Something Works Share it 

[3] George Dinwiddie on the Three Amigos

[4] Cross-dysfunctional teams

[5] Be lean ask Why?

[7] The Cover your Ass manifesto

[8] Sign off by High Five

[10] Test Automation, Help or Hindrance?

[11] How I stopped logging bugs and started living happy

[12] 5 Reasons why best practices are bad for you

[13] Stop Moaning, be the change

Testing, the big agile misunderstanding

Navigating social media I bumped into the Capgemini Word Quality Report 2014-15. After sharing my personal data with Capgemini, I downloaded it and started reading. First of all, it is a very well written document, second the findings are interesting, I will talk about some of its puzzling conclusions some other time.

What I am going to comment on here is one small part in the chapter “Agile Testing: Growing in Acceptance, Still to Fully Mature” and in particular to the finding that the biggest challenge in agile testing according to the report is:

“Lack of a good testing approach that fits with the agile development method”

According to the report 61% of the 1432 respondents (among 1543 CIOs and IT testing leaders) claim this is an issue for their organization and among the issues this is the most widespread.

Can you see the real problem?

The problem is that 61% of the interviewed don’t know what agile testing is about, and that’s the real issue.

Agile testing is an inseparable part of agile software development how can it not fit with itself?

Do you want to know when it will not fit? It will not fit when you try to shoehorn traditional centralized independent testing approaches into an agile development team. Yes in that case it won’t fit at all, in fact, forget it, if you do that you will fail.

Do you really want to be agile? Really? Then forget about Test departments and change the culture in your organization. Software quality is everybody’s responsibility in an agile organization, embrace the change and YOU WILL FIT.

 

 

 

Continuous improvement is an infinite loop

This morning, at home with the flu, I thought about visualizing a continuous improvement process (that’s what crazy people do when they are sick). So I took markers and paper and I started to draw. Looking at it I realised that I was drawing an infinite loop. With my developer hat on I thought: WTF? There is a problem. I need to fix it.

Then I looked again, and it hit me. No problem at all, continuous improvement IS an infinite loop, and if you think you are done improving your process you are doomed!

You might say that the word continuous should have tipped me, yes you are right, but I find that looking at a graphic representation of a concept always makes me discover new things, that’s why I draw things even though any 5 years old could do a better job.

Markers + A4 paper + MsPaint + phone cam + Gliffy created this thing

Continuous Improvement

Some quality metrics that helped my teams

Measuring_Tape_Inch+CMI’ve been asked the question “what are the best metrics to improve software quality?” (or similar) a million times, this blog post is a selfish time saver, you are probably reading this because you asked me a similar question and I sent you here.

Firstly, i am not a fan of metrics and I consider a good 99% of the recommended software quality metrics pure rubbish. Having said that there are a few metrics that have helped teams I worked with and these are the ones I will share.

Secondly, metrics should be used to drive change. I believe it is fundamental that the metric tracked is clearly associated to the reason why the metric is tracked so that people don’t focus on the number but on the benefit that observing the number will drive.

Good metric#1: In order to be able to re-factor without worrying about breaking what we have already built we decided to raise the unit test coverage to >95% and measure it. Builds would fail if the metric was not respected.

Good metric#2: In order to reduce code complexity, improve readability and make changes easier, we set a limit and measured the maximum size of each method (15 lines) and the cyclomatic complexity (don’t remember the number but I think it was <10). Builds would fail if the metric was not respected.

Good metric#3: In order to continuously deliver low complexity easily testable units of work and help with predictability we started measuring the full cycle time of user stories from inception to production with the goal of keeping it between 3 and 5 days. When we had user stories that took more than 5 days we retrospected and examined the reasons.

In the 3 cases above, the focus is on the goal, the number is what we think will drive the change and can always be changed.

If people don’t understand why they write unit tests, they will achieve unit test coverage without guaranteeing the ability to refactor, for example by writing fake tests that don’t have assertions. We should never decouple the metric from the reason we are measuring something.

These are the good metrics, for me. If you want to see some of the bad ones, have a look at this article I wrote some time ago on confrontational metrics and delivery teams that don’t give a damn about their customers.

http://mysoftwarequality.wordpress.com/2012/12/27/the-wrath-of-the-mighty-metric/

Cross-dysfunctional teams

Every agile enthusiast will tell you how powerful a self-empowered cross-functional team can be. Once you have one, it brings complete team accountability from product idea to customer support, it naturally grows with continuous improvement, and finds self motivation in innovation and delivery of customer value.

It’s a beautiful and powerful concept; the practical implementation sometimes is not so beautiful and more often than not what you get, is a cross-dysfunctional team.

Let’s have a look at the cross-dysfunctional examples I have experienced.

Pseudo specialist cross-dysfunctional teamfarm-silo

Developer: “I am a developer I am not meant to test, the testers test!”

Tester: “I don’t need to know anything about how the product is designed, I only care about how the customers use it!”

Business Analyst: “I am not technical, I can’t help you guys!”


devops“As Long As It Works for us” cross-dysfunctional team

Developer: “It works in our environments, it’s operations responsibility to make it work in production”

Tester: ”Listen, it worked in UAT, it must be a configuration issue, or a missing firewall hole and nothing I could have spotted during testing…”

Customer: “Hello! Nothing works here…”

Abdicating cross-dysfunctional teamheadinsand

Developer: “The architect told me to do it like this”

Tester: “Feck it, let the Test manager deal with it”

Business Analyst: “I don’t think there is any value in this story, but the Product Owner wants it, so get on with it and develop it!”


no-thanks-were-too-busyContinuous Decline cross-dysfunctional team

Developer: “No point in doing retrospectives, things are always the same”

Tester: “We DON’T HAVE TIME to try new things!”

Business Analyst: “We do it like this, because that’s how we do things here, and that’s it!”

Disintegrated cross-dysfunctional teamWorked-Fine-In-Dev-Ops-Problem-Now

Developer: “My code works perfectly, it’s their system that doesn’t work, who cares”

Tester: “We have 100% coverage, all our tests pass and we have no bugs, if the developers of system X are idiots, there is nothing we can do about it”

Customer: “And still, nothing works here…”


ihazsuperiorityNazi cross dysfunctional team

Developer: “Testers are failed programmers, they shouldn’t be called engineers”

Tester: “Developers are only able to produce bugs, the world would be better with more testers and less developers”

Business Analysts: “I don‘t know why I bother talking to testers and developers, they are total idiots”

Do you recognise your team in one of the categories above? What have you done until now to help your team change? Little? Nothing? But you are still bitching about it, aren’t you?

Remember, you are very powerful and can become the change that you want to see.

Agile2014 day one lessons learned

1. Asking Microsoft to do the keynote at an Agile conference is like asking Justin Bieber to conduct orchestral music. #fail

Facepalm

Facepalm

2. “Management is the Act of Serving and Supporting Everyone’s Natural Awesomeness” and Woody Zuill in person is a really awesome guy #mobprogramming

Woody

Woody

3. Moving from being a Test Manager to being a tester in an agile team is far from being a demotion #embracechange

change

4. Tim Ottinger can play guitar, knows a thing or two about pair programming and stand-up comedy #learnwithfun

Tim

Tim

5. Changing people’s job title can greatly affect the way they are perceived and accepted – thanks Martin Hynie! #usejobtitleslikeaweapon

martin

Martin

6. The 3 amigos is an amazing concept and alligators are softer than you’d think #imissthemalready

The 3 Amigos

The 3 Amigos

Complexity is the Excuse

People think I am a fool

People think I am a fool

When I speak to people about how it is possible to continuously deliver customer value with near zero issues, I usually get laughed at.

After I tell them that there is nothing to laugh at, people start challenging me on how I integrate with other systems, how I manage defects, how I deal with changing requirements, how I manage regression issues, and how I cope with context switching and other similar issues.

Luckily enough I have empirical data and my answers are based on experience and not some book or model I read about somewhere, so after a while I manage to get people moving from laughing at me to at least starting to be curious.

It has to be said, people become curious but deep inside they still don’t believe me and still think I am a big fool.

How could I blame them? I would have done the same a few years back. I know that people need to have to prove it for themselves to be able to believe it, I have no problem with that.

While I manage to explain my way of dealing with defects, changing requirements, regression, and context switching, until now I haven’t been able to answer the biggest question of them all, the one that every conversation ends up with eventually: how do you deal with extremely complex systems that need to scale up?

I have been thinking about this for a while now and the more I think about it the more I become convinced that Complexity is the Excuse.

Complexity exists when we are not able to prioritise the value to deliver (we don’t know what we really want).
Complexity exist when we are not able to understand and describe the system we are building.
And finally, Complexity is a nice excuse for not doing our job properly as software engineers and having something to blame.

The net is not complex to the spider

The net is not complex to the spider

Reduce Complexity and stop taking excuses:
1) You want to deliver customer value, OK. You don’t need to deliver everything on day 1. Sit down with your business partners and identify the highest value added feature and focus on that one. If asked for bells and whistles, say, “we will do it later and only if we really need to”, chances are when you are finished doing the first feature you will have learned that you need something different anyway.
2) When deciding how to implement such feature, look for the simplest and cheapest solution, do NOT future proof. By future proofing you will be adding complexity and guess what? YAGNI. Measure the success of your feature and feel free to change direction, failure is learning.
3) Once you have identified the value to be delivered, make sure you break down its own complexity. If a user story or unit of work or whatever you call it has more than one happy path, then it is too complex, break it down into 2 or more units of work.
4) If you start working on something and you discover it is more complex than you had thought, then stop and break it down to less complex units, if you keep on going saying nothing, you will hide complexity and sooner or later you are bound to mess it up.

Scaling up is the wrong answer to the false complexity question.

Chances are you don’t need to scale up at all: Read 1 and 2 again and again, you will find out that you don’t need as many resources as you thought you would. Scaling up, most of the times, is the easiest, most expensive and laziest approach to fight complexity.

For doing 1) and 2) in a structured manner I strongly recommend an approach called Impact Mapping devised by Gojko Adzic, it works.
For doing 3) click here
For doing 4) use your head

TL;DR: stop blaming complexity when you don’t understand what you are building

Tech Conferences for Dummies – dos and don’ts

I love going to tech conferences, I love the buzz, the learning, the engagement and the fun. There are a few things you can do to get the best value out of attending a tech conference, keep on reading.

1. Draw a plan and make sure you don’t stick to it

Plans Change

Plans Change

Every self respecting tech conference will have a public program listing all the available sessions, times, locations etc. Well before going you want to read it and identify the talks, workshops, open sessions you want to attend. That’s the easy part.

The measure of how successful your participation to the conference is, is directly proportional to the amount of unplanned sessions you attend. Why do I say that? When you were planning, you were reading a session’s abstract, maybe researching the work of a speaker, but deep inside you needed to trust your intuition believing that what will be at the session is what you expect. The great thing is that once you are at the conference you will be able to ask other people what they think about a speaker, about a specific subject, about other sessions and so on. Use people around you to challenge the assumptions you created while reading the session’s abstracts, discover what you didn’t know you didn’t know with the help of the other conference attendees. Be agile, discover, adapt your plan and act!

Discover The World

Discover The World

2. Ditch your work mates and discover the world

If you are at a tech conference, chances are you are with at least one or two colleagues. Let me ask you a question: do you think you are going to learn more if you stick to your mates and avoid talking to the rest of the people or if you open up and speak as much as possible to the other conference attendees? The answer seems obvious, but you will be amazed by how many little “same company groups” stick together through thick and thin and avoid contact with “the others”. Ask yourself, am I here to learn or to be shy and protected by my team mates? You know the answer, get out there, mix up with people from all over the world, share your experience and and learn from theirs, you will be surprised how many people do great things, yet in a different way from you.

Interact With The Speakers

Interact With The Speakers

3. Interact with the speakers, they are (mostly) decent human beings and they care

You have been following this guys’ blog posts for years, you’ve read all his books, you have attended 2 other talks he presented in the past and you are inspired by his ideas. Now he is there, having a coffee during a break between sessions and you are there with that “huge question” you have never been able to answer in your mind no matter how many times you reread his books. What do you do?

  1. Stare in awe and duck if he is looking at you
  2. Run away before he recognise you from your twitter account picture that has been re-tweeting all his tweets in the last 5 years
  3. Go there, introduce yourself and ask the “huge question”

Another obvious choice if you want to grow, but make no mistake, most conference attendees do either 1 or 2. I can guarantee that the speaker will be delighted you’re interested, will be flattered by the fact you are familiar with his work and will do everything possible to answer your question and make sure you can put your mind at rest. Here’s the deal, if you do 3 and the speaker treats you badly and embarrasses you because you asked a stupid question, I will buy you a beer.

Go to Open Sessions

Go to Open Sessions

4. Go to as many open sessions as you can

Be it a “pitch your idea” or a “lean coffee/beer” or a “games session” or any other open session where you can interact with others, please go go go go go! In these sessions you will find people that maybe had an intuition but their idea is still half baked and you can help them discover it, you will be asked to participate and interact with others, you will discover something new that you didn’t know existed and more importantly you will be able to interact with other people in an informal environment. Introduce yourself, ask for names, show interest, talk and listen, listen, listen.

Tweet Blog Talk

Tweet Blog Talk

5. Tweet, blog, talk about the interesting session you listened to and the things you learned

Be nice to others, if you learned something valuable, share it with the rest of us, we appreciate it. When tweeting or blogging add the handle of the speaker you are talking about allowing him to interact with you and make your tweet, blog richer and more interesting for everybody.

Have the Craic

Have the Craic

6. Relax and have the craic

Most conferences are hosted in fancy hotels that have beautiful bars with plenty of tasty fluid. Go to the bar and you will be surprised by the fact that a good 50% of the punters are speakers. For some of them speaking at a conference is their job, talking and interacting with people all day can be stressful, so some of us like to have a drink or two to unwind after all the talks are finished. Join in, bring your pint over to any group of people, speakers, attendees, it doesn’t matter and start talking to them, more than likely you will find out you have something in common with them, after all you are all there for one thing, learning.

 

2013 in review

The WordPress.com stats helper monkeys prepared a 2013 annual report for this blog.

Here’s an excerpt:

The concert hall at the Sydney Opera House holds 2,700 people. This blog was viewed about 18,000 times in 2013. If it were a concert at Sydney Opera House, it would take about 7 sold-out performances for that many people to see it.

Click here to see the complete report.

Follow

Get every new post delivered to your Inbox.

Join 71 other followers