With even the utmost care taken by developers: Bugs creep into code. Whether it’s Microsoft’s bug in their SMB software that led to the infamous WannaCry hack. Or the bug that crashed Apple’s iPhones whenever they were sent a peculiar message.
At this point in the computer history, timeline bugs are pretty much a given. Developers combat bugs with a counter-tactic known in the community as testing.
The tactic in effect is to lay down a minefield designed to go off when a bug is nearby. Mines are concentrated to ensure tightened coverage around points of interest/increased importance.
Such as password authentication systems. Developers regularly check the minefield to see if any of the mines (tests) have gone off (failed). If they have, the developer knows to start looking in that area for the bug.
This works because, unlike a minefield, tests can be generated out of thin air. They can also be automated, stacked, copied and even brought onto airplanes.
Not to mention they take up so little space you can virtually never have too many. That does sound quite nifty. But.
What Is A Test?
We can liken software testing to the quality control process in a factory. After the door of a car is assembled it must go through a quality check to ensure that it is going to work properly with the rest of the car.
This quality check is a part-specific list of tests such as:
- Does the car door close properly when fixed to the car frame?
- Does the door handle activate the latch mechanism?
Software testing is the same.
A push button, once designed and implemented, must go through its own part-specific quality check consisting of the following tests:
- Does the button change to the correct color when pressed?
- Does the button perform the correct action after being pressed?
- Does the button have the right wording, color and/or icon?
- And so on…
They differ from a factory check in that these tests will live in a document where they can be automated to run all at once or alternatively one by one. Each of them will produce an output of either Passed or Failed.
While these tests could be performed manually the value proposition is when the developer has 50 modules to work on. Tests against all the modules can be run at the same time with a single command.
This workflow provides valuable instant feedback that can be traced directly to any modules that are failing.
Test Flavors
It doesn’t make sense to test each part of a car on its own if we do not also test the car as a whole once assembly is completed.
This is not only possible with software, but we can test at each step right down from individual units all the way up to a fully functional product with all the parts attached.
And then we can throw in some Quality Assurance as the cherry on top. These steps are detailed by the following types of tests:
Unit tests
A unit test is designed to cover a single module (unit) of software in isolation. This can be in the form of a single function or a single object. The key is that the module does not interact with anything else during the test.
As an example, a calculator would test both the minus and plus operations separately as unit tests.
Integration tests
By contrast, an integration test is designed to cover a scenario where different modules work together as a group.
In our calculator example, we could test that a calculation with both a plus and minus operation produces the right answer as our integration test.
Functional tests
A functional test covers a whole functionality which may include multiple modules.
In our calculator example, we could check that the formula for the area of a circle produces the right answer as our test.
QA tests
Quality Assurance tests are focused on the end-users of an application. A QA test must describe what the user intends to do and how the application should respond.
These tests are difficult to automate because they involve user interaction. In our calculator example, we would check that the user is able to find and use all the operations easily without asking for help as our test.
Benefits of Testing
Testing increases the time taken to implement features off the bat. This makes sense as the tests themselves are code that must be written.
But do not fret! The benefits that come with this increased initial development time are multifold.
Increased product quality
Knowing that code needs to pass a check makes developers think harder about the problem they are solving and pushes them to improve and match the stakes.
The quality of the product goes up proportionally to the quality of the code.
Bugs can be found and fixed early on
Defects in code that may have come up later on in the integration process can be caught quickly and fixed preventing back-and-forth frustration.
Pseudo documentation
Tests utilize components the way they were designed to be used. If a new developer joins a team at Appstrax Technology they need look no further than the tests to understand what each of the systems do and how they are used. They can of course also look at the actual documentation.
Cost reduction
Fixing bugs means extra costs allocated to development resources. Testing helps to find and fix bugs quickly, reducing the time spent in the debugging process and consequently less money on development resources.
Write Better Software With Tests
It’s all about the code
The technique is battle tested on the iron shores of Google, IBM and even Microsoft who had a rough introduction to testing around the Windows 2000 days.
When it boils down to the hard brass jazz tacks: Software testing is about producing the best code that the developers can without dramatically increasing time-to-market. And by extension testing is about producing the best end product for the customer.
Do We test?
At Appstrax we find that writing tests can occasionally feel like a drain to a project’s release velocity at the outset.
However, this feeling quickly subsides when developers start to push out high quality features without getting bogged down by hard to find bugs.
That is, after the initial bump, the release velocity actually increases! Our commitment to high quality code has led us to strive for 100% test coverage.
