Agile Testing Days 2014 - Day 1

Agile Testing Days 2014 – Day 1 

So…let’s start this live blogging thing! Sometimes it may come across as word vomit, but I’m just doing my best to feed you what is being said during presentations with maybe an opinion of my own here and there.

Quick re-cap of the previous day. I wasn’t able to attend the speakers dinner, I think I missed a whole lot of fun! But I couldn’t leave work early enough to attend and it was a 7 hour drive, oh well. The bar got crowded after the speakers got back from the dinner and it was so nice to see all the familiar faces and chat over a beer. I tried to go to bed at a reasonable time, but I ended up sleeping at 3 am. Not because I stayed at the bar, but because the pillows in the hotel are ridiculous. A lot of hotels provide a concept of a pillow rather than an actual pillow, it seems. So, with about 5 hours of sleep I’m going to see how this day will go.

Day 1

I was downstairs pretty early and saw that there was no queue for the registration desk. They knew my name, which kind of baffled me but hey, I never had such a smooth registration process at a conference ever. No complaints here. Breakfast was good as always, had lots of fruit and copious amounts of coffee to compensate for the pillow-incident. Going to buy a new pillow during lunch break, I swear. Sleep is sacred. Enough smalltalk, let the keynote begin!

Keynote – Lisa & Janet “Welcome to the Future” 

Last year these ladies did the closing keynote that started with an awesome piece of acting. Something with a wall, cowboy developers and fluffy beasts. So, I’m expecting a lot right this year.

And then, the SUPER AGILE PERSON came on stage again to free the customer, who was apparently backed up in a corner. Collaboration was central last year, so where do we continue? With Captain Kirk and Spock, of course! 

Questions: What are the current challenges for testers?  Can we change the conversation as testers? 

What do we want vs what do we need 

As a tester you don’t have all the skills you need to test all kinds of new fancy technology. The solution is to be a T-shaped person with broad skills in general and specialised skills in some areas. You’ve got to know where your weak spots are and team up with someone else (dev/BA/PO/etc) to improve yourself if you are faced with new technology and challenges.

Always think about the context of your project. Expand your technical awareness where it’s needed and use exploratory testing techniques. New challenges here are: how to deal with Big Data, generative testing and swarming (would like to learn more about swarming, it sounds exciting).

Ah, and now on to the devil in the box: distributed teams. I’m fortunate (?) enough to have my team in the same room, but yeah, it’s a reality many people face. Is it possible to work agile with a distributed team? You want to see other people face to face, but we are forced to use the tools we have. Use them more wisely is the advice here. Don’t be afraid to use a video call to talk to your teammates overseas and use cloud-tools like mindmapping (personal tip: MindMup by Gojko Adzic) to create shared understanding. 

And apparently, some people still don’t user their feet enough. They’d rather pick up the phone or email, but that really conflicts with agile values. Talk to your team mates! Seems like a big “DUH” to me 🙂

Next, the challenge that has been there forever: how do we identify what the customer wants in stead of what they are asking you to deliver. Lisa’s tip here is: use Impact Mapping. Arrange a session with your PO and/or other stakeholders and try to find out what problem they’re really trying to solve.

*Technical problems are making all the slides look pink and totally 70-ies. I thought it was on purpose and looked hip, but it’s not* 

Ok, continuing the story: you can also incorporate other disciplines. Bring out your inner BA and UX’er. You won’t be an expert but it doesn’t hurt to expand your skillset. It’ll make you a better tester as a whole.

AND: try to guide development with examples. Ask lots of questions, clarify fuzzy requirements and create shared understanding. This isn’t new, but refers to Behaviour Driven Development, Example Driven Development and so forth. If this was new to you, you really have been living under a rock 🙂

What may not work in the future?

Stop counting bugs, stop talking about the quality of the process (HEAR, HEAR!). Talk about business value, risk and uncertainty instead. Risk analysis is still a legit method to figure out where you need to test heavily. 

Business value is more important than ever. Software is embedded in our daily lives so much, that you really need to add value for your customer to stand out. This goes hand in hand with thinking about the risks in your product. There are different kinds of risk: reputation, first-time-right-risks…etc. And also think about the uncertainty of what you’re trying to build. Use the Cynefin model to figure out complex vs complicated and simple vs chaotic. 

