As I publish in Twitter: https://twitter.com/dobar
1. When you are stuck analyzing an issue and need someone’s help, after saying the nature of your request, continue with: these are the steps I took to understand the situation better before approaching you.
2. I worked with a programmer that got tired of the same questions by testers. I told him this is the last time, but I need all the info. Got it, asked questions, and published it all in Wiki. He was never asked again.
3. If you are professional, don’t limit yourself to tests. I surprised myself when I participated in design meetings and gave good points about general software architecture.
4. In case you have issues continually delaying your tests, like recurring lab downtime, don’t just complain: measure the damage and come to your manager with numbers (e.g., lab downtime hours X number of infected testers and plans delay).
5. Most bugs are not only the tester’s mistake but begin much earlier – in the requirements or design. Don’t agree to participate in the blame game. However, join and even initiate an honest lesson-learned process.
6. It’s the ordinary course of things that testers will find more important bugs in round 2 & 3 of a new feature than you expected. This is the point we get bored of the plan and test differently, and the point we know more about the feature.
7. Don’t be quick to answer questions about efforts even if you think people expect it from a pro like you. Sometimes small changes yield more tests than expected. Better start describing the tests needed and past experience, then estimate.
8. Measurements are a great tool, but just a tool. It can advise you about the status, but it is not the status only one of many sides of it. It is the first step to understand reality, not the last which is human analysis.
9. Learn some programming. Good for building tools including automation, but also important to understand how software works and have a common language with the programmers.
10. When you start working for a new company, and after adjusting, suggest the good thing you learned and are relevant to your new place, like test processes. I was always excited to hear how to improve our work.
11. Sometimes programmers’ products make them look bad. But let’s be honest, sometimes our actions look strange to programmers. Don’t be fast to judge.
12. Tester: make sure you share things that bother you with your manager – it is important! Manager – make sure that you create such a sharing environment!
13. There are no small features, only testers with hubris. In many cases, most in my experience, small features hide many implications: either on existing capabilities of the software or unthought cases inside the feature.
14. An outsider might be surprised, but being a software tester requires creativity, e.g. for creating exploratory charters.
15. you did ~70% of the tests for this version? Now by yourself and with peers imagine the user installing and using your app. What did you forget? e.g. that your tests run on cleared browsers but users have cache? Something else?
16. Always learn about methodology. Even one blog post/article/book chapter a week is good – that’s how I finished a (great) long book – Agile testing.
17. Everything in testing (maybe in life too) is based on the situation. Having a large number of tools and use them per situation might be more effective (and fun) than ‘best cases’.
18. Some days you’ll fill frustrated you didn’t do anything or progress wasn’t done. But maybe you did progress fixing the reasons for the delay – that is progress. If it’s just waiting, have a backlog of important, not urgent tasks to perform.
19. Your manager could be wrong about test strategy. If you think so- tell him. If he’s not willing to listen (he can disagree), consider looking for a new position. You’re a pro tester with opinions. Also, it will not help your development.
I once thought a certain area must be tested, but my manager thought differently and didn’t approve. I did a recon session on my free time, found critical bugs, presented them and got allocations to deeper test. Later, my manager told me it was a mistake not to test that area.
20. I used to ask nominees how they handle boring tasks like regression tests. But there aren’t boring regressions unless you want them to be: perform test differently, try new ideas, combine tests with other features, add heuristics…Make it fun!
21. Don’t count on your employer to take care of your career. If you think you need to learn something ask your employer to assist. If it doesn’t work – learn it on your time and if needed expense. It’s your life.
22. Report bugs even if they are not part of the tests you are currently performing.
23. The bug report is your business card. When written well, it combines much of your knowledge about testing, the project, the system, etc. Your peers and managers will assess you accordingly.
24. If you have responsibility for tests, review opened bugs daily (for review: are they clear and accurate? and for knowledge about the system status), and go over all the tests plans (to know important tests are covered).
25. Always be skeptical but not obnoxious.
26. Join code design reviews even if most of the meeting is a waste of time. Still, you can give a valuable contribution at certain points. Heuristic: When a flow presented point to an object and ask ‘what if that fails’.
27. when a bug is fixed, a bug that is important or is interesting or unexpected – don’t hesitate to ask what happen and how it was fixed. Here is a great opportunity to learn important things about the system.
Source: ministry of testing
27 short advices for software testers