Overview
There’s a common saying in software testing: catching a bug in development costs 1c, catching it in automated testing costs $1, catching it in user testing costs $10 and catching it in production costs $10,000. Testing is one of the most important factors in producing successful software, but many developers only have a loose understanding of what the testing team actually do. Today at CodeClouds, we’re going over some testing basics.
Testing was always important: the cost of catching bugs late can be crippling. But in 2019? Our code gets more complex every year, and more moving parts means more ways it can go wrong. Testing was important when we were running IBM punch cards—it is orders of magnitude more important now that we’re building neural networks. It doesn’t matter who you are: even if you don’t go anywhere near testing, it’s important to know what it is and how it works.
We’ve broken down various types of test by simple questions. Sometimes you can combine them, and sometimes it’s implicit. For example, a functional test is almost always a black box test—you’re not going to hear people talking about black box functional testing any more than they talk about toothpaste for teeth. There’s various layers of overlap you’ll learn as you progress as a developer, but don’t worry about that too much for now.
How much can the test see?
White Box Testing: This is when the tester has full access to the code, and can see what’s happening internally as it happens. If you know there’s a problem, white box testing is great to figure out specifically what that problem is. White Box testing is also often done during development, before any problems have come up—it’s like regularly checking the oil in a car.
Black Box Testing: Testing that conceals the code from the tester. This form of testing can better replicate the actual user experience, and can help strip away distractions and get you to notice things you might not during white box testing.
What level are you testing on?
Unit testing: Testing each individual component of a piece of software to make sure they work in isolation. This is often the first sort of testing done, though it continues throughout the development process. Unit testing is often considered the most important form of testing: Agile development Guru Mike Cohn has a famous testing pyramid that puts it front and center.
Integration testing: Combining various units and testing how they interact with one another. This is the second stage of testing, and serves as a bridge between unit testing and functional testing.
Functional testing: Testing the software as a whole, often interacting with it more like an end-user would. Functional testing is the simplest sort of test to understand from a non-developer’s perspective: it asks does our product work? Y/N.
Who is doing the testing?
Manual testing: When a developer sits in front of their machine well, testing the software. Probably what most people think of when they think ‘software testing’.
Automated testing: When software like Selenium is used to simulate a user without actually requiring one. Allows for a much higher level of efficiency and coverage than manual testing, but can miss things that a developer might notice.
User testing: When you bring in actual users to test the software. In practical terms, this often means getting college kids to come in for an hour on the offer of pizza vouchers. This should happen fairly late in the game—it can get expensive if you’re relying on user testing to find a majority of your bugs. User testing is for when you think you’ve got a finished product, but you want to be sure.
Why are we running this test?
Acceptance criteria: Does the software do the thing it’s meant to do? Y/N.
Cyclomatic Complexity: How many different paths can be taken through a particular piece of source code. Lower C Complexity is usually better, though be wary about stripping away too much—while it’s a good indicator of how complex a piece of software is, ‘enough’ is going to depend on what you need from it.
Smoke testing/Sanity testing: Broad testing that aims to tell whether or not the basic functions of the software work. Smoke testing isn’t bothered about the particulars, it just wants to know whether the thing runs.
Stress testing/Load testing: Testing whether or not the software can handle high volumes of use.
Test condition: A catchall for one specific thing a particular test aims to measure. If you’re running a test to figure out whether a particular payment gateway accepts transactions through your app, then that’s your test condition. Acceptance criteria are the things you want to happen and tend to be considered as a whole, but test conditions can be smaller and value-neutral.
Have we missed anything?
User Persona: ‘Target audience’ but as an individual. This is a specific person, either real or imagined, used in testing to simulate end-user interactions.
User Story: A narrative construct intended to replicate how an actual end-user will interact with a product. User stories are useful because they pull us away from the code and make us consider what we’re actually making. They’re often written: as <user persona> I want <goal> for <reason>.
Is that it?
For now, yes. It doesn’t stop there, though—software testing is a lot deeper than it can appear on the surface. With the increasing complexity of our code and growing popularity of Agile development, it gets more crucial with each passing year. It’s something you should invest in, and pay attention to. Now go! Build yourself a user persona, boot up Selenium, and get testing!
If you’re a tester yourself and are reading this to remind yourself of the fundamentals, we have potential job opportunities for you. Checkout our careers page, CodeClouds currently has software testing jobs in Kolkata available.
Similar Reads
How can we help?
Tell us about your inquiry and we’ll get back to you as soon as we can.
