'Exploring': my first testing experience

Michael Bolton wrote a piece in response to my previous blog post, 'Software Testing: I don't just 'break stuff'.'' You can find his post here -  'What Is A Tester?' (Developsense Blog, 25 June 2015).

His blog post has given me a lot to think about. I know now when I'm next faced with the question: "So you just break stuff all day, eh?" I'll be thinking about using those metaphors - I'm a research scientist, an explorer, a social scientist, a tool user, a critic and an investigative reporter.

But today, I'd really like to focus on the explorer metaphor.

Bolton writes: "I start with a fuzzy idea of the product, and a large empty notebook. I treat the product as a set of territories to be investigated, a country or city or landscape to learn about."

Thinking back to my first testing experience, I could safely say that Dora the Explorer would have put me to shame. I was nervous on my first client site, people spoke a lot of 'tech' with their superior domain knowledge and I'm ashamed to admit it - but despite being taught some great techniques from respected, experienced testers - I was tentative in my exploration of the large and complex system.

First day nerves definitely got to me. And it actually extended out into a week or two before I really settled into the groove of things.

One of the biggest traps I fell into as a newbie was feeling overwhelmed at how much I didn't know. Once I finally felt like I understood something, I would get tunnel vision by focusing on that tiny fragment of the system.

Put simply, I needed to think about my testing in context. I was focusing on understanding my findings but not seeing how my piece of testing sat within the whole.

I found myself thinking back to my favourite childhood picture book - Zoom, by Istvan Banyai.

Credit: Zoom, Istvan Banyai

Banyai's illustrations reminded me as a fresh tester not to think about my testing solely as the picture on the top left. My area of test was a part of a complex software system that runs through a number of processes on a cyclical basis. 

Some thoughts that were triggered by thinking about Zoom: 

• Where does my testing sit relative to the project? How does it link to what the rest of my team are testing?
• How does this piece of functionality tie into the cycle as a whole? What other related areas should I explore?
• What are the consequences of this not working - what would the flow on effects be to the end user?
• 'Zooming in' to what I'm testing - have I missed any key details out?

Now that I'm a little further along from my 'first experiences' as a tester, I've re-evaluated and come up with more questions to think about:

• Zoom is merely a 2D graphic, can we consider the entire system from a different perspective?
• What kind of value is my testing adding to the whole?
• Can I take a few more steps back and approach my testing from another angle - and in doing so, will I potentially cover off multiple areas of concern, thus making my testing more effective?

These thoughts may be amateur - but I would have never thought that a picture book I enjoyed as a primary school student would have such a lasting impact on me, especially on my career. In a weird way, the book has helped me become a better tester, a better explorer.

Software testing: I don't just "break stuff"

In the past year I've had extremely interesting (and often amusing) conversations with people who have a lot of questions about my day job.

Here are a couple of classics...

Friends and peers: 

The most common type of conversation I've had. I'm talking about the young professional, the fresh graduate who doesn't work in the IT industry, but who understands software (well at least the software they use in their finance/insurance/banking/medical jobs) and who also understands basic IT concepts.

"Oh, so you just break stuff all day, eh?"

Or, along the same lines...

"So... do you just think about stupid stuff that a user might try and do, and then try and see whether the system lets you do it?'

Ahhh, if only it were so simple. I'll admit that I wasn't the best at describing a software tester's job. I think this is because our roles as testers change so often, depending on the type of project, team or environment. No two days are the same, well at least not for me anyway. So it was really hard for me to explain what I do on a day-to-day basis.

So now when I talk to friends, I'll talk about how software testers can work together with businesses to build quality into the software development life cycle, which means ultimately delivering better software. And while it does involve trying to "break stuff" sometimes, that's definitely not the only thing we do.

I'm not entirely sure they're convinced though.

My mum

...who is the cutest. Technology is definitely not her forte.

"You work in IT now, so you can fix my phone? Can you tell me why my app won't open? How does this anti-virus thing work?"

