Posted on by

#WeTest2018 Liveblog Experiment

Today, #WeTest2018 arrived in Auckland and we get to enjoy the fabulous WeTest conference again after a fabulous day in Wellington on Tuesday. During the first edition, I sketchnoted all the talks except my own. Today, I’m experimenting with something different. Depending with how my energies hold up, I’ll take more traditional notes on the talks and publish them here unedited.

Richard Bradshaw @FriendlyTester – Redefining Test Automation

Richard shares his journey from a focus on test automation and building automation frameworks to the creation of Automation in Testing, coined together with Mark Winteringham. He poses the question: what does test automation mean to you? After a few moments silence, he goes on to pose the answers tool vendors, companies and certifications have given in the past. Richard is unsatisfied with these definitions as they lack a focus on what the problems are people are trying to solve. Richard advocates an approach that is less tool- or language centric, and focuses on where the risk are, what the problems are and puts testers in the centre.

Automation in Testing is a mindset and namespace that promotes a human-centric approach within the context of testing. AiT focuses on strategy, create, usage, education of valuable automation that truly supports our testing activities.

Automation in Testing values:

Supporting testing               over                Replicating testing

Testability                              over                Automatability

Testing expertise                 over                Coding expertise

Problems                               before             Tools

Focus on risk                         over                Coverage

Observability                         over                Understanding

So, how do we spot automation opportunities? Repetition, shadowing, ‘oh, this again’, time, multiple steps.

Story time: working on a project. “For two weeks, I’ll observe you.” And Richard did. For two weeks, he quite literally sat behind his colleague and observed his work. It might seem counterintuitive but it was a great way to spend time. Over the course of the two weeks, Richard spotted crazy amounts of opportunities to help him. 60% of the time was spent on data creation, so we automated that (in an ugly-through-the-UI-fashion) and then we automated the installation on various devices. In the end, we had done no traditional test automation, yet cut down the time for these tests from two week to 2 days.

We have an immense toolbox as testers and coders. For the first part of the years of Richard’s career, he focused almost exclusively on one language. This gave him work, but lacks flexibility and growth. When you have a hammer, every problem starts to look like a nail. Nowadays, Richard encourages you to expand your toolbox. Expose yourself.

There is this notion we can automate all our regression testing. It’s flawed. It stems from the idea that we have a fixed knowledge and we can automate that knowledge. Yet, we end up with gaps because the system cannot reeducate itself. Also: our knowledge evolves. But because the checks turn green, we are unlikely to reexamine the continued validity of the checks. Also, we have way too many end-to-end checks which adds unnecessary complexity.

Mnemonics:

TRIMS –

Targeted,
Reliable,
Informative,
Maintainable,
Speed

SACRED –

State Management,
Algorithm,
Codified Oracle,
Reporting,
Execution,
Deterministic

If we implement the principles underlying these mnemonics, we create small rapid feedback cycles. And then finally, the most important bit about this talk: we need to educate people. What is possible with automation? What is testing? Share knowledge, get them on board easier. We need to break the false-pattern that we can automate all testers away. Richard wants you to stay on track: focus on what the problems are. Examine the situation and then pick your tools and languages from your toolbox, and solve the problems. Stay on track.

As Adam mentioned with the superpowers, let automation elevate YOU. You are the one who can put all the information in the context. The tools support our jobs.

Jackie Wang  @JackieWang7 – A Change of Mindset: Testing in a Dual Track Agile Environment

What is dual-track-agile. It is a term coined by Jeff Patton.

Dual Track Development is not Duel Track

Two different words: discovery & delivery.

Discovery: build RIGHT things

Delivery: build things RIGHT

Dual track development is not dual track. The two different words are not in contract or conflict with one another. Instead, they function as two tracks of the rails.

When Jackie started preparing for this presentation, she interviewed a large number of people. She asked them a series of questions. What is your background; why did you choose to become a tester? Have you heard about Dual Track Agile before? Etc. She met a technical automation engineer who had never heard the term Dual Track Agile before.

What is the value? In New Zealand, a large amount of companies started the transition to Agile in recent years. Dual Track Agile allows you to focus on building the right thing as well as building it right. Why does this focus matter?

