4 Tips for Working Remotely

I’ve been mainly working remotely for the past month and did a bit of remote working before Christmas. I sure can’t complain about the lack of commute, but it definitely takes some getting used to. Here are 4 things I have learned that help make working remotely a bit easier.

1. Add some sort of structure to your day

I do this by going to the gym at lunch (it’s a very short walk). This means I have a “morning slot” and an “afternoon slot” in which to do things.

2. Find a tool to help you be productive

For me, this has been something as simple as a to-do list each morning/week. I write it by hand and draw little boxes beside each one, then tick it off as it’s done. I’ve tried online Note tools etc. But they don’t work for me nowhere near as well as handwritten to-do lists.

3. Communicate with your team

We do the standard “good mornings” but I also do my best to let them know when I won’t be available (e.g. going to the gym). I don’t actually tell everyone in my team I’m going to the gym, but only those I’m directly working with. I don’t want them messaging me and having them wonder where I am.

4. Move your body

This might sound a bit strange – but I like to stand up, have a break and either go for a 10min walk around the block (weather dependent), dance to a song (this one is my favourite) or do some lunges etc. I figured people who work in an office get to move around a much bigger space than me – and sitting still all day can make me somewhat lethargic so I need to get a bit of blood pumping.

What’s the purpose of Test Documentation?

Last week I went to a testing meet-up where one of the presenters said that he used documentation to defend himself – which really caught my attention. But it also got me thinking.

While Test Documentation may be used to defend yourself, surely that is not its purpose.

Why do you write Test Documentation?

Chances are, something along the lines of, “to communicate information” comes to mind.

But what does “communication” really mean?

I think phrases like “strong communication skills” etc are thrown around and misused. According to Meriam-Webster, the definition of communication is:

“It is the art or process of using words, sounds, signs or behaviours to express or exchange information….”

Scrolling down the page I saw a further definition: “Information transmitted or conveyed”

I proceeded to click on the hyperlink that gave me the definition of convey “to make (something) to known to someone”

We use Test Documentation to make information of the software known to someone. 

BUT providing test documentation and making information known to someone are NOT the same thing. 

Which leads me to….

Who is your audience?

When I think I about Test Documentation the most important thing is who will be reading this. My approach towards Test Documentation relies heavily on who will be reading the information.

This usually boils down to three categories:

My future self
This is the easiest audience for me to write test documentation for, because chances are, I don’t need to worry about misinterpretation. I write test documentation for my future self when I am testing a feature which may take more than a day – I need this information so that I can look back at it and see what I have already done and how things went.

Technical people such as developers
This either happens when I’m testing a feature or retesting a bug. To this audience, I make an effort to provide detailed information on the links clicked, usernames, database tables and information you can find with the console open.

Business users such as Project or Product Managers
Providing test documentation for this audience is based on the assumption that they are in charge of deciding whether something is ready to go-live and when that is. Here, I make an effort to say what users of the software can and cannot do at its current state.

Above I state what my focus is for each audience. That’s not to say I wont provide technical information to the Business Users or that I wont tell Technical People what the users currently can and cannot do.


One final note: What you write and what is read may not be the same thing

You may provide results of test cases or a mind-map which shows the current state of the software and in your opinion, it shows things are looking pretty bad. But the reader may think otherwise.

Strictly speaking, this might not be a matter of opinion but a reflection of how well a job you are doing as a tester.

When you write test documentation you should ask yourself, “how can I ensure that the reader understands what I am communicating”.


Software Testing is not for Attention Seekers

Software Testing is not for Attention Seekers.

What a bold statement!

Let me explain.

As a broad generalisation, I feel that testing is only noticed when someone (the tester) has messed up. A few months ago I had a pretty open conversation with a workmate on how they felt unappreciated and undervalued. After all, when code goes into production and all goes well – usually one doesn’t applaud the tester for finding all of the bugs and helping improve the software quality by communicating information about it (before going live).

I really could relate to my workmate as I recall many times where my input into a project seemed to be forgotten or ignored. Some code would go live, which I tested vigorously, and then only the developer would be mentioned. This happened in both team-wide forums and tools you could use to give “kudos” to someone.

It’s a bit weird being in a profession where the metric on which you base my success is probably going to be you not realising the role of a tester exists.

To elaborate:
Let’s say you’re buying airline tickets online. You first select your Departure City by entering three or more characters, then selecting your city based from the dropdown list that subsequently appears. Afterwards you go to the Arrival City field and do the same thing.
There are two (of many) ways this could possibly pan out.

  1. The Arrival city field dropdown is only populated with cities to which you can fly from the Departure City. You then continue to select dates and make a purchase. (You probably don’t even think in one step of the process of a tester\’s role in this).
  2. The Arrival City field dropdown list is populated with every city (including ones you cannot fly to from your Departure City), you select one of the ‘unsupported’ cities and get an error on the next page. Something only these lines crossed your mind: “Who tested this? Why didn’t they think of this?”

The Girl Who Cried Wolf – Picking Your Battles

After my Google Hangout Interview with Katrina, I started to think about picking your battles – which she listed as an important quality of a tester. Below I’d like to talk about my experience and thoughts on this idea.

The Girl Who Cried Wolf

