What tester are you? /s

Let’s see what kind of tester you are, answer the 3 questions below and find you profile description at the bottom.

You start testing and the product has obvious problems even with the “happy path”, both cosmetic and very obvious bugs are everywhere, what do you do?

  1. I send the product build back and don’t touch it because it is not testable and back to facebook for the day!
  2. I log 124 bugs in extreme detail, one for every problem I encounter. If somebody after 3 days asks me why I am not finished yet, I respond that I am logging bugs and testing is not complete.
  3. I go talk to the developer that made the last check in and ask him why he didn’t test his product. If he says, “because you are supposed to do that” I talk to him about the incredible amount of waste he is creating by delaying the feedback on the product and not testing it himself. I sit down with him, ask him to test the product and fix the issues we find together in a continuous loop until we both are quite happy with the result.
    I then explain to him that if the feedback for each of the issues has to come from a different party (me) the delays in the detect fix retest rate will create a massive amount of waste. I encourage him to test his application before sending it to me and as we are at it I suggest the next time we test it and fix it together.
  4. I tweet to the world how idiotic my developers are and include screenshots of the errors. I spend 2 hours defending my point on social media and catching my interlocutors on inappropriate use of terms to prove my point.

You have been sitting idle on your chair for over an hour because there is a delay in the build you want to test, what do you do?

  1. Yippee I have time to browse the web and watch some videos on youtube! I hope their problem persists for a while, the new Game of Thrones season is awesome!
  2. I look at my test plan, change it a bit, add some graphics, get a coffee and start reading that testing book I always wanted to read.
  3. I have been out of my desk already for 50 minutes. 10 minutes idle time is waste, our customers are getting our product later than they should.They say there is a problem with the build, let me see if I can help out. I go and offer my help to my teams’ developers. They might need me to rebuild a machine to check something or to try something quickly to debug the problem. I get stuck into it, wow, I even learn something about it! I might even resolve the problem altogether using my strong critical thinking skills and looking at the problem from a different perspective. I help, we solve the problem and, yes, now I can test it! Chances are that while troubleshooting the problem I have already gathered a lot of information on the product that will support and supplement my testing.
  4. If developers are idiots there is nothing I can do, I will spend this time blogging about how to become a better tester and how testing is the most important thin g in the universe, much more complex than development by the way.

Developers have nothing to do because the analyst has been sick and there are no refined user stories in the backlog, you just finished testing, what do you do?

  1. BINGO! I might as well re-start House of Cards
  2. I start complaining and moaning about how this company sucks and about how better it would be if I was the decision maker here. We need to hire more analysts and testers of course! I then go back to writing more test cases even if there is nothing to test. I might also create some fancy SQL query to extract lovely bug lists to show to management with graphs and all.
  3. Great opportunity for learning a bit more about how business analysis works. In the previous weeks I have been helping the analyst and I think I can get the job done. I organise a meeting with the team and we start breaking down user stories, as soon as we have a couple ready we can start working. I will replenish the backlog until the flow is reestablished, using WIP limits will help me understand how much work I need to do on this.
  4. There is nothing to do, if development activities are foreign to me, imagine how I feel about doing something that is even further away from my testing world. I am here to find bugs and provide information to stakeholders, not write user stories, hire more analysts if you don’t want this to happen.

RESULTS

If most of your answers are 1, you are a slacker that happened to be doing testing. Why don’t you find a job you enjoy doing instead of trying to avoid the one you have?

If most of your answers are 2, you are an old time tester that spent the last 15 years in a bubble far away from the evolving world. Nothing outside your little testing world is worth consideration, after all you know better than anybody else and why should you improve?

If most of your answers are 3, keep on doing what you’re doing, you and your company will be OK

If most of your answers are 4, I know who you are 🙂

 

 

 

The Agile Tester, a curious and empathetic animal

Agile testers at work
Agile testers at work

The agile tester (ˈadʒʌɪl/ ˈtɛstə/) is a 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 other’s 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