Hell of a Tester

Improvements in how things are being done don't help that much if you are doing the wrong things. Focusing on cutting down the deployment/production pipeline, using the latest and greatest languages and tools, exploratory testing, mob programming, etc will surely be a boost to efficiency. But efficiency is not key if you are doing the wrong things. And quite often we are. And a big reason for that is, that we suck at prioritisation. We suck at it because we: - spend too little time on it: "But we could save minutes of talking by hours of coding!" - do it too rarely: "Welcome to our annual roadmap revision meeting." - try to have specific people/roles be responsible for it: "Ask the PO..." - do not think about different dimensions enough: "But the customer needs it!" But mainly we suck at it because it is so hard. Here tho is list of 10 things I think might help. 1. Don't keep a big backlog. Focus on the things being done ...

I have had quite a lot of discussions about code reviews. Quite many also with testers, by which I have understood that many do not do those. I will not start arguing here on whether code reviews are good/important or not. But I will list a few things why I think testers would benefit of doing them. 1. Code is the only documentation that is up to date . If you really want to know how something really functions, you want to be able to see and read the code. 2. Knowing more about the thing done enables you to do better testing . You can spot things that you should definitely test, and things that you probably don't need to test that much. Like extra things added by coder, usage&modifications of existing functions, data types, etc. And to arguments thinking that one loses their "independence" as a tester by knowing too much, I would worry a lot less about that than about testing stuff that you have no idea on how it has been built. 3. Improve logging . I obse...