Once upon a time, we looked at software testing and testers and I wrote about how software engineers don't get along so well with software testers because software testers help to ensure that the code meets the user's requirements and have no bugs. That responsibility puts developers and testers at loggerheads as, without the approval of the tester, a developer will have to keep perfecting the code before it is released. Now that we have the recap out of the way, I feel the need to share how testers do what they do, while I can't get into the nitty-gritty as I'm not a tester (though I've written some automation tests, unit tests, and done some manual testing which qualifies me to write this post), I do believe an overview of how they test can help us appreciate the work they do.
A RELATABLE EXPLANATION
There are two major methods of testing; we have black box testing and white box testing (Yes, if you read my post yesterday, you'll agree with me that the entire field of software development has a thing for creating/grouping things in twos 😂). You'll find that there are usually two things involved when it comes to anything with computer programming. I think it started when machines were taught to understand things in binary of 0s and 1s (but I digress 😅). It does help to ensure that one isn't boxed into a corner, you'll always have an alternative. It gives more legitimacy to the Yoruba proverb that says that "it isn't only one road that enters the market"
BLACK-BOX TESTING
Black-box testing is one that involves "over the surface" testing, it's like when you buy a car without the aid of a mechanic or without opening her up to see what she looks like under the hood. You simply take her on a test drive and you judge based on the performance of the vehicle during the test drive. Black box testing takes less time and a lot of it is being automated these days. Black box testing is also what is done during user acceptance testing, which is when the product is interacted with in the same way the actual users of the product will interact with the product in a bid to confirm if users will like the product before releasing it to the world.
WHITE-BOX TESTING
White-box testing is one that lends credence to the fact that the devil is in the detail 😅. This is typically where developers fight with testers the most, this method of testing is when you go to a car dealership with a mechanic who proceeds to spend time doing a full analysis of the car (you bet the salesperson will be pissed 😂) before a purchase is made. With White-box, the tester has to be given access to the codebase, the tester will quality time evaluating the code with the aim of finding loopholes that can be reported to the developer for fixing. This usually creates a cycle where the product goes back and forth between developers and the tester(s) till the code is fit for deployment. They can leverage tools like Selenium, Cypress in order to get the job done.
FINALLY...
You can be sure that Black-box testing is likely faster than White-box testing, this isn't to say one is better than the other, everything within the field of software requires tradeoffs. While black-box is faster, white-box is more detailed addresses more business concerns like efficiency, speed, security, reusability of the code, the ease of maintenance and the possibility of extending the code by adding new features. A lot of back and forth typically occurs between software engineers and software testers, a software tester said something recently that struck me, he said: "if you see an organization where software testers and developers are friends, it means they're not doing their work well".