When I started my first (ever) project, my understanding was that the purpose of testing was to provide information with more emphasis placed on advocating for the fixing of bugs.
The thing is – I took this too far.
Part of me relished raising bugs in the Test Tool and assigning a severity and priority. The sad thing is, I thought I was a better tester when I raised bugs with a higher severity and priority. This meant I probably assigned a higher severity or priority to bugs than they actually deserved.
I’d see spelling and grammar mistakes and would make a massive deal out of it. It took a while for me to learn that my opinion mattered but wasn’t actually as important as I thought it was at the time. Looking back, I didn’t try to see if the spelling and grammar mistakes could change the meaning of text – I merely marked it as wrong. If I were to come across this situation now, I would consider the impact of meaning on whether I were to assign a higher severity/priority. (For example: Would the bad grammar lead the user to commit an error?)
Unfortunately, this led to a “boy who cried wolf” situation. I found it more difficult to get my bugs fixed partially because of the fact I placed too much importance on bugs that didn’t actually matter (and partially because of factors out of my control).

Why should you pick your battles?

  • To not cause the testing profession to be seen as a a blocker of the SDLC
  • To avoid a “boy who cried wolf” situation
  • To ensure we (as testers) are seen as adding value to a team and not hindering the team

How can you pick your battles?

Here are a few questions you could ask yourself when advocating for a bug
  • Why do I want this bug to be fixed?
  • What’s the worse thing that could happen if the software went live with the bug in it?
  • What’s the risk of the bug being discovered in production?
  • Have I made a reasonable effort to see things from the other person’s point of view (if someone is saying the bug does not need to be fixed)?
  • Looking back, are there bugs I insisted on being fixed, that were in fact not that important? (this may affect the current perception by the team)
  • Have I asked the opinion of someone (honest, who won’t just blindingly agree with me) about the bug and presented the bug in an objective manner?

Google Hangout Interview with Katrina Clokie

Spent half an hour talking to Katrina about software testing.

Questions include:

  • How did you get into Context Driven Testing?
  • Why do you speak at conferences?
  • What advice would you give to someone who is in the first year of their testing career?
  • What is your biggest achievement of your testing career?
  • What’s the best thing about coaching a team of testers?
  • And what’s the most difficult?
  • What made you decide to start blogging about testing?
  • What do you wish more people knew about software testing?
  • Do you see a problem in the gender ratio in testing?
  • If so, why? If not, why not? If so, how do you suggest we address this?
  • What, do you believe, are the 3 most important traits in a tester?
  • Do you think it’s possible to be a CDT but not Agile? vice versa?
  • I am the only tester in an agile organisation with only developers and POs. How do I get mentored, because most people here do not understand testing.

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.
  • 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.

Bug Advocacy Part II

Last Tuesday, I gave my Experience Report on Bug Advocacy at the latest WeTest Auckland Meetup. It was a bit daunting – not that the audience had menacing expressions on their faces or anything, but I tend to do a little freak out before I speak in front of people. Something that I need to work on.

Here is the link to my Prezi.

Below is a reflection on the Bug Advocacy Meetup we had last Tuesday.

A bit of background information about my experience: I’ve never been on an Agile project. Neither have I been brought into a project early in the SDLC. By the time I’ve come on to projects, the software has already been built. This meant that some people questioned why I don’t just talk to the developer and get the bug fixed? Or why don’t I just write it on a post-it note and stick it up on their computer? While I agree that these are great ideas, I’ve been on projects where things have to be tracked in a Testing tool.

I learned a lot from the discussions that followed my experience report. Namely, how people deal with bugs when they are on ‘less traditional’ projects. I also found it interesting to see that people seem to be just as passionate about functional bugs as they are about usability bugs; arguing that the usability bugs make the software ‘unprofessional’. 

After my Experience Report, I prepared an activity which involved finding bugs in an Advanced Driving School website, using another Advanced Driving School website as a heuristic. These usability issues included:

  • The fact that the first website’s homepage was too long.
  • You cannot easily identify the menu
  • The fonts and colours constantly change
  • Some fonts are unreadable.
  • The visitors’ count should be replaced by a conversion counter for it to be more meaningful.
I then played Devil’s Advocate and argued back why one shouldn’t have to fix the above issues. That really riled them up.
They explained to me why these bugs should be fixed and how some of them would be a quick fix. So given the impact of the issue, and how relatively easy it would be to fix – some of these bugs really weren’t worth arguing about.

Here are a few things that people agreed on that makes a good bug report:

  • Write a useful Summary/Title
  • Include steps to replicate. There was a developer in the room and he said it really helps.
  • Attach logs if you can. A developer should be able to tell you how/where to find/record these logs.

Here are a few things that people agreed helps you advocate for bugs:

  • Respect people’s time – if they look really busy, maybe come back later or gather a few questions before you approach them (instead of interrupting them every two minutes)
  • Create a warm, happy environment. Some Testers say they have friendly bets with developers – the losers get cake for the team. Remember, we are all in the same team.

Here’s a link to Bug Advocacy Part I

Interview with Kim Engel

Kim Engel is a software test manager focused on user experience and fostering communication between stakeholders.
She is a regular attendee of the OZWST peer conference, an avid reader and occasional writer of testing blogs, and an infrequent tweeter @kengel100.
Kim is in the process of overcoming 10+ years of traditional testing experience to adopt a Context Driven approach to Testing.

What was the hardest part about the transition from a traditional Test Manager to a Context Driven Test Manager?

Continue reading “Interview with Kim Engel”