A reflection on Let’s Test 2015: Part II

Here’s the link to A reflection on Let’s Test 2015: Part I

The sessions (Part II)

Below does not include all of the sessions I went to nor all aspects of the session I mention

Visual Creativity: Using Sketchnotes and Mindmaps to aid your agile testing – Dan Ashby and Christina Ohanian

Before this session I stumbled upon Christina drawing out her sketch notes from the previous session and marvelled at how fascinating it was. Sketch notes were only something I’d only ever seen on the net. They were gorgeous and a clever way to communicate information.
When she told me that she was going to have a session on this – I was all in.We ‘warmed up’ by drawing whichever image came to mind when Dan said a word. It was interesting to see how a lot of people could interpret the same word differently. For example: “Time” could be a clock, a watch or an hourglass.

After this we got down to the nitty gritty and started drawing some sketch notes based on some requirements from Trello. It was tough – I drew a blank with quite a few words but got there in the end.

Afterwords, we tested Trello using mindmaps with the groups we were sitting in. Not only was this a great way to help us learn how to communicate information using mindmaps, it ended up being a good indicator of how useful our sketch notes were.

Exploring Web App (In)Security – Bill Matthews and Dan Billing

We learned about the THREAT model and then how to apply it. We also learned STRIDE and split up into groups to brainstorm ways we could use STRIDE to ‘attack’ the test website that Dan and Bill had created for this session. I must admit some parts of STRIDE were easier to brainstorm for than others (For me personally, information disclosure was a whole lot easier than repudiation).

I absolutely loved the hands on aspect of this session. It was great to learn about stuff that I’d often heard mentioned, like SQL injections and Tampering, but never had an opportunity to do (in a safe environment of course).

In this session we got constantly reminded about the importance of being ethical and making sure what we’re doing is legal, should we want to pursue security testing in the future. For us to flex our security-testing muscles, Bill and Dan pinpointed us to some Bug Bounty websites where, if you find some security flaws in their software, you get some compensation (etc.).

Feedback Bootcamp – Tobias Fors

In this session, we learned not only how to give feedback but also to receive feedback. I loved the fact that the lessons learned in this session could be applied in all work contexts (not just for those who work in testing).

We did a few activities to learn how to give and receive feedback – one of which was to write a Haiku as a team. Part of the activity was also to decorate the piece of paper on which we wrote the Haiku. Afterwards we were asked to give feedback to each-other and also to receive the feedback. People were also allocated the role of the observer. One interesting thing I observed was that some people have a tendency to go on a bit more than they should. When it comes to compliments, I felt it could “weaken” the compliment somewhat.

Key Takeaways

  1. Being surrounded by a bunch of people who are passionate and excited about software testing is a great way to reignite your love of testing.
  2. Having a conference with well-organised, interesting sessions was great – but it’s the conversations I had with people at meals and the friends I made that I’m most grateful for.
  3. Attending both sessions that I felt are within my comfort zone and sessions that were outside of (my comfort zone), meant I really enjoyed being challenged.
  4. I seriously recommend any testers who want to ‘rediscover’ testing and be surrounded by passionate people who also want to learn – should definitely go to Let’s Test 2016 

A reflection on Let’s Test 2015: Part I

It was my first time at Let’s Test and I absolutely loved it. My only complaint is – why does it have to be a 24 hour flight from New Zealand?!

The interesting thing was that I’ve been following on Twitter about 15 people who were at the conference so it was somewhat surreal meeting these people in real life.

This time last year, I saw a lot of noise on Twitter about how amazing it was – so I just HAD to check it out for myself.

The Keynote

We kicked off Let’s Test with a mint keynote by Ben Simo“There was not a breach, there was a blog”. Ben spoke about how initially he wanted to search for health insurance options for his granddaughter, but found himself getting a lot of media attention when he started blogging about his findings of the healthcare.gov website (after calling their contact centre got him nowhere).

One of the things I loved about his presentation was the fact he spent a fair bit of time setting up the context of the situation: Healthcare insurance in the USA, Obamacare, his desire to enrol his granddaughter in health insurance. It helped me following his presentation with a bit more insight.

Useful testing heuristics I have discovered

Thanks to Emma Armstrong and Ben Simo, I’ve discovered some very useful test heuristics which I look forward to sharing with the testing team at Vend.
Schneiderman’s 8 Golden Rules – These are some heuristics you can use to ensure the software you are testing has great interface design.
Jakob Nielsen’s 10 Usability Heuristics – Similar to above (there is some overlap).
Up until now the only ‘formal’ heuristics I had been using are the consistency heuristics I learned in the BBST Foundations course 

The sessions (Part I)

The sessions varied in length from 1 hour (which was like an experience report) to a full day workshop where you get to not only learn a concept but apply it as well. This, along with the wide variety of topics  meant I seriously thought the conference had something for everyone.

