Ever wondered if you can actually test less and perform other operations that will help your product achieve higher levels of quality in production?
Maybe this is what we should aim for when we define our job as QA (Quality Assurance) Engineers and not as Testers…
Some time ago I wrote a blog post called “Principles of good bug reporting” that talked about the basic things that make a good bug and helps testers not make the typical mistakes that then to make other members of our teams criticize our bug reports.
Jerry Weinberg commented on this blog saying among other things “I don’t think testers should be prioritizing bugs”, and looking back at what I wrote I now agree with him, I was only half right on asking tester to set their severity and priority grades correctly.
Many times we see testing teams that have automatic testing but still run part of their automation suites manually. I went out to ask for the reason for this in order to learn more about the challenges in running Manual and Automatic Testing efforts together.
Here we have the top answers, but I am also looking for more reasons in case you have something you want to share…
Is there such a thing as Agile Testing? I’m not sure there is…
You don’t need to work on an agile team to work and test based on an Agile Thinking mindset.
Yesterday I started providing short training sessions for agile programmers who need to learn how to test better.
Would you trust a programmer to test your application? It’s like asking a Fox to guard the chicken-house, right? Well, sometimes you don’t have a choice, or you do but that choice is to release the application untested…
Have you ever been on a situation where you need to test 10 things but you have only the time for 6 of them, and on the other hand you look at your development team and 2 programmers are done with all their important tasks and started working on stuff that sits under the “nice-to-have” list (or even worst, they went to the game room to “test the Wii”)? What do you do?
