|
|
|
Quality > Quality Assurance
|
|
|
Quality Control
|
What is Quality Assurance?
A simple definition in the context of quality is that ‘quality is meeting requirements’. This definition works because by creating technical specifications and requirements that describe various attributes of software as well as how it should function you have set yourself goals to achieve and have determined specific indicators of quality. Quality can then be measured by testing various aspects of your Web site and the complex relationships between all areas of the site at intervals.
|
User input validation
User input must be validated to conform to expected values. For example, if the software program is requesting input on the price of an item and is expecting a value such as 3.99, the software must check to make sure all invalid cases are handled. A user could enter the price as "-1" and achieve results contrary to the design of the program. Other examples of entries that be entered and cause a failure in the software include: "1.20.35", "Abc", "0.000001", and "999999999". These are possible test scenarios that should be entered for each point of user input.
Other domains such as text input, need to restrict the length of the characters that can be entered. If a program allocates 30 characters of memory space for a name and the user enters 50 characters, a buffer overflow condition can occur.
Typically when invalid user input occurs, the program will either correct it automatically, or display a message to the user that their input needs to be corrected before proceeding.
Boundary Value Analysis
Boundary value analysis is a form of black box testing in which input values at the boundaries of the input domain are tested. It has been widely recognized that input values at the extreme ends of and just outside of, input domains tend to cause errors in system functionality.
In boundary value analysis, values at and just beyond the boundaries of the input domain are used to generate test cases to ensure proper functionality of the system. Boundary value analysis is an excellent way to catch common user input errors which can disrupt proper program functionality
Smoke testing
A sub-set of the black box test is the smoke test. A smoke test is a cursory examination of all of the basic components of a software system to ensure that they work. Typically, smoke testing is conducted immediately after a software build is made. The term comes from electrical engineering, where in order to test electronic equipment, power is applied and the tester ensures that the product does not spark or smoke. It ensures that the future testing is not blocked.
Black Box Testing
To check that the outputs of a program, given certain inputs, conform to the functional specification of the program. In electrical hardware testing the specifications of the interface between the device and application circuit is tested.
The term black box indicates that the internal implementation of the program being executed is not examined by the tester. For this reason black box testing is not normally carried out by the programmer. In most real-world engineering firms, one group does design work while a separate group does the testing. The main benefit of black box is that the tester is inclined to look at the software from a user perspective and see how the software interacts with its environment.
Unit Test
In computer programming, a unit test is a procedure used to validate that a particular module of source code is working properly. The procedure is to write test cases for all functions and methods so that whenever a change causes a regression, it can be quickly identified and fixed. Ideally, each test case is separate from the others; constructs such as mock objects can assist in separating unit tests. This type of testing is mostly done by the developers and not by end-users.
Integration Testing
Integration testing is the phase of software testing in which individual software modules are combined and tested as a group. It follows unit testing and precedes system testing.
Integration testing takes as its input modules that have been checked out by unit testing, groups them in larger aggregates, applies tests defined in an Integration test plan to those aggregates, and delivers as its output the integrated system ready for system testing.
The purpose of Integration testing is to verify functional, performance and reliability requirements placed on major design items. These "design items" i.e. assemblages (or groups of units), are exercised through their interfaces using Black box testing, success and error cases being simulated via appropriate parameter and data inputs. Simulated usage of shared data areas and inter-process communication is tested, individual subsystems are exercised through their input interface. All test cases are constructed to test that all components within assemblages interact correctly, for example, across procedure calls or process activations.
The overall idea is a "building block" approach, in which verified assemblages are added to a verified base which is then used to support the Integration testing of further assemblages.
Black Box Testing, Concrete Box or Functional Testing
Black Box Testing, Concrete Box or Functional Testing is used in computer programming, software engineering and software testing to check that the outputs of a program, given certain inputs, conform to the functional specification of the program. In electrical hardware testing the specifications of the interface between the device and application circuit is tested.
The term black box indicates that the internal implementation of the program being executed is not examined by the tester. For this reason black box testing is not normally carried out by the programmer. In most real-world engineering firms, one group does design work while a separate group does the testing. The main benefit of black box is that the tester is inclined to look at the software from a user perspective and see how the software interacts with its environment.
A complementary technique white box testing or Structural Testing uses information about the structure of the program to check that it performs correctly.
Alpha, Beta and Gamma Testing
In the first phase of alpha testing, developers test the software using white box techniques. Additional inspection is then performed using black box or grey box techniques. This is usually done by a dedicated testing team. This is often known as the second stage of alpha testing.
Once the alpha phase is complete development enters the beta phase. Versions of the software known as beta versions are released to a limited audience outside of the company. The software is released to groups of people so that further testing can ensure the product has few faults or bugs. Sometimes beta-versions are made available to the open public to increase the feedback field to a maximal number of future users.
Testing during the beta phase, informally called beta testing is generally constrained to black box techniques although a core of test engineers are likely to continue with white box testing in parallel to the beta tests. Thus the term beta test can refer to the stage of the software—closer to release than being "in alpha"—or it can refer to the particular group and process being done at that stage. So a tester might be continuing to work in white box testing while the software is "in beta" (a stage) but he or she would then not be part of "the beta test" (group/activity)
System Testing
Most software produced today is modular. System testing is a phase of software testing in which testers see if there are any communications flaws either not passing information or passing incorrect information between modules. Testing that attempts to discover defects that are properties of the entire system rather than of its individual components.
Regression Testing
A regression test re-runs previous tests against the changed software to ensure that the changes made in the current software do not affect the functionality of the existing software. Regression testing can be performed either by hand or by software that automates the process. Regression testing can be performed at unit, module, system or project level.
Regression testing often uses automated test tools to reduce the effort required to repeat a large suite of tests over many versions of the software.
|
|