30 Things Every New Software Tester Should Learn

✓ (Task 1) Are you interested in software testing?

Let’s start with a little self-reflection.

  • What led you to this article?
  • Why is software testing valuable to you?
  • What do you believe software testing is? We’ll talk about this more in the next Task but it’s good to think about what you currently believe it is.
  • Commit to print why you are here (a post-it or whatever medium you prefer)
  • Where do you plan to be at the end of this?
  • What skills do you have now that you think are useful for testing?
  • What do you currently perceive software testing to be?
  • Plan this guide into your schedule. Be realistic about what you can achieve. Consider your day to day work and your energy levels.

✓ (Task 2) What is software testing?

Start by writing down what you think software testing is and what a software tester would do.

  • Read this list of things of what software testers do.
  • Try asking people around you about the title of this task. Ask people you work with testers and non-testers, ask people on Slack and maybe even ask your family. Has this changed much from what you originally thought? How different were the responses you got?
  • Research other industries such as pharmaceuticals, appliances etc. What is their approach to testing? How different or similar is it to the tech industry? Do any of the differences change your thoughts on how you would approach testing?

✓ (Task 3) Testing for non-testers

When I started in software testing I had no idea what testing was. I also had no clue of where to start. One of the most useful resources I came across was the pathway Testing for non testers by Katrina Clokie. Using Katrina’s pathway I was able to understand testing and the value it provided. I was also able to investigate her references further to start expanding my knowledge and list of people I should look to for advice.

  • Share the link with your team
  • Read an article a day from Testing for non-testers
  • Create your own list of things to learn and practice. You will most likely be updating this constantly

✓ (Task 4) Get social

This will be a slightly easier task to get started with but you will need to put in effort to keep it up. Start as simply as you like or feel comfortable with. I do recommend achieving all of the steps below when you can.

  • Go to Meetup.com and look for a local software testing meetup
  • Join the testers.io or Ministry of Testing Slack
  • Join Twitter, start finding testers to follow and get involved in some conversations
  • Join The Software Testing Club
  • Read Andrew Morton’s blog posts on attending the Bristol STC meetup and the Cardiff STC meetup
  • Start looking up testing conferences such as TestBash, Agile Testing Days, EuroStar, STPCon, Global Testing Retreat, TestCon, STAREAST, Let’s Test, Nordic Testing Days. We’ll cover these more in Task 23. They are a big part of getting social.

✓ (Task 5) Get organised

It can be difficult to stay organised when there is so much information being thrown at you. I struggled with this a lot, I still do occasionally. Tiny Habits was recommended to me by another tester when I was getting started. I go back to it frequently and set myself new tiny habits to achieve, particularly when I feel like things are going awry. This does not take a lot of time but it will save you in the long run.

  • Sign up to Tiny Habits and do it for a week
  • Start a mindmap
  • Investigate if Habitica is for you
  • Create a personal Kanbanflow or Trello board. Start with the column headers “To Do”, “In Progress” and “Done”. Add a card for each thing you would like to achieve and move them across the columns as you progress with them.

✓ (Task 6) Sign up to the Dojo

Sign up to The Dojo and explore it. The Dojo is run by the Ministry of Testing. I have found it to be an amazing resource for my career. I can watch training videos, access testers blogs and I get notified of upcoming events that they host. I started with a free membership and finally graduated to a paid membership this year.

✓ (Task 7) What is a bug?

I know a bug in software when I see one, or at least I like to think I do. I thought it would be easy to explain what a bug is. When I tried to find a definition I found many that just didn’t cover the scope enough. James Bach defines a bug as “Anything that threatens the value of the product. Something that bugs someone whose opinion matters”. That is a nice high level definition. On Testing Computer Software you will find “most bugs cause a program to change its behavior when the programmer didn’t want or expect it to, or cause the program not to change its behavior when the programmer did expect it to”.

  • Have you encountered bugs in any of it?
  • Why did you feel like they were bugs?
  • Did you do anything about it (e.g. report a bug in an app through the app store)?
  • Can you think of three different things that help you decide whether a bug is actually a bug or not? These are called Oracles and we will look at them in more detail in Task 13.

✓ (Task 8) Recommended Reading

