1

Question: I am needing advice on how best to approach a testing for a project where I am the only tester.

Are there standard processes that every tester should be following?

Are there specific patterns that every tester should be following?

Background:

  • Currently I'm working in a new project where I'm the only tester in my company.
  • I know to write the test cases, automation tests in selenium, communicate with development & business analyst resources
  • I have requirements provided by the client
  • I have only prepared & executed test cases manually and then automated the particular test cases
3

In order:

  1. First learn the business domain and processes
  2. Manual testing the happy path
  3. Manual testing the sad path
  4. Automating the happy path
  5. Manual testing optional paths
  6. Unit tests
  7. Automating the sad path
  8. Automating optional paths
  9. Manual testing browser/device
  10. Performance and Load Testing
  11. Automating browser/device
  • I know about the testing types like smoke, sanity, regression....I don't have any practical experience with the testing types when should I apply to my project ? – user24314 Mar 26 '17 at 6:16
  • Don't get hung up on terms. Smoke and Sanity tests are the happy manual/automated tests. Regression tests are basically any tests that you keep around and run again. Typically regression testing refers to automated tests. – Michael Durrant Mar 26 '17 at 9:59
  • I miss an important item between #3 and #4- decide what's worth automation. Not every happy path it automatable or worth automating. – Rsf Mar 27 '17 at 13:27
  • Well that's true for every level and aspect of test and manual automation. – Michael Durrant Mar 27 '17 at 13:55
1

I start but working with the stakeholders to build a common understanding of the scope of the testing activity. To do that I use a cut down version of the IEEE 829 master test plan. The idea is to capture as much information form the stakeholders as you can without creating an un-ncessarly detailed document (good chance no one else will really read it anyway.)

I keep updating this plan through the project. Even if there is a sign off I keep that version and continue to update a new copy as I go. I use it as a map and to measure progress and identify scope creep through the project.


Introduction

Test Items

  • Clearly identify the thing you’re focused on; Also the things that are dependencies or affected but aren’t going to be your focus.
  • Its important that everyone agrees on where to draw the line around the system under test.

Features to be tested

  • A simple list of each features in scope. It doesn’t need to be every feature of the system, just the ones that mater in this round of testing/ Usually all new features.

Features NOT to be tested

  • Often at the start of the project this will be empty but as things that are identify as too hard and low value might be added here as you go.

Risk failure modes

  • Not in IEEE 829, I add this to prioritise things. Here I create a mind map of failure modes and possible causes.

Approach

  • In this section describe the kinds of testing and tasks you plan to undertake. Exploratory testing for this bit, automation for that bit. Build a special framework to manage bits C, D, and E etc.
  • The exact makeup will depend on what you’re testing. My advice, if you’re already committed, is to underpromise and overdeliver .


Pick and choose the next IEEE 829 headings based on the projects specifics, environmental requirements, scheduled, test complete criteria, etc..


Then create a series of test tasks to address the features and anticipated failure modes. I don’t try to address each feature with an individual test case. In my experience things move to fast to keep up trying to do that, and often ended up spending days writing up notes on old news.

If you’re working in sprints add a few test tasks, the ones that make sense, to the backlog. Also plan time to review stories that are being worked on by the development group and deal with any bugs that might come up.

1

I'm in a similar position as yourself as being the only tester in the company.

In terms of approaching testing for a project, my advice is to find an approach/ process that works best for you and your company as each company/tester is different.

Experiment with different approaches and see which one works best. Approaches I've used in the past are:

  • Test plan following ISO/ISEE
  • Mind map
  • Checklist

Each one started with gaining an idea of what was in scope and what was out with relevant stakeholders. From these conversations, I got an idea of what was needed for the release not just functional testing (i.e making sure it worked, ensuring existing functionality still works (regression)) but also non-functional (performance, security, usability).

Depending on how your company work, you can break these down by feature/ requirement: For each feature/requirement:

  • does it work as it should
  • does existing functionality integrated with it work as it should?
  • does it perform?
  • is it secure?
  • is it usable? etc

Then it's a case of deciding what to automate and what not as per the approaches above. I generally follow a risk-based testing strategy based on the technical and the business risk

Severity = business impact (high, medium, low) Probability = technical/testability risk (high, medium, low)

This forms a matrix and helps me decide priority, what is important to automate and other decisions.

Most important is to always have a definition of done/ release criteria that everyone can agree on - stakeholders, developers, testers etc. There will always be lots of things to test, new and imaginative ways to find defects etc so this is important to help know when to finish and by getting everyone to agree, it helps brings everyone together to help get a release out.

Hope that helped?

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy