Free websites to learn software testing skills

This pathway is designed to help non-testers tackle testing activities. If you’re asked to test something in your team, this is a set of practical resources to help you. Software testing is an investigation conducted to provide stakeholders with information about the quality of the software product or service under test.

There are a variety of steps that you may approach linearly or by hopping about to those that interest you most. It is a little different to the other testing pathways as it is:

  • Specifically for non-testers
  • Designed to help people with immediate questions like “How do I decide what to test?”
  • Does not include exercises, instead assuming that the provided resources will be applied in practical situations within your development team

STEP – Why non-testers should be involved in testing

Agile development teams generally seek shared ownership of quality. In order to achieve this, the tester may have to yield some control and others in the team may need to be more willing to pick up testing activities. These teams want to move away from the tester as the only person who tests, towards an environment where the tester leads testing and empowers others to contribute too. These articles describe the shift in thinking towards testing as a shared activity:

READ ALSO:  Top African technology companies to watch in 2018/2019

STEP – How to make an application testable

As developers and business analysts, the easiest first step to aid testing of the product is to understand the attributes that make it testable. Changing the way you specify solutions and design software can have significant impact on a tester’s ability to verify and explore what is delivered. Learn to consider the various facets of testability:

STEP – How to decide what to test

When asked to pick up a testing task, the non-tester may wonder where to begin. Testers are often poor at explaining how they test an application, which can make testing seem like magic. In fact, testers will have their own set of testing heuristics, whether they can articulate them or not! Fortunately there are resources that provide common test heuristics to help you determine which tests you’d like to perform, or prompt you to think of your own ideas beyond these boundaries:

READ ALSO:  QServers Web Hosting: Reviews and Rating based on users experience

STEP – How to document your test ideas

One deterrent for a non-tester to test may be your perception of the amount of documentation required. Within your development team, the testers are likely to have an approach that you can adopt. However there may be freedom for you to utilize lightweight documentation to map out your thinking. Perhaps to simplify what you need to do, a tester might transfer your results into the wider ecosystem of test artifacts afterwards. These articles give practical examples of using mind mapping software for test planning and execution:

STEP – What to think about while testing

Testing isn’t just about picking up and blindly applying the heuristics of others. When interacting with the software you may also want to consider what user persona to adopt, what bugs to raise, and what test evidence to collect. Though many of these decisions will be driven by collaborative interaction with your development team, these resources may help you understand the possible compromises being made and approaches that are possible:

READ ALSO:  Best places to learn mobile app development for free

STEP – How to debrief

A key aspect of getting non-testers to pick up test activities is following up with a post-testing debrief. This provides an opportunity for the tester and the non-tester to sit together and spend a few minutes discussing the testing activity that has occurred. These resources provide common questions that may be asked during a debrief:

STEP – Where to automate

Finally, you may be asked to contribute towards automation. Agile teams will usually require automated checks to support their rapid delivery cycles so that testers have time to understand new functionality, explore the application and find interesting problems. These articles describe factors to consider when determining what to automate, where to implement and how to interpret the results:

Thanks to Steve Mosley & Anthony Boobier, the non-testers who helped refine this pathway.

Leave a Reply

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