Uhm...no, I can't. But Google can help.

My mum's best friend

...who is a grandmother. She got her first smartphone last year.

"So, do you make apps?"

I don't code. I'm trying to dabble in basic coding, but I don't know how to code at all. This didn't seem to sit well with her, so after several attempts I finally got her to understand software testing by using a very loose analogy about building houses. So 'the business' (or the person who wants the app) is sort of the equivalent of the home owner, and a little bit like the designer/architect; a developer is the builder, and a tester is the building inspector. And we're all trying to build a software 'house'. A bit crude, but she got the gist of it.

But I also mentioned how in an ideal world we'd all be working together from the start, and I'd be able to point out the flaws in the architect's plans before the building got started. :)

Kids 

I did a presentation to a local school about my job not too long ago. Thankfully they had just been talking about critical thinking at school, so I could talk about how my job is all about critical thinking and problem solving.

"So, can you be a video games tester? Is that a real job?" 

Yep, it sure is! How cool would that be?

A great explanation that my colleague had used for younger kids was how we're 'detectives' looking for 'bugs in the code.' I love this!

Ten things I learnt in my first year of software testing

I'm one and a half years into my software testing career - and it's been the fastest year and a half of my life. Here are ten things I learnt in my first year of testing:

1. The global software testing community is huge, and hugely inspiring. 

• I don't think I've ever seen a more active and sociable professional community where people are willing to share their thoughts and ideas - and debate them. 

2. Communication skills are crucial 

• Working for a software testing consultancy means I'm constantly engaged with different clients and developers. Learning how to communicate effectively - be it verbally or written -  can make all the difference in both establishing relationships, building trust and in the overall delivery outcomes. 

3. Asking the 'dumb questions' early on can save a lot of pain later

• The question might feel stupid, but sometimes those questions are best answered early to prevent dangerous assumptions from being made, or stops me from deviating down the wrong path.

4. Testing is a creative process

• It's not just about meeting requirements. Testing is about really engaging with the SDLC process, and engaging with those around me. Thinking outside the box. Trying to challenge existing processes, challenge what's given to me and not accepting the answer of 'that's how it's always worked.' Getting paid to think is the best part of my job. 

5. You can't test it all

• Exhaustive testing is impossible. I've had to learn to let go of a lot of 'what-if's' and learn to trust my own professional judgement. 

6. You can learn from everyone around you

• Be it a BA, developer or fellow test professional, the way that everybody chooses to approach a problem is always interesting. Often developers will choose to tackle things from a technical perspective, a BA from a business perspective and a tester will often come into the discussion with their own take on the situation. No one is more right than the next person, but hearing the different perspectives always makes me re-evaluate my own analytical process. 

7. Coming from a non technical background is not a disadvantage

• I have an accounting degree. This doesn't make me any less of a tester than a person with a computer science degree. It just means that I think about things quite differently - and often, I think about functionality the way an end-user would, rather than from a 'but that's how the code works' perspective. 
• Some of the greatest testers I know don't have computer science backgrounds.
• That's not to say that I don't want to gain technical skills though - that's something that I'm hoping to work on. 

8. Being open minded and showing that you're willing to try new things is key

• Testers can be quite opinionated and passionate about their certain areas. As a junior tester, I've learnt that while it's important to develop my own opinion, keeping an open mind means that you don't close the door on opportunities that may come knocking. 

9. Everyday I learn something new (no joke)

• Software is a wee bit of a fickle thing. Just when I think I understand a functionality, I find out that there's this other part that triggers the main engine to behave completely differently. It's one of the biggest challenges of my job, but keeps me on my toes. 
• When I move from project to project, I get to learn about a completely new area of functionality - or I get exposure to a a completely different piece of software, which keeps life interesting. 

10. And finally, delivering a piece of software that works (or improves on existing functionality)  is super rewarding and feels so damn good.