An interesting discussion came up recently on the Ministry of Testing Slack. It’s one that I loved to see because it reminded me of some of the excellent developers I have worked with in the past.
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?
With follow up information of:
I need to give a stand alone talk about what they can individually do, possibly in projects where I am not even around.
Answers included:
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
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
I think that checklists are VERY useful. Basic stuff:
- Does the page I’ve created or edited look right
- When I enter expected data, does it save correctly?
- What about unexpected data?
- When I access existing items that are saved do they load correctly?
- When I edit items do they save correctly?
What would you add or expand on in the above suggestions?
3 Likes
I’m a BIG fan of pair programming mentioned above. Doesn’t matter if tester is a manual tester or automation engineer, pair programming is win-win for both testers and devs as it’s the best way to help / support devs on testing stuff and in-return learn development related stuff from devs. As an added bonus It helps testers to come up with more useful scenarios when they get exposure to the code and architecture of the application.
Testing workshops (e.g. TDD or BDD) may help in starting culture of Test/Behavior Driven development. However, these workshop also need to be followed up with pair programming for proper implementation/acceptance.
A checklist could be useful in some cases however in my opinion it often could be too vague or too exhaustive to use on daily basis.
Pointing Devs to theoretical testing concepts for self-learning may or may not work with all as not all devs would be motivated enough or not all of them would have time to learn through vast theory related to all types of testing.
1 Like
I introduced testing tours to a few of my colleagues and a few of them really got into it. Like all of a sudden it all made sense to them. Both the idea that you look at you work from different perspectives and that you give some focus for test ideas. Some of the favourite tours for their data intense web application are:
- Data Tour - Follow the data through different parts of the application
- Claims Tour - Look at what the application is claiming you can do
- Superficial Tour - Only look at the appearance, same style for same function, consistent layout etc.
4 Likes
I love the idea of tours. We did this in a previous team, we had the advantage of having moved to a larger office and mapped the entire application out on the floor. One person was the user and they were navigated around the map by members of the team to visualise possible risks, omissions, etc. (We were very visual learners)