Team Quality

Automated Tester

Our job as automated testers is not to catch bugs it’s to validate that the bugs exists. When you attempt to set up automated testing and you also have the primary responsibility for quality you lose site of proving bugs in favor of hunting for and catching them. Everyone on the team should explore the appication to uncover risks. This activity may help catch bugs, but being responsible for automated testing it is your job to write the most valuable regressions tests. Regression testing is not about bug hunting. You are proving that a bug exists for various scenarios executed against the application. You find tests that can prove a bug exists and when the tests don't reveal the bug you can say that it doesn't exist and the application works as expected for a given scenario. This type of testing will not uncover new bugs but will only reveal suspected bugs that have been coded into the automated check. This means the team has to step up the Team Quality approach and manually test the application, write automated unit tests, integration tests, and UI functional tests.

QA Tester

The days of QA tester bearing the primary responsibility for “QA” must be destroyed. I don’t mean go out and fire all QA. Just that traditional QA mindset must be renewed or it will go the way of programming computers with paper punch cards. Testers must assist in transforming the role from “test monkey running through checklists” to risk analysts. I was born on the delivery team as a developer and spent many years there. I changed roles to test developer in January 2014. Although, my responsibilities got expanded to DevOps and building development infrastructure so I was not fully immersed in testing. I have continued to study testing, ponder about it, question the validity of various techniques, processes, and tools and think about how to prove what waste or value they provide without bias.

I am a baby tester and I may be wrong about these views on testing. Yet, I can’t help but to have an opinion based on what I know so far. Sharing may assist in someone helping me to fail so that I can pass to the next stage.

I remember I had a mandatory test that I to pass to continue in my career progression. The test was automated. To pass it you had to watch a video and answer a quiz with 80% correct answers. A tester would know that you didn’t have to watch the complete video to get credit for watching it, because they would have been testing the automated test system as they took the test. A tester would also know that you can fail the quiz as many times as you like as long as you get 80% correct at some point. The questions and answers don’t vary greatly from test to test so you have to at least read the question make an educated first guess, if you get it wrong remember the answers and select a new answer for the question on the retries until you locate the correct answer.

This is like continuous delivery. You want to continuously deliver passing test scores. You want to have very fast feedback on the correctness of you test response. You want to know if you saw that wrong test response before. Then you want to give a new response as soon as possible to correct the wrong one and get fast feedback. Loop.

The OODA loop, continuous improvement, Kaisen. Failure is an option as long as you can succeed fast. The trick is learning how to succeed fast and accepting that failure is OK.

You must think deeply about each change to your application. Understand what is expected, surmise what may go wrong, and make judgements on how best to do this in a way that you provide enough trusted feedback to help the delivery team keep the application running and growing.