by T Ashok
Summary
Terms used in the software testing discipline are often confusing leading to them being abused. Most of the phrases seem to have appendage of ‘testing’ like a surname that seems to make it belong to a family. Some terms are test types while some are approaches, and some practices and so on. This article partitions 50+ software testing terms into cohesive groups to sharpen the clarity depicting it as simple mind map and then giving a clear definition to each one.
Jargons abound in software, only to be misused most often! And I think in our discipline of testing, they are abused even more! In the testing discipline, most of the terms seem to have an appendage of ‘testing’ making it far more confusing.
In this article I have attempted to put together a mind map
attempting to group terms cohesively based on a phrase
to minimise confusion and sharpen clarity.
Here are quick explanation of these terms with details in the associated link after the terms.
Levels of testing
Unit, Integration, System, Acceptance refer to the levels of the testing, implying as when in the SDLC, the earliest being the Unit testing.
Types of Testing
Functional, Performance,Load, Security, Reliability, Stress, Volume and others are really specific types of tests designed to uncover specific types of issues, the functional being the behaviour while the others are about the various attributes.
Test Techniques
Black, box, White box are really test techniques that use external behavioural information to design test cases whilst white box uses internal structural information to design test cases. Pair-wise(All-pairs) Orthogonal array are specific techniques to combine of test inputs to generate optimal number of test cases.
All pairs testing
… is a combinatorial method of software testing that, for each pair of input parameters to a system (typically, a software algorithm), tests all possible discrete combinations of those parameters. Using carefully chosen test vectors, this can be done much faster than an exhaustive search of all combinations of all parameters, by “parallelizing” the tests of parameter pairs. (From Wikipedia )
Click here to read in detail.
Orthogonal array testing
… is a black box testing technique that is a systematic, statistical way of software testing. It is used when the number of inputs to the system is relatively small, but too large to allow for exhaustive testing of every possible input to the systems. It is particularly effective in finding errors associated with faulty logic within computer software systems.Orthogonal arrays can be applied in user interface testing, system testing, regression testing, configuration testing and performance testing. The permutations of factor levels comprising a single treatment are so chosen that their responses are uncorrelated and therefore each treatment gives a unique piece of information. The net effects of organizing the experiment in such treatments is that the same piece of information is gathered in the minimum number of experiments.
(From Wikipedia)
Click here to read in detail.
Execution Approach
The terms “Manual testing” and “Automated testing” really indicate the method of execution of test cases, the former implying using a human being whilst the latter is about using a machine to execute the test cases.
Black-box testing
… is a method of software testing that examines the functionality of an application without peering into its internal structures or workings. This method of test can be applied virtually to every level of software testing: unit, integration, system and acceptance. It is sometimes referred to as specification-based testing. (From Wikipedia)
Click here to read in detail.
White-box testing
… is a method of testing software that tests internal structures or workings of an application, as opposed to its functionality. White-box testing can be applied at the unit, integration and system levels of the software testing process. Although traditional testers tended to think of white-box testing as being done at the unit level, it is used for integration and system testing more frequently today. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it has the potential to miss unimplemented parts of the specification or missing requirements. (From Wikipedia)
Click here to read in detail
Model-based testing
… is an application of model-based design for designing and optionally also executing artifacts to perform software testing or system testing. Models can be used to represent the desired behavior of a system under test (SUT), or to represent testing strategies and a test environment. (From Wikipedia)
Click here to read in detail.
Adhoc testing
… an approach to testing a software in a unstructured manner with consciously applying any techniques to design test cases, to break the system using unconventional ways.
Click here to read in detail.
Exploratory testing
… is an approach to software testing that is concisely described as simultaneous learning, test design and test execution. It is defined as”a style of software testing that emphasizes the personal freedom and responsibility of the individual tester to continually optimize the quality of his/her work by treating test-related learning, test design, test execution, and test result interpretation as mutually supportive activities that run in parallel throughout the project.” (From Wikipedia)
Click here to read in detail. Another great read on this is here.
Risk-based testing (RBT)
… is a testing approach which considers risks of the software product as the guiding factor to support decisions in all phases of the test process.
Click here to read the full article.
Shift left testing
While early testing has been highly recommended by software testing and QA experts, there has been a special emphasis on this agile approach of Shift Left testing that recommends reversing the testing approach and involving system/software testing earlier in the lifecycle. Practically, move the testing approach to the left end on the project timeline.
(From Cigniti blog, Click here to read the blog).
Continuous integration (CI)
… the practice of merging all developer working copies to a shared mainline several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day. (From Wikipedia)
Click here to read in detail.
Continuous delivery (CD)
... a software engineering approach in which teams produce software in short cycles, ensuring that the software can be reliably released at any time and, when releasing the software, doing so manually. It aims at building, testing, and releasing software with greater speed and frequency. The approach helps reduce the cost, time, and risk of delivering changes by allowing for more incremental updates to applications in production. A straightforward and repeatable deployment process is important for continuous delivery. CD contrasts with continuous deployment, a similar approach in which software is also produced in short cycles but through automated deployments rather than manual ones. (From Wikipedia)
Click here to read in detail.
Test-driven development (TDD)
… is a software development process that relies on the repetition of a very short development cycle: requirements are turned into very specific test cases, then the software is improved to pass the new tests, only. This is opposed to software development that allows software to be added that is not proven to meet requirements. (From Wikipedia)
Click here to read in detail.
Acceptance test–driven development (ATDD)
… is a development methodology based on communication between the business customers, the developers, and the testers. ATDD encompasses many of the same practices as specification by example (SBE), behavior-driven development (BDD),example-driven development (EDD), and support-driven development also called story test–driven development (SDD). All these processes aid developers and testers in understanding the customer’s needs prior to implementation and allow customers to be able to converse in their own domain language.
ATDD is closely related to test-driven development (TDD). It differs by the emphasis on developer-tester-business customer collaboration. ATDD encompasses acceptance testing, but highlights writing acceptance tests before developers begin coding. (From Wikipedia)
Click here to read in detail.
Behavior-driven development (BDD)
… is a software development process that emerged from test-driven development (TDD).Behavior-driven development combines the general techniques and principles of TDD with ideas from domain-driven design and object-oriented analysis and design to provide software development and management teams with shared tools and a shared process to collaborate on software development. (From Wikipedia)
Click here to read in detail.
Health checks
Sanity testing is primarily a basic evaluation for the system to ascertain if it basically good enough to go ahead so that we may proceed to do thorough testing. Regression testing on the other hand is primarily about if checking prior health of the system has not not compromised due to changes done now. It simply means that was was available and working in the system continues to do so.
About SmartQA The theme of SmartQA is to explore various dimensions of smartness to leapfrog into the new age of software development, to accomplish more with less by exploiting our intellect along with technology. Towards this, we will strive to showcase interesting thoughts, expert industry views through high quality content as articles, posters, videos, surveys outlined as a SmartQA Digest weekly emailer. SmartBites is soundbites from smart people”. Ideas, thoughts and views to inspire you to think differently.
Signup to receive SmartQA digest that has something interesting weekly to becoming smarter in QA and delivering great products.