In Let’s Test conferences, people are encouraged to participate. For example: a generous amount of Q&A time is allocated to the ‘Experience Report’ sessions called Open Season.

Below does not include all of the sessions I went to nor all aspects of the sessions I mention

Equipping you for the Unexpected Challenges of Testing – Emma Armstrong

Emma’s session started with a presentation where she gave us her thoughts on the challenges testers face – one of them struck a cord with me: apathy. (e.g. People don’t raise bugs they find) It’s weird because it’s an issue that I feel can be the elephant in the room. As a tester, you’re supposed to care about the software you’re testing and put in your best effort to provide accurate information about the software being tested. But after days or even weeks of testing the same thing – that can be tough!
A useful exercise we did was the Paper Prototyping exercise. In pairs we used the (previously mentioned) heuristics to test the UI.
Why?
  • Visualisation
  • Speed
  • Feedback
  • Communication
 

Interview with Shirley Tricker

Shirley Tricker worked in a wide range of IT roles for almost 20 years before starting Elementum, a business that helps people in IT to develop skills, attitudes and habits to be productive and happy in tech roles. Shirley is active in the testing community as an organizer of the Auckland chapter of WeTest, an attendee at the KWST peer conference, and she runs the Auckland Testers Facebook page.She is also co-organiser of the Women in Tech Auckland meetup and she speaks to students via the ICT-Connect programme, which inspires and educates young people about a future in IT. She recently started blogging where she advocates for people to take back control of their careers and work happiness.

 
You’ve been an amazing mentor to not just me, but other people I have worked with. What do you find most rewarding about being a mentor?
I get huge satisfaction from seeing people achieve things they weren’t sure they could, and from helping people to do more of what makes them happy. It’s most rewarding when I see people take what they’ve learnt and help others to do the same.
 
 
And what do you find most challenging about being a mentor?
It’s challenging for me when it’s clear that the person I’m working with has valuable skills and attributes but they don’t see them. When people underestimate themselves I need to find other ways for them to understand their value so that they feel ready to take the steps needed to move towards what they want. I work with some really good people and many of them feel like imposters, so if any of your readers feel like that I’d say that’s a sign that perhaps they’re more talented and capable than they think.
 
What are some of the hardest decisions that testers face in their careers and how do you help them arrive at a decision?
The situation I come across often is testers feeling unfulfilled at work but not knowing if it’s better to stay on in their current company or move somewhere new and uncertain. To help them I try to get to the root of what it is they really want at work and in their life. This will depend on many things including their circumstances and stage of life as well as their skills and experiences and what makes them fulfilled at work and in their personal lives.
We assess if their current company can offer them what they want and if so what steps they need to take to make that happen. People often have more options than they think to improve their situation at their current employer.
If it makes more sense to move to a new company, I make sure they are clear about the value they offer to potential employers and we work together to plan a targeted job search.
What’s one issue you think a lot of testers face, but they don’t realise they’re not alone in this?
In my experience many testers feel at the mercy of poor practices in their workplace but they don’t think they have the power to change things. Maybe they’ve been told that it’s not possible to change, maybe they’re not confident standing up for themselves, or maybe they’re unsure what options they have.
My advice is to avoid merely pointing out what’s wrong. First, aim to understand the issues that contribute to these practices. Having understanding and empathy for other people’s constraints will make discussions about the impacts much friendlier and more useful. If one person feels frustrated it’s likely others do too so find them and work together to think of alternatives. Testers can also research better ways of interacting with the people they need to influence, as well as looking into how other people have made positive changes within their companies.
Testers are ideally placed to help companies to improve, but to do that they need to speak up and work together.
 
In your current role, you help develop people’s soft skills – which soft skills, do you believe, are the most important to develop and why?
Soft skills wrap around our technical skills and help us be effective in our jobs. They affect how we’re perceived and our ability to influence others. They’re called ‘soft’ but they can be quite hard to improve.
Communication is often mentioned as a critical soft skill, and I agree that it’s important that people learn how to present their ideas, listen and write. Since we hear a lot about communication, here are a few other soft skills that I see becoming more and more important.
Collaboration. This involves finding common ground with others, and working together as equal partners. Communication is obviously important for collaboration, but so is respect for the needs and contributions of others, and a willingness to share information and help whenever possible. Being able to collaborate is key in the lean and more iterative software development approaches.
Taking ownership. This is a great skill to develop if you want to be a leader (and there never seem to be enough strong leaders).
Taking ownership means you do things the best you can. We aren’t able to control everything at work, but taking ownership is an attitude and it’s entirely in our control. Be accountable to yourself and your team. Be enthusiastic. Be someone who steps up and takes responsibility. By taking ownership you’ll be more effective and people will be more likely to trust and respect you.

For more interviews, go here.