Browser Tab-Nabbing Security
April 7, 2021Things to look out for when switching from Couchbase SDK 2 to 3
May 7, 2021Part of my current work involves quality assurance(QA) for the code that our team writes. When I started performing QA work, I wanted to understand each feature and piece of code before I tested/reviewed it. That approach is still sometimes required depending on the feature being reviewed. As the amount of time I have spent performing this task accrues, I learn more and adapt my approaches. One such adaptation has been to test before I fully understand the feature. This allows me to test with less of a confirmation bias which I found I was falling into when I fully understood the feature and the code behind it.
My current approach is more like throwing pasta at a wall and seeing what sticks versus what falls off; It helps me test the code in ways I would not have considered otherwise if I would have fully understood it first. Once I understand it, I can be more surgical in my testing but I find it much harder to test the “what if” scenarios. Using this shotgun like approach has helped me identify issues that I would have otherwise missed.
When I ask a developer questions regarding the results I am seeing while testing their feature, it sometimes sounds like a dumb question. I have received several responses along the lines of “Why are you testing it like that? That is not the right way to test it.” I used to view that as a failure on my part, now I see it as a success. Asking dumb questions and testing the “wrong” way before testing the “right” way is a tool I have added to my toolbox.
Next time you test your own or someone else’s code try doing it the “wrong” way and ask the dumb questions. It might help you catch something you would have otherwise missed.