45 at 45

As of about 0100 on Sunday 20th August 2023, I was 45 years old. This isn’t a post about feeling old, I’m happy to say that I don’t. In fact I’m happier and healthier than I have ever been. I didn’t look after myself too well in my 20’s and early 30’s, but some lessons of varying harshness along the way have taught me a thing or two.

Speaking of learning, here is a list of 45 things I wish I knew when I started testing (in no particular order):

1. I have shaped everything I’ve ever tested. Being an information provider is a baseline, not the end goal.
2. Before giving feedback on unit tests, say thank you for putting the effort in. I know adding tests is part of being a developer, but its more complex than that.
3. If you ever think I know how to break this with my first test, just tell the developer whos building it what you are going to do.
4. Enjoy your ISTQB, don’t let anyone devalue you for taking it. I really enjoyed mine, the instructor used to test glass for aeroplane canopies by firing things through a cannon at them.
5. I’m glad the testing vs checking thing didn’t last very long. Beware semantic arguments, just use what you need.
6. If your system is hard to test, the testers will do the testing. That means you.
7. Test automation sticks when led by developers, despite the whole industry around testers writing test automation.
8. Domain knowledge is great, testing knowledge is better. Mainly because after a few years in the same domain, you pay less attention to testing.
9. Being able to run the applications you test locally, instantly brings you closer to your developers.
10. If someone says you can’t test this, then ask for a walkthrough of the PR. There will be something to test.
11. Build a good enough relationship with a developer that they will give you an early look at what they are building.
12. Without a positive relationship with your developers, your testing will be without an audience.
13. Offer to support your system but not without getting paid for it. You can learn a lot but it shouldn’t be for free.
14. The first time you use a browser automation library to start a browser programmatically is cool. And you should feel good.
15. If all the logic is in the front end, writing UI automation is a valid approach. You can’t fix every architecture.
16. Pick a mocking and stubbing tool and learn it well, it adds flexibility to your testing and enables you to get involved early. I like Wiremock.
17. Don’t say you’ve tested something when you haven’t. Just tell one person if it’s embarrassing.
18. The Testing Pyramid is a good way of thinking about testing in layers, its just that its not always a pyramid.
19. Ask for access to source control. I’m still surprised at how often organisations don’t use it.
20. It’s ok to learn at work (its mostly unavoidable) we aren’t preprogrammed with knowledge. There is always something to test but set aside some time for yourself, if you can.
21. Don’t feel under pressure to craft fancy charters. I’m going to test feature X in two sessions, one iOS and one Android is fine. Add sophistication later rather than starting there.
22. Charles/Fiddler/MTM are one of your best friends as a tester. It adds a whole new dimension, you can see what your application integrates with.
23. Remember, if you dash off to become a Scrum Master/Agile Coach/Product person while in your testing role, you are leaving a gap.
24. Support your local meet-ups and go to conferences, in that order. Conferences are expensive and time consuming, so choose carefully.
25. Early in your career, find someone to test with. Ask them about what you are testing.
26. Don’t ask developers who have never written unit tests to do test driven development. Its a terrifying ask.
27. Add some randomness to your testing, fuzz your product. No one does that and you will stand out.
28. Try not to automate what the system already does but test for what it needs to do.
29. Postman is one of the greatest bring the whole team together tools. A decent collection makes developers happy.
30. All decisions are made based on the best information and judgement available at the time. Even if it looks ludicrous in hindsight.
31. Setting up security and accessibility scanners is a perfectly good way to introduce those concepts into your test strategy. Iterate from there.
32. Performance and load testing is hard, don’t worry if your first scenario explodes everything.
33. When doing exploratory testing, add an initial time limit of 10 minutes of so, then check in and ask if you are still looking in the right place.
34. Ask for an architecture diagram of the system you are going to test. You’d be surprised how often they don’t exist.
35. Volunteer to give product demonstraions, but not always. It will become your job if you aren’t careful.
36. Testers have a really special sense of community that other software development disciplines don’t. Let people in.
37. Say after me: They are my developers or our developers, not the developers.
38. We should ask testers about improving developer experience. In fact, making the testers experience better will make everyone happier.
39. Being a tester is like being a Scrum Master, everyone thinks they can do it better.
40. Checklists and step by step tests are fine for some things, like data migrations.
41. If you get an invite to a product or solution architecture meeting, do your prep and think about how you can ask for greater testability. A nice hidden configuration menu for your mobile app for example.
42. Try not to ignore that was weird type feelings while testing. Especially if your application works at high scale. Ignored weirdness will happen to thousands if your users are in their millions.
43. The developers didn’t add unit tests because they have probably been discouraged to do so in their past. Or don’t know how.
44. If you are technically inclined, build a simple version of whatever it is you are about to test. A mobile app with a feed of items for example.
45. Using Gherkin syntax to structure your tests even if you aren’t doing the full BDD thing isn’t so bad. Just go easy on the datatables.

Thats it. Some of these are useful, most of these are wrong. I hope that some of them are familiar.

As Douglas Adams once said: you live and learn. Or at any rate, you live.