Visualise your work! This is becoming more important. Nobody wants to read a boring word document, it’s way better to be creative and visualise your progress. It isn’t easy to do this right though. (Read “Thinking, Fast and Slow” if you want to learn more about classic thinking fallacies we humans make is my personal tip. I was also thinking about David Evans keynote from last year “Visualising Quality”. You can still find it online if you Google.)

PLAY – OBSERVE – INNOVATE

With this cycle you can improve your product. We tend to forget that playfulness is an important aspect of testing. Bring out your inner 4 year old. I think it goes without saying that innovation is important… but there is no recipe you can follow to do this right. 

We cannot predict the future. All we know is that we, as testers, have to evolve and adapt ourselves so we will always be able to add value to teams.

Lisa and Janet: maybe in the future we will build stuff value-based and risk-based, not test-based. So no more counting bugs and analysing requirements, just focus on value. “Never stop doing customer validation and experimentation”.  

Lisa: Always think for yourself, don’t let some expert tell you a silver bullet exists. Experiment, tweak, try new tools. Make new connections at the conference!

Conclusion: this keynote entails everything what an agile tester should know. DOING this is the hard part though….

Meta-level of this talk: high 

Kristoffer Nordström – The struggles of my identity and how I got my developers to start testing

I quickly talked to Kristoffer during the break before his talk and it seems we share a lot of the same struggles. As long as I keep getting broken builds from my developers it seems that they don’t really test the stuff they build, which is a shame and an agile capital crime but whatever. In reality, it still happens. So what can we do to get our devs to start testing? 

 Now, on to Kristoffer. You have to identify yourself as both a tester AND a developer. He calls himself a test developer who loves to automate testing, so that he can focus on quality human testing. I hope every tester identifies him/herself with this!

In a team everybody wants to fit in, wants to belong. We have certain ‘personas’ we play out. At work you’re a little different than how you are at home (not sure if I agree). It seems that when you’re in a new team ‘everybody is so cool’, everybody seems to know what they’re doing. Kristoffer claims that 7 out of 10 people are afraid that they will be unmasked as ‘fakes’, aka the Imposter Syndrome. “Everybody else is so cool and I’m not.” (this feels like a really weird concept to me…just be who you are).

The not-so-cool syndrom for testers usually means: “I can’t code, I’m not so cool as a dev.” “The other testers are so good at Exploratory Testing”. A risk is that you frantically are trying to learn ‘everything’ and end up being like thinly spread peanut butter, tasteless. Pick your battles and have faith in yourself that it’s okay to not know everything. I think this is a nice point, although it’s hard to combine with the ‘be a T-shaped person’ message from Lisa and Janet.

Also, Scrummastering is a verb now. “I did Scrummastering”. I like it.

A bit of a history lesson here. When the testers and developers weren’t sitting together in one team there were common fallacies. “The testers, they are failed devs” “The programmers, they create such silly bugs”. There wasn’t common ground to work together. But we need to feel ‘belongingness’ or we can’t work together very well. We need a way to combine our own identity with a group-feeling. 

What I’m getting from this talk is that it’s natural to search your own identity. You are a ‘tester’ and will proudly defend/explain why. But it sometimes clashes with what you want to achieve as a team. In order to get great results you need to progress from individual to team.

Unfortunately, I find my thoughts drifting away from this talk and wondering when he’s coming to the actual title of the talk. His journey is in fact very different from mine, and I cannot relate to many of his problems. Kristoffer went to try Kanban, while my team is already ‘agile in processes’. I was hoping he would provide tips on how to get your dev to test. But I don’t need yet another explanation of a scrum board and process…So, although I LOVE his enthusiasm, I cannot relate. He stopped from doing ‘everything’ to just ‘testing’. That seems healthy if you don’t want to die from stress 🙂

Break

I skipped the talk before the lunch break because I really wanted to get a new pillow. I informed at the reception and I could get a hundred of the crappy pillows if I wanted, but that wasn’t going to solve the problem. So…I decided to get a good pillow at Karstadt. Costs 50 euro, but good sleep is priceless.

When I got back the lunch was in full swing. The food was awesome as always, it’s nice that you can count on that at this conference. 

Roman Pichler – Strategy Testing, Building a Product Users want