This is a starting point for your reading list. You won’t achieve all of this in one day. Some of the books I list here will be referred to in relevant sections later in the series. This is to make you aware of the existence of the books and work towards purchasing or borrowing them from the friends you will make when you get social.

  • Explore It! by Elizabeth Hendrickson, an excellent book about exploratory testing.
  • Evil by Design by Chris Nodder, I love this book! I learn something new every time I read it. I’ll cover more about this later.
  • Agile Testing by Lisa Crispin and Janet Gregory is one of those books that everyone raves about and you wonder why it took you so long to read it.
  • Thinking, Fast and Slow by Daniel Kahneman which I have not personally read. This has been recommended to me by enough people that I will be starting it as soon as I finish this article.
  • Start to read one of the books mentioned above. If you’re unsure where to start, I suggest Thinking, Fast and Slow.
  • Look at the recommended reading list from the CAST 2015 speakers.
  • Ask on one of the Slack channels or on Twitter for more suggestions of books to read.

✓ (Task 9) Write a user story

A user story is like a set of instructions you get with flat pack furniture. By writing a user story it will help you to understand their purpose.

  • A description of what needs to be done.
  • Acceptance criteria outlining what the story needs to accomplish.
  • Any criteria which are out-of-scope for the story to be considered accomplished.
  • Note any dependencies required to start the story.
  • Write a user story for making toast, a peanut butter sandwich or even Ikea furniture using the templates above.
  • How do you know if you missed something?
  • Have you made any assumptions?
  • Think about the order things need to be done in. Are there any optional inputs?
  • Are there any requirements or prerequisites (assume the user has bread for example)?
  • Try to make toast or a sandwich from scratch following your user story exactly.

✓ (Task 10) Testing personas

When you are testing you shouldn’t only test for you. You need to think about impatient users, users who take their time, users who have a bit of a tester in them and like to “break” things and many more. Katrina Clokie has an excellent guide to getting started with testing personas. As you get familiar with an application, things like this may slip from your mind and you may go into autopilot somewhat. I find trying to get into the user persona more helps me to avoid this pitfall.

  • Pick an app on your phone or a program on your computer to test
  • Navigate through it using the different user personas in Katrina’s article
  • What did you learn from this?
  • How did the application perform under each persona?
  • Think about and research how others approach personas

✓ (Task 11) Test a user story

This is linked to Task 9 and a follow on from Task 10. There are many ways to document testing but we will not focus on those here. If you’ve never written testing documentation, you could look at the test case templates on Tutorialspoint.

  • Who is this story important to?
  • What is the one problem this User Story tries to solve?
  • How could this be misunderstood?
  • How could accidental bugs find their way into this?
  • What behaviour should it absolutely NOT show?
  • When are you done?
  • At what point did you feel like quitting your analysis and want to start testing?
  • Does this feel reasonable?

✓ (Task 12) Heuristics

Cem Kaner and James Bach describe a heuristic as “a fallible method of solving a problem or making a decision”. Karen Johnson says that a heuristic “Refers to experience-based techniques for problem solving, learning, and discovery. Where an exhaustive search is impractical, heuristic methods are used to speed up the process of finding a satisfactory solution. Examples of this method include using a rule of thumb, an educated guess, an intuitive judgment, or common sense.”

  • Can you think of any other heuristic? Explain it to someone and give it a name. Test Sphere and Explore It! from Task 8 could help you with this.
  • Do you know of any heuristics you have used before? Use the articles above as guidelines.
  • Research and share other heuristics you might have found.
  • Pick any of the heuristics and start a discussion with peers.

✓ (Task 13) Oracles

According to Michael Bolton “An oracle is a principle or mechanism by which we can tell if the software is working according to someone’s criteria; an oracle provides a right answer — according to somebody”. Cem Kaner describes it as “a software testing oracle is a tool that helps you decide whether the program passed your test”.

  • Read Testing Without A Map by Michael Bolton. It gives a step by step guide on using oracles to determine if you are ‘done’ testing.
  • Check out Testing Mnemonics list that Lynn McKee has put together. Also read FEW HICCUPS by Michael Bolton which expands the HICCUPS mnemonic.
  • What oracles have you used? Can you see any oracles in your testing work?
  • When an app on your phone updated, did it maintain a consistent behavior? If not, did you like this inconsistency? Was it an improvement on previous behavior or did you consider it to be a bug?

✓ (Task 14) White & Black Box Testing

White and Black box testing are two approaches to software testing. Think of them as two umbrellas for types of testing to fall under.

  • Try out doing some of the Black Box Puzzles
  • Try testing any mobile app you have on your phone, you would essentially be doing black box testing
  • Go to the Khan Academy Computer Programming section, try out some of their tasks and see how you can create or identify problems with knowledge of code

✓ (Task 15) Accessibility Testing

