The Basics of Software Testing
The Basics of Software Testing
In software testing, test automation involves controlling the execution of tests. What are these tests, exactly?
Join the DZone community and get the full member experience.Join For Free
DevOps involves integrating development, testing, deployment and release cycles into a collaborative process. Learn more about the 4 steps to an effective DevSecOps infrastructure.
In software testing, test automation involves controlling the execution of tests. Test automation can automate some repetitive (but necessary) tasks in a formalized testing process already in place or perform additional testing that would be difficult to do manually.
Test automation offers a possibility to perform these types of testing effectively. Once automated tests have been developed, they can be run quickly and repeatedly.
Many times, this can be a cost-effective method for regression testing of software products that have a long maintenance life. Even minor patches over the lifetime of the application can cause existing features to break which were working at an earlier point in time
There are many approaches to test automation. However, these are the general approaches used widely.
Graphical User Interface (GUI) Testing
This is a testing framework that generates user interface events such as keystrokes and mouse clicks and observes the changes that result in the user interface to validate that the observable behavior of the program is correct.
GUI testing can require a lot of programming. It's time-consuming whether it's manual or automatic. Usually, the software author writes out the intended function of a menu or graphical button for clarity so that the tester will not be confused as to the expected outcome. GUI testing also tends to test for certain program behaviors that users expect.
This is a testing framework that uses a programming interface to the application to validate the behavior under test. Typically, API-driven testing bypasses the application user interface altogether.
During API-driven testing, the following things are considered:
Exploring boundary conditions and ensuring that the test harness varies parameters of the API calls in ways that verify functionality and expose failures.
Generating more value added parameter combinations to verify the calls with two or more parameters.
Verifying the behavior of the API and considering the external environment conditions such as files, peripheral devices, and so forth.
Verifying the sequence of API calls and checking if the APIs produce useful results from successive calls.
A growing trend in software development is the use of testing frameworks such as the xUnit frameworks that allow for the execution of unit tests to determine whether various sections of the code are acting as expected under various circumstances.
Until now, testing has been slow with agile methodology. If you run testing late in the software development process, you risk discovering problems at a very late stage. It's a huge and complicated method. At the same time, it forces you to go back to the drawing board at the last minute, which is the worst. For developers who run testing with manual test executions, it can be incredibly time-consuming. They need to run tests after each phase of the cycle: after writing the test, after producing the code, and after refactoring the code.
Software ages. You need to test much more often to ensure its quality. However, most companies are working with limited resources and without much time to execute these tests. This gives you an unappealing choice: either risk compromising on quality or compromising on time. Neither of these options fit nicely within a smooth CD process.
You can automate your testing and integrate it into the build process as early as possible. A continuous testing platform runs in the background, automatically executing the tests and ensuring that issues are identified almost immediately, thus reducing the time to release and closing the circle to ensure a successful Continuous Delivery process.
Opinions expressed by DZone contributors are their own.