1. When you are stuck analyzing an issue and need someone's help, after saying the nature of your request, continue with these steps I took to understand the situation better before approaching you.
2. I worked with a programmer who got tired of the same questions by testers. I told him this was the last time, but I needed 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 rounds 2 & 3 of a new feature than you expected. This is the point where we get bored with the plan and test differently, and the point where 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 understanding 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 things 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 too 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, 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 the 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 in my free time, found critical bugs, presented them, and got allocations to deeper tests. 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 tests 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 test 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 presents a point to an object and asks '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 happened and how it was fixed. Here is a great opportunity to learn important things about the system.
Comments
Post a Comment