Do you know anyone who is colourblind or maybe uses a screen reader? I know people who are colourblind, visually impaired, deaf, dyslexic or have photosensitive epilepsy. As a result I am always thinking about these users along with the ‘standard’ user set for our application. Luckily there are tools that can test an application for its accessibility level. A fun and easy trick to try is navigate through an application you are testing with no mouse or trackpad. Sounds easy right? Give it a go and see what you think. There are a few more quick things to try in this 6 Simplest Web Accessibility Tests Anyone Can Do. There are various plugins you can add to your browser to view your application the way someone with colourblindness would.

✓ (Task 16) Podcasts

Ever wanted to learn about new things while you work, drive or take the train? I always want to learn more in work, but have so many things to do. I can’t always sit down to watch a video of a talk or read a book or paper. Podcasts have given me the opportunity to learn while I work or commute.

✓ (Task 17) User Experience (UX) as a tester

The user experience is pretty much what it says on the tin. It is how the user experiences your application and how they respond when they use the application. Don Norman describes it as even more than that. Testers are often tasked with understanding user experiences and helping ensure the user has a good experience by reporting back any possible issues to the rest of the team. Even before the product is out on the market, testing can help to highlight UX issues. An example would be a page takes a long time to load. A user wouldn’t wait that long because the competitor product hasn’t got the same issue. We should investigate the delay and try to fix it.

  • Start to really think about user experience.
  • Can you recall a stand out positive user experience you had?
  • Can you explain why you felt it was positive?
  • Do the same for the negative case.

✓ (Task 18) Regression testing

A big part of software development is getting things to work together and keeping them working together. Even if loads of time and effort go into harnessing these implementations you’ll find cracks within the surface.

  • Think about a time when one feature in one of your favourite apps didn’t work anymore. This might be in a game such as Pokémon Go, Facebook, Netflix application, or any other product that does frequent updates.We’ve grown quite used to these frequent updates and bugfixes. Additionally, a malfunctioning feature might be fixed tomorrow. Sometimes, this backfires and users get fed up and discard the product entirely.
  • Consider the strategies these companies use to tackle their regression issues and compare them with strategies used in your company. Are they very different? Does that make sense to you? Can you come up with other strategies?
  • Do you have something that you can practice regression testing on? Let’s think back to that app on your phone. Did it recently update? Have a look around at the new functionality that the app creators say they have added. Has it broken functionality that previously worked? If so report it to them. They might already be aware of it but if not you’ve helped improve someone’s experience.

✓ (Task 19) Agile testing

If you’re quite new to the software scene you will not have heard of development practices such as Waterfall, Agile or DevOps. These are methods or approaches to software development. A key thing to notice in the diagram below is where testing fits into each of the approaches. DevOps is relatively new to the scene. We’ll start with Agile to ease you in and you can research DevOps more later.

✓ (Task 20) Pairing

Pair testing involves two people working together at the same machine with a single keyboard to test a piece of software. One person has the keyboard while the other suggests ideas or tests, pays attention and takes notes, listens, asks questions, grabs reference material, etc.. There should be a shared goal with this approach and the two people will constantly communicate to ensure that the goal is achieved. Communication is key with this testing approach. Both people involved should have a shared understanding of what they are doing and why they are doing it.

  • Read the articles from Katrina and find a pairing buddy. If you’re not in a software house ask someone from the meetups you attended or off Twitter or Slack, you could even try remote pairing.
  • Pair with this person and reflect on your experience.
  • What did you learn from it?
  • What could be better next time?
  • Would you do it again?
  • What did you teach the other person?
  • Katrina also spoke about this at TestBash Brighton 2016 watch it if you can.

✓ (Task 21) Mob Testing

This is not something you can do by yourself but you should read up about it in the Mob Programming Guidebook. If you can, try to do it in work or get a few people together to try this out. A good chance to do this is at the end of a sprint demo session. Start with a 15–30 minute slot with the whole team. Get them to start asking questions and testing the product as a team. This is a great way to get non testers involved in testing and possibly help generate some new ideas or approaches.

✓ (Task 22) Dark Patterns

Dark patterns are “user interfaces that are designed to trick people”. These are well thought out tricks that are meant to benefit a business but rarely consider the user. Have you ever noticed that the option to opt out of mailing lists is usually the smallest item on a page? You wouldn’t notice it unless you are really looking for it. These are dark patterns.

  • Watch the video of Emma’s talk.
  • Read the linked content and start to think about dark patterns.
  • Can you think of any dark patterns that you have come to accept as the norm in your life? You can use the examples from Melissa as a guide but I’m pretty sure once you start to really think about this you will have a pretty long list.

