Main testing terms, types and activities
> Manual and automated testing
> White-box and black-box testing
> White-box testing activities
> Black-box testing activities
> Other activities
Manual and automated testingManual testing is still very important and widespread because some kinds of tests cannot be automated (e.g., usability testing can be only automated partially). Moreover, some complicated faults are found by means of manual testing techniques only. Automation is realized with the help of special testing tools developed by such such manufacturers as IBM (Rational Robot, Rational Performance Tester), Mercury Interactive (Quick Test Professional, LoadRunner), Segue Software (Silk Software), AutomatedQA (TestComplete), and others (see also Software testing technologies, tools). Sometimes it is necessary to use specialized automation tools, for example, for unit or code style testing.
White-box and black-box testing
Black-box testing implies that a tester doesn't know how an application is designed at the code level, i.e., it involves dynamic testing of compiled applications. The tester interacts with the software system via its interface and analyzes the application reaction. Therefore black-box testing is one of the most popular testing types as: 1) It doesn't require access to the code, algorithms, and internal data structure (all of them can be a closely guarded trade secret of a software development company); 2) It gives an opportunity to test software products from the point of view of the end-user.
White-box testing (also called glass-box or clear box testing)
In this case a tester knows the internal program structure and its code. As a result, the tester can execute each program statement and function; check each intended error handling, etc. This testing involves source code reviews, walkthroughs, as well as design and execution of tests based on the access to the program code. White-box testing requires deeper knowledge of programming languages and technologies than black-box testing.
White-box testing activities
Here are some of the white-box testing activities:
The task of code testing is to test program classes, functions, modules as separate code units and check their interaction. As a rule, it is accompanied by development of special test classes, start functions, test data sets (including illegal/invalid data), design and execution of appropriate test cases.
Static testing takes place without running an application or its modules. It can include source code reviews, code inspections, peer reviews and software walk throughs.
Code style testing
This type of testing involves the code check-up for accordance with development coding standards and guidelines, i.e. using the rules of code comments use; variables, classes, functions naming; the maximum line length; separation symbols order; tabling terms on a new line, etc. There are special tools for code style testing automation.
Black-box testing activities
It is testing of application functionality and examination of its compliance with the software requirements specification (SRS).
The main aim of this type of testing is to make sure that the bugs revealed in previous tests are fixed properly and no new bugs appeared during such bug fixing. If possible, it's recommended to automate regression testing, as the number of software development / bug fixing iterations is usually large.
Test of application productivity and its conformity to requirements. It is especially important for complex Web applications and mobile software. For example, graphics processing can be crucial on mobile devices, so, it is necessary to check if the application works properly and, e.g., doesn't lead to display "freezing". Special tools allow getting productivity metrics. One of the subtypes of this testing is benchmark testing.
It tests system work under loading. This type of testing is very important for client-server systems including Web application (e-Communities, e-Auctions, etc.), ERP, CRM and other business systems with numerous concurrent users.
Stress testing examines system behavior in unusual ("stress", or beyond the bounds of normal circumstances) situations. E.g., a system behavior under heavy loading, system crash, and lack of memory or hard disk space can be considered as a stress situation. Fool-proof testing is another case which is useful for GUI systems, especially if they are oriented at a wide circle of users.
It tests correctness of application work when entering the boundary values of input data as well as proper processing of over-boundary values. For example, for a percent entry field boundary checks can be 0% processing (it should be processed correctly) and -1% treatment (it should not be allowed to be entered). Boundary values can be much more complex and demand much more complex boundary testing.
This is one of the most complex and interesing types of testing. It is very important for all sorts of application but it is the most acute for Web, mobile/wireless and mobile internet systems (see more in the article Mobile usability testing: problems and solutions).
It checks how an application works in different configuration environments (OSs, DBMS, peripherals, mobile carriers, network capacity, hardware, etc.). A typical example is a printing application: configuration testing would include test printing on all printers available in the market or the most popular ones.
Installation testingOne of the widespread problems with software products is the installation issue. You might have faced a situation when after buying an application which you liked at your friends' place; you had serious troubles with the installation. Installation testing is aimed at making the installation as simple as possible, so that you understand what is necessary to be done without quitting the installation process. This testing is often combined with documentation testing.
The aim of this testing is to help in preparation of the cover documentation (User guide, Installation guide, etc.) in as simple, precise and true way as possible.
Security testing is conducted to examine an application from the point of view of possibility to affect the user safety and/or make his/her data available to third parties. This testing is especially important for payment systems and other applications which use critical data about a user.
User Acceptance Testing
Involves running a suite of tests on the completed system. Each individual test, known as a test case, exercises a particular operating condition of the user's environment or feature of the system, and will result in a pass or fail outcome. The test environment is usually designed to be identical, or as close as possible, to the anticipated user's production environment. These test cases must each be accompanied by test case input data or a formal description of the operational activities (or both) to be performed—intended to thoroughly exercise the specific case—and a formal description of the expected results.