Most of startups fail. Why? Look at Melissa Perri’s concept of: The Build Trap (https://melissaperri.com/talks). There are a lot of products created that fail because they have problems such as: people do not WANT to use them. They don’t solve the right problems, or have poor user experience or value. This applies to small startups as well as large companies.

Things to consider (to help you find your place in discovery work and not just in delivery work).

“I don’t know” – it takes courage and a growth mindset to say this. “I don’t know, but I hope to find out someday”. It also triggers imposters syndrome for a large group of people.

Validate your assumptions. When we create software, we make a lot of assumptions. We need to validate these assumptions. Talk to a customer. Gather some data. Prototype something. Put it in production. The key idea: validate your assumption before you build anything.

Start with empathy. Why? We might work behind computers in open floor spaces, our customers might be working on a large farm, factory, remotely from home, caring for their children, spouse and family, deal with a large amount of distractions. So: build empathy with your customers by talking with them. Prepare this carefully. When you ask closed questions, they often don’t get to actually share their experiences, context, problems. It’s already your interpretation. Additionally, closed questions imply a right-wrong answer. Open questions break open the conversation. It is not the customers’ role to figure out what they want. It’s our job to figure that out

It is the outcome that matters Output is what we produce, release, and often celebrate with cakes. Yet it is the outcome to the customer, the value it delivers to them, that truly matters.

Start with what interests you “If you always do what interests you, at least one person is pleased” – Katharine Hepburn

Think big, start small

Write down what you want to learn about discovery, and talk to people who have the experience. Practice how to write an assumption. Talk to the user research specialist. Write down the outcome of your current project. Remember to timebox it & take notes what works for you.

Discovery and delivery compliment each other. Both are essential and feed each other like in a loop. It is ultimately the outcome that matters for the customers.

Morris Nye @mossnz – Test Reporting in the Hallway

Context: I’ve always worked for companies that develop software for other businesses, with a software as a service model. Additionally, I work in continuous integration and continuous delivery model.

So, let’s move onto reporting? When do we report about our testing? When something has changed – that is relevant to a stakeholder’s interest. That can be on a small thing that has an impact or the half-yearly release that’s about to go out.

That’s when we report, but how do we report? The medium is the message in a lot of ways. There’s the informal bumping into someone the hallway, sent a slack message, an email, a written report. Each mode has a place to play. The message you get across using the different modes changes according to the medium.

Yet, when we report: there are several categories of the type of messages we can communicate.

V State clearly the working capabilities of the software under test

V Celebrate the achievements of the testing & development team

+ Provide information and concise examples

– Note any differences of deviations from initial plans

X Raise key areas of concern

Put the summary at the FRONT of your report. This is the key elements that stakeholders are interested in. It might feel logically to WRITE it last, but have your stakeholders READ it FIRST.

The icons & colours help communicate. The prevalence of colourblindness among the population means that just using colour is not sufficient.

Have your own personal notes that you don’t worry about being part of a permanent record.

Read feminist philosophy over business philosophy when it comes to communicating with people in positions in power.

Childhood story around Fences. For the sake of simplicity of a fence or a gate across a moat. A story of someone who wants to remove it: “If you don’t see the use of it, I won’t let you clear it away. When you understand the use of it, I may allow you to destroy it.” Our existing processes work the same way. It is important to understand why the fences are there before we try to clear them away.

When I started adopting this, I found that reporting about the process is just as important as the artifacts that I’m putting out. Communicating clearly about my process allows decision makers and stakeholders understand the value and the concerns. When you report, restate any planned functionality that is part of the working software so that people can check if their mental model of the application matches up with your model. Use your own words to do so and don’t use words like “luckily, we found this” as it is not luck but skill and therefore it is important not to undercut your skills. Highlight your team members contribution by name – give credit where credit is due.

“As uncertainty increases, the amount of information that must be processed by decision makers increases” – Jay R. Galbraith (Organisation Design: An Information Processing View). What information is valuable? What does information tell us? What kind of data actually provides us information? (Hint: piecharts or counts of passed/failed test cases are useless.)

Morris’s oracle for raising concerns: it is a concern when escalating it would help. Morris asks himself: is it going to surprise or disappoint my stakeholder? Use different modes of communication throughout. The final report delivered to a stakeholder should not come as a massive surprise. If there is, there is a problem earlier in the communication.

“When you expose a problem, you pose a problem. I have been thinking more about the problem of how you become the problem cause you notice the problem” – Sara Ahmed (look at this quote in the context of diversity and inclusion in which the original blogpost is written).

Feminist philosophy is very practical in terms of communicating around power.

Morris highly recommends the following books:

‘Living a Feminist Life’ by Sara Ahmed

‘Feminism is for everybody’

Mrinal Mukherjee @mukherjee_mk – Compliance is dead. Long live compliance

Mrinal works in infrastructure security compliance. Mrinal tells a story of a development team that is confronted with a compliance issue. They change their process to add an extra step of security review in there. Their compliance officer is kind and helpful and helps the team. We get a whole checklist for the security review & fix all those issues, and our application promptly falls over which obviously leads to delay and frustration. The traditional way of compliance is dead. It is slow, disrupts flow, causes conflict. Yet compliance is essential. It is here to stay. Only look at the security breaches at prominent companies lately to look just at how essential it is. You cannot test in quality, you have to build it in from the start. Mrinal shows a model for Continuous Compliance, where we agree on the standards together and all take responsibility for this.

Anish Prasannan – That doesn’t look right!

Anish demonstrates a visual regression tool. He shows us two images that are subtlety different – can we spot the differences? As an audience, (those who are close to the screen) can see some slight things that seem a bit odd. The tool Anish demonstrates can highlight the exact differences on a pixel level.

When they were automating their toolkit they choose the fun way and had testing on the table from day one. They integrated testing in their project from the start. They are now able to release 2-3 times a week with ease and confidence. He shows some code snippets on how it works. They trust their master branch to be their source of truth, their baseline against which to compare. They store the results of the comparison in PNG as that does not loses any pixels. Anish shows a couple of other things the tool can do. Go see him in the break!

Allen Geer & Amanda Baker – Continuous testing govt.nz with Specification by Example and Behat

Allen & Amanda share their story of moving to Specification by Example and changing their workflow. They share their challenges: sites are out of date; we have a lot of customization; no automated testing or strategy in place; etc.

They started their transformation by mapping their existing workflow. They wished to involve their whole team and started with Specification by Example and 3 amigos. By moving to test driven development and involving the whole team in quality, we were building quality into the process a lot more. The SbE stories were written in Gherkin and the whole team then writes the test automation when the user story is written. We envisioned a goal where we wanted to be able to rely on a suite of unit & behavior tests for every commit.

Ultimately, it was a three step journey:

  1. We were able to visualize a lot of metrics, technical debt, coverage, to foster an attitude to improvements
  2. Determine high risk features and focus on those first. How important is it to the product? And be aware when you spent more time than you save.
  3. Wrote all feature tests in Gherkin in syntax. Which then was the living documentation for the team.

Marianne Duijst @marianneduijst – Wearing Hermione’s Hat: Narratology for Testers

I’m excited to go back on stage! Being on stage & sketchnoting & liveblogging about my own talk is rather hard to combine though, but based on the fabulous response of people in the audience in the break after, people loved it.

 

 

Dan Barrow @TesterWatchful & James Espie @JamesEspie – Avoiding cataclysm as a change catalyst

We often look for others to take the lead. But that doesn’t really work. That’s not to say management or leadership doesn’t care, but they are dealing with different circumstances.

James:

Meet Nigel. My coworker. He won’t be offended if I say that I prefer to spend my time with my wife & child. So, let’s do the math.

Nigel: 6h a day for 5 days a week: 30h a week

Wife & child: 3h a day for 3 weekdays & 10h on weekend days: 29h a week.

My first response, many years ago, was frustration. Antagonizing my coworkers as they were the reason I wasn’t spending time at home. In frustration, I would not socialize with my coworkers. A lovely colleague at the time sent me a request on myspace (this was years ago) and I rejected it. She called me out on it. I was like: ‘yeah… I don’t socialize with coworkers.’ She responded very kindly: ‘well… you should.”

Upon observation, we did exactly the same job, but she was a lot happier than I was. She was happy and friends with the people she worked with. It’s difficult as you have to make the time & space to make relationships grow and find things in common.

You and me and all of us could be team lunch organizers! Here are my six tips for a great team lunch!

  • Invite everyone, even if they are only ‘partly’ in your team. When in doubt, invite! (Risk of not inviting someone & how they feel if they are not invited versus the reward of inviting someone new).
  • Invite the boss (sometimes) (It adds a different dynamic to a team. You feel like you are always ‘on’. Fortunately, this is problem that often solves itself as they are often too busy to join, so invite them & they’ll show occasionally.
  • If you are going out: book a table! Not sure how many to book for? Try this handy formula:

‘Yeses’ + (‘maybe’/2) = number of people to book for

  • Know your team’s dietary needs
  • Don’t talk (only) about work! Family, travel, Netflix are all good subjects
  • Two ears, one mouth – remember to listen

Dan:

Joined a new company and team. I was expected to continue the testing as it had always been done before. “Why have you not caught this?” The feature was only introduced late in the process, as I had pushed back and indicated that I would not have enough time. But it was highly critical and was pushed through and failed to the extend we missed a compliancy deadline. I was very unhappy with this as not only had I been pushed to do work I was unsatisfied with & now I was blamed for it.

So, I decided to change it. I sat down and crafted a new process & upon implementation, we found that we had two releases that had no hot patches. We celebrated! Higher management was happy: more predictability. Yet, the team dynamics started to suffer. We had made one huge error: we had pushed this on the team & told them this would be the new process, rather than have

There is a big difference between acting with authority and acting on change. I really believe if we had involved the whole team more, we would have done a better job all-round. We would have had a better process and would have had better team dynamic.

I resolved to do things better next time:

I wanted to be more open & to encourage others to do the same.

Learn to tweak things, rather than throw the baby out with the bathwater.

Collaborate.

I ended up playing Streetfighter with someone I’d never met before. I learned a few things about him. I learned his name was Marc. He worked in payroll. He lived closeby the office. Had been with the company about 18 months. For the next few months, if we met in the hallway, we’d greet each other. In the meantime, we would have to integrate with project X. Our next integration would be with payroll. “Aha! I know someone in payroll, I ask him about it”. So, the Streetfighter tournament had an impact that I had not anticipated. It doesn’t always work, yet it’s important to have some fun together with your colleagues at work.

There are some challenges with organizing such a tournament (the biggest challenge is having the courage to do it).

“Be the change  you want to see in the world” – Gandhi

“See a need, take the lead” – Chris Heaslip and others

A few final thoughts:

People come first: Put the human you work alongside first, learn and include their perspectives

Take a risk, get a win: Try out new things, start with small tweaks and be humble enough to change or backtrack

Learn from your mistakes

Dan & James are @supertestingbro on twitter.

Panel Discussion – Building Super Testers

http://sli.do/WeTestAKL

Let’s build our Super Hero Testers! Pick & choose live & explain your choices!

Richard: Facilitation | Modeling & Visualisation | Identifying Assumptions | Offering feedback

Mel: Adventurous | Storytelling | Agility | Research

Em: Communication | Bravery | Patience | Vulnerability

Audience: Curiosity | Empathy | Analytical Skills | Keen Learner

Mel Eaden @melthetester & Em Preston @empreston96 – Ready, Testers? Let’s Go Back to the Future!

Choose your own adventure!

Everyone has to start somewhere, so let’s start at level one!

Level One: Starting Out & Asking for Help

Asking for help is OK

Receiving help is OK

Challenges & Change is Normal

Em shares her story about being afraid of needles. She would faint. As a child, she’d take her mother with me and later a friend. Lately, she had to do a number of blood tests. So, this time… she told the nurse that she was afraid of needles and that she’d always faint without really understanding it. The nurse was accepting. She talked her through it and started counting down. On three, she stopped and said: “You’re holding your breath.” This was surprising and true. The anxiety literally made me forget to breathe.

Level Two: Growing a Career

Don’t Be Afraid to Add Your Voice

Don’t Let Imposter Syndrome Get Stop You

Every person needs a champion: Help Others Believe in Themselves

Mel jumped at the opportunity to attend TestBash in New York when she saw that Richard Bradshaw offered multiple tickets and to win it, you had to write an essay. This was a lifechanging opportunity. She wrote her essay and managed to win the ticket, and it propelled her into joining twitter and slack, engage with the global testing community and kickstarted her into massive new opportunities with her career. It starts with a small step, and can propel you into so much more.

Level Three: Bringing Folks Along for The Ride

Remember What It’s Like to be New

Seek to Understand Before Being Understood

Growing As a Learner

Growing As a Mentor

This talk is a joined talk between Em & Mel. They only met on Tuesday morning in person, and are on stage together on Tuesday & Thursday. Through the power of global communication, Mel mentored Em on public speaking. From the US to New Zealand, they jointly created the talk and inspired each other. Seek out your own mentors & mentor others. All our journeys are unique, and therefore, even when you are relatively new, you have something to offer to others. Grow together both as learners and mentors & reach out. Add your voices.

Selena Delesie –

Selena is a leadership and transformation coach and also runs a podcast Lead with Love.

At 9/11, BlackBerry was the only cellphone that worked several stories under the rubble and BlackBerry brand took off after that. We were growing rapidly. I moved from being a Tester to leading a team of 20 high school & university students. I liked being a tester. I liked being the one who found the problems. I wanted to be the lone hero who found the issues. It took me a while to realize that in order to grow our organization and do my job well, I needed to focus on the whole team. The future of organizations is the growth of the people in them. I had to learn to believe in other people. To believe other people had the skills and capabilities to figure it out like I did. “I trust you” We hire people because we believe they have something to bring. When we switch that mindset to believing & trusting… the potential for growth is immense.

At one company, we were working 60+hours a week. Lots of overtime & stress. I was OK with this for me, but not for the people I was managing when I saw that their smiles were going away. So, I started to push back. Imagine you have a 100$ and are in a store: you have to prioritize as you cannot buy all you want. It took a while for people to come around but we were persistent. This lead to a much higher focus and better team balances. People were happy again.

When creating teams, it is important to hire people who are UNLIKE yourself and the dominant culture. It’s more than diversity, it’s complimentary: people fitting together from different backgrounds & with different skillsets. They were brilliant together.

Be careful that you don’t attempt to maximize your effectiveness, as it is the ‘slack’ time in which you process and reflect. This allows you to solve things in the back of your head. It leads to ingenious solutions and creative ways to solve problems that we don’t know could be solved. It’s important to give time & space.

Focus on happiness at work. Build a cohesive team together that can succeed together. Bring your unique skills and joys and happiness together to all be superheroes together.

 

Thank you #WeTest for flying me to New Zealand and being so incredibly welcoming. I enjoyed making my sketchnotes & experimenting with liveblogging throughout the two days.

Published by Marianne Duijst

3 Replies to “#WeTest2018 Liveblog Experiment”

  1. Dear Marianne – Thanks for this wonderful post, and even more for your Amazing sketches!
    As this is an “Experiment” I will take the liberty to add a small feedback:
    Please consider adding at least one of the sketches as a normal picture rather in addition to its twitter link within the post – in order to enable Facebook and other social networks to automatically gather it while we share the link to the post.
    This way it will become more viral by having an Eye-catching photo of one of your wonderful sketches.
    Thanks
    @halperinko – Kobi Halperin

    Reply

    1. Dear Kobi, thank you for reaching out & commenting. I indeed forgot to set a featured image for this post. Hopefully fixed it now and otherwise I’ll pick it up later. -Marianne

      Reply
  2. Pingback: Take a look at Jigs - October 21 to 27, 2018 - LaunchApp

Leave a Reply to Marianne Duijst Cancel reply

Your email address will not be published. Required fields are marked *