In the movie RoboCop, the cyborg law enforcement officer advised people to “Stay out of trouble.” This article focuses on ways to stay out of trouble when building a software product by following the stages of software testing, using the 1987 movie’s titular character as an example. Let’s examine each testing stage and see if we can build a better RoboCop.
Unit Testing
A unit is the smallest piece of functional code in a software application. In object-oriented programming, the smallest unit is usually a method. The method could be as simple as a single line of instruction, such as the product of a x b, which performs the function of multiplying two numbers. A unit test exercises the smallest piece of functional code to ensure it functions as designed. In this case, the unit test verifies that the multiplication of two numbers produces the correct value.
In our RoboCop example, a unit could be RoboCop’s pinky finger. Our unit test verifies that RoboCop’s pinky finger should be able to bend and straighten. The pinky finger should not break while bending or bend in a way the joints were not designed to move. An important distinction is that a single section of a finger, one-third of a “robo-pinky,” is not a unit, because one-third of a robo-pinky does not perform any function. However, the entire robo-pinky is a unit because it can perform the function of bending.
Integration Testing
This is the stage of software testing in which two or more units are combined and tested as a group. The purpose of integration testing is exposing problems caused by the interaction between the combined units.
Let's imagine testing two programming methods that produce returns that must work together. Individually, each method passes all unit tests, but the returns of each method, however, do not work together. One method returns a String, and the other method returns an Integer, so there is a type mismatch.
Think of integration testing as the testing of RoboCop’s entire hand, with five individual finger units and a palm unit combined to form an integrated hand. A good integration test would be to test RoboCop’s “kung fu grip,” a prerequisite for all Hollywood action heroes, human or cyborg. A grip without kung fu capability is not up to standards and should be rejected.
An example of a failing integration test would be if RoboCop’s hand could not bend two or more fingers at the same time. The individual finger units may be able to bend one at a time, a passing unit test, but if the integrated hand cannot bend two or more fingers at the same time, this results in a failing integration test. As the movie points out, RoboCop needs a firm grip for shaking hands and breaking hands.
System Testing
This is the stage of software testing in which all the integrated groups are combined to form the complete system. The purpose of system testing is exposing any defects caused by the interaction between the assembled integration groups. You are no longer testing components, but the actual return result of using the product. If the product is a word processor, you would be testing that all the menu options produce their expected results and that the word processor as a whole is capable of producing a customizable document that can be printed.
RoboCop is now fully assembled, and all its joints should be bendable. RoboCop should be able to move like a cyborg police officer within all the designed requirements, including walking, shaking hands, and writing violation tickets.
Acceptance Testing
The final stage of testing is evaluating the system to determine whether it is acceptable for delivery to customers. The combined RoboCop system is now tested to determine if RoboCop can perform all the law enforcement duties that a human police officer can perform, while being understandable to customers and meeting customers’ usability needs.
Acceptance testing asks, “Can customers effectively use the RoboCop system?” This means not only carrying out instructions as defined by its logical computer programming, but also having the context-driven, cognitive awareness of a person. For instance, the RoboCop system should not be issuing violation tickets to dogs for littering on sidewalks. Though technically illegal, RoboCop must possess the human reasoning ability to figure out it is unproductive to issue tickets to dogs. Fortunately, RoboCop passes the acceptance test.
As an example of a failed acceptance test, let’s examine the other robotic law enforcement droid from the RoboCop movie, ED-209. This clumsy behemoth of gears could only process computer code for its behavior and wasn’t able to reason like a human. During acceptance testing, ED-209 not only issued violation tickets to dogs, but arrested dogs for murdering the sidewalks. If we were in charge of testing ED-209, we would say it failed the acceptance test and should not be shipped to customers.
Don’t let your software testing future turn into a dystopia. The next time you’re testing a product, think of RoboCop, and make sure it passes each testing stage.
User Comments
Thanks, Michael!
You are right. Automated testing is essentially testing by robots. However, automated testing scripts are still coded by humans. Of course, humans with pacemakers or other electronic implants are technically cyborgs, so the lines separating reality and science fiction are blurring.
In my current assignment, I am being asked to help re-establish best practices for testing. Currently, there are only 2 phases being utilized here, SIT (System Integration Testing) and UAT (User Acceptance Testing) unfortunately the UAT team seems to do a majority if not all of the System/functional testing to requirements. I am attempting to make a cultural shift in re-defining the phases as you have indicated here. So, thank you this continues to validate my points on standard test phases, what they are and generally who executes.
Thanks, Jody! As Robocop might say, "Stay out of trouble in your testing."