Tips on Testing

Shift-left testing

Case Study:

Our developers are asking if I could talk to them about tips on testing that they could use in their work, to catch the worst stuff before my testing. I don't know how to approach this I test user interfaces of consumer websites and apps and don't code, so that's where I am coming from. Has anyone ever done talked to developers about something like this?

-- Anonymous

Recommendation 1: Sure normal thing to talk with the Devs about possible issues and what they could maybe already check

• unit tests

• integration tests

• happy path testing

• some basic tips what to look for e.g. for date field: what happens if you enter a day in the past, today, future.

-- Andreas

Recommendation 2:

• Maybe basic, but I had projects where they obviously didn't do it: when they think the feature is "done" they should verify it in the demo environment, clicking through it so it does not only "works on my machine" Maybe do some pair programming sessions where you show them how you test?

Also, when you catch a bug, do the root cause analysis together with the dev so everyone learns from it.

But i think you are in a relatively good environment when the devs come to you for guidance how to catch defects earlier. That's pretty rare I think (if it's in good faith and not to shift more responsibility to you).

-- Andreas Worm

Recommendation 3:

I think that checklists are VERY useful. Basic stuff:

1. Does the page I've created or edited look right

2. When I enter expected data, does it save correctly?

3. What about unexpected data?

4. When I access existing items that are saved do they load correctly?

5. When I edit items do they save correctly?

I also love doing root cause, however I've found that's something that gets cut every time, as the team gets busy. I tend to try them when there's something more impactful or novel only.

-- Jeff Poulin

Recommendation 4:

When you create something you want it to work. There's a big cognitive bias there. In some sense developers don't thoroughly test because they don't want to discover problems and then have to fix them. In some cases it will require more than providing checklists to improve the situation. If they don't like/want to test then they probably will not do a very good job. I think this situation requires a mindset shift, I'm not sure how to effectively do that though.

-- Viktor Dimetriv

Recommendation 5:

If they demo to their peers and demonstrate that the requirements are met.... (you are a peer too btw). They don’t have to do all the edge case stuff. Sure it would help if they did, and if you helped them with that so when you do a 3 Amigos, they don’t have to rely on you to bring it up the next time. In effect this is a form of pair programming, where they demo to you and you test it and then they make changes for things you spot/they realise, and demo those changes to you. Update: I misread the question but hopefully it’s still helpful. Update2: if they shadow you as you test, and talk them through how and why you do what you do... make a checklist/bullet point list as you go along, so they can dip in and out. If it’s quick and easy, and if it can be built into unit tests, even better.

-- Mike Ruttenberg

Reference:

"http://testobsessed.com/wp-content/uploads/2011/04/testheuristicscheatsheetv1.pdf"

-----

"https://www.thebraidytester.com/downloads/YouAreNotDoneYet.pdf"

PDF