✓ (Task 23) Conferences

There are many testing conferences out there to choose from. Some even post videos afterwards of the talks. This is amazing, but honestly it is not the full experience. When you attend you get to network, this sounds awful business like but seriously it can be the best part about attending a conference. Another advantage of actually attending is the chance to ask the speaker questions at the end of their talk or find them afterwards to discuss it in more detail. Speakers usually welcome the opportunity to discuss their talk in more detail, sometimes it can even give them ideas about how they might change their talk in the future.

  • Find a testing conference to attend.
  • Network online with people who have or will attend the conference.
  • Search for existing online videos of previous testing conferences.

✓ (Task 24) Exploratory testing

Exploratory testing is one of my personal favourites. You get to explore areas of the application that you most likely didn’t cover with other testing methods or covered, but you felt like you could investigate more. There are some really interesting articles I will advise you to read for this. Most of them are quite recent!

  • Read the linked articles and start Elizabeth’s book.
  • When you are done reading them pick something you would like to explore, maybe an app on your phone as you take the train to work.
  • Explore with intent for the day!
  • Did you find anything unusual?
  • Did you feel like you explored it enough?
  • Would you approach it differently the next time?

✓ (Task 25) Mobile testing

I would call this a specialisation. I’ve put it in here so that you have resources to be aware of the specialisation. Maybe you’d like to specialise in mobile testing or your job requires knowledge of it. The Dojo has some resources in the mobile-testing section. Check out this quick introduction to mobile application testing. There are channels on both Ministry of Testing and testers.io Slack for mobile testing where you can ask for guidance if you wish.

✓ (Task 26) Security testing

Dan Billing recently released a sandbox to practice Security testing in called Ticket Magpie. He also has a lesson series on the Dojo to get you started. We’ve all seen the big hacks over the past year or more: TalkTalk, Ashley Madison, 3pay, Tesco. Security testing is becoming more important than ever before.

  • Watch or read about an introduction to security testing and see if it is something you would like to explore further
  • Go and read some of Troy Hunt’s work
  • Check out OWASP and the incredible resources they have
  • Check out the 30 days challenge by Ministry of Testing for security

✓ (Task 27) Automation

Automation is a huge topic of debate and discussion within the software testing community. When you delve into this topic be prepared to hear such things like “automation fixes everything”. These perceptions are the possible cons of automation. You may also read things about “testing vs checking”, please do not be put off by the language used, I know I found it overwhelming at the beginning. Richard Bradshaw gave a talk at TestBash 2015 about automation in testing, I highly recommend you start there. The Dojo also has a podcast talk with Richard about how to get started with automation. Maybe there are more podcasts related to it that you stumbled across from Task 16.

✓ (Task 28) Performance testing

There are quite a collection of resources about performance testing on the Dojo. Think back to that app on your phone and the software package in work from Task 1. It is estimated that the average user loses patience with a web page that doesn’t load after 4 seconds. Now think about Black Friday sales or those concerts that sell out in 2 minutes. Have you ever been in an online queue for either of these? Load and performance testing can help the whole team to get an estimate of possible weakness in the product before it is released to customers.

✓ (Task 29) Ask a question

After all this information you probably have a lot of questions.

  • Take a seemingly simple testing concept. Talk to someone about it. Ask for their understanding and explain it for yourself. What aspect do you stress and how does that differ from the other person’s explanation?
  • Did a blog or podcast cover the topic you have questions about? Leave a comment for the host to answer.

✓ (Task 30) Share your experience

People and even just yourself, will find inspiration and strength from writing about your experience, even if it is not for public consumption. Writing is a great form of self retrospecting to better plan for the future.

  • Tweet about each task with the #starttesting hashtag
  • Post updates to the #starttesting channel on Ministry of Testing Slack
  • Write a blog post
  • Write an email and send it to someone you may feel would benefit
  • Maybe even submit your own 99 second talk to the Dojo

About Heather Reid

Heather is a tester at Exploristics. Her passion is helping the software testing community in Belfast. She is a co-organiser of the Belfast testers meetup and of TinyTestBash Belfast. This all started when Heather discovered the Ministry of Testing through TestBash 2016. When she’s not testing she’s usually exploring or working on restoration projects. You can find Heather on Twitter where you will also find a link to her blog

--

--

Good stuff for software testers.

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store