How can you tell if you’re building the product that makes the user (&& your client) happy?  

It used to be: just do what the boss wants. He had a vision, created a plan and the minions would make it. 

That’s not what a programmer wants to do. He just wants to GO FOR IT. Build first, talk later. “Hacking your way to glory”. Yep. If only the world would work that way.

Here it is again: Start with the WHY. What is the vision, the overarching goal you’re trying to achieve?

After you’ve distilled your overall vision, you can then start making a strategy. And while you’re building, you have to pay attention to the details. Those are very important. 

Mandatory Steve Jobs quote “If you are working on something that you really care about you don’t have to be pushed. The vision pulls you”. To be honest, I can’t do anything with these types of quotes, because they aren’t pragmatic. Roman gives an example: if you’re making a health app your vision should be “help people eat more healthy” in stead of “help people monitor their food intake”.

When you have your vision, how do you know that the product you’ll be making adds value? Choose your path and show that it works. You’ll know more if you talk to the users and the customers of your product. That’ll help you relate and make better products. And even still: why the hell would they want to use your product? What is the incentive for them to interact with the product and why would they chose yours? The market is crowded, competition is fierce.

Stand out from the crowd: he gives the example of Strava as example of an app that stands out. I think Runkeeper is just a fun though. You can also compare yourself to others on there.

Before you can start building you have to test your strategy (meta-alert). Select the biggest risk, decide how to address it, collect data and make changes based on what you found.

Roman acknowledges that failure is part of the game. You won’t always make the right decision, although it’s not nice to fail. It’s a risk we always take when we’re building software.

Meta-level of this talk: extreme. Phrases like “Find an itch that’s worth scratching” don’t help me realise if the product I’m building with my team is the right thing. Also, I can ask the business WHY they want certain functionality, but I’m not in the seat of power. If they want to build something ridiculous and I’ve challenged their decision that’s about all I can do. And besides, every itch is worth scratching because it’s annoying. 

The Antimatter Principle – Bob Marshall 

Already the last keynote of the day. Time flies. I’m not attending all the sessions because I want to enjoy the company of other people as well. It’s important to take breaks and expand your network!

He starts with telling us that he has no idea what is going to tell us. It keeps getting better!

Twenty years ago everybody was having a miserable time. At a big company you generally have a miserable time, but some smaller companies also are awful. Since we spend a lot of our time at work, Bob had as a mission to improve our time at work. It should feel rewarding to work somewhere and not make you feel miserable.

Bob notes that only a few organisations actually want to be better. That shocks me actually. I think if you’re working in such a place you should run away hella fast.

Treat people how you want to be treated: golden rule

Treat other people how they want to be treated: platinum rule

Is there a next step beyond the platinum rule? 

He asked Google what the most valuable stuff on earth is, and it was antimatter.  He wanted to make the antimatter principle as simple as possible. The antimatter principle is = attend to folks’ needs.

Discussion in the audience about ‘why do we do software development?’ Our answers:

– to automate boring tasks, do calculations beyond the reach of humans, and to give people exciting new functionality (games etc)

– because we have computers 

Fear, obligation, guilt and shame to get people doing what they normally don’t want to do. Wow. Yeah….this is so true. Many times I still see that the tester gets blamed for defects found in production and as a result, a tester will be really careful and stressed about releases to production. It is this fallacy that I try to fight everyday at work and trying to get the view across that the team is responsible for the quality of the product. 

Theory X organisations: driven by management, governance, assumption that workers are lazy etc. The organisation where you have to do stuff you know is stupid, but just to keep management happy. (Very energy draining and my top reason to never work at a bank again.)

I actually stopped writing, because Bob is going FAST. He keeps making awesome points and it’s really a lot to take in. So what I’ve written here is by no means a complete summary of his talk. It really stirred something in me. I’m going to think about how I can apply this in my daily life (not just work).

Helping other people is the biggest motivator for most people! Full circle back to the antimatter principle : attend to other folks’ needs.

Quick thought: isn’t what you’re doing in Retrospectives trying to attend to peoples’ needs? You’re identifying what could go better and tackling those points one by one. It probably isn’t exactly what Bob meant, but it’s a step in the right direction.

Whew, my head is spinning. I say: Beer o-clock!