Sanity check

Last updated

A sanity check or sanity test is a basic test to quickly evaluate whether a claim or the result of a calculation can possibly be true. It is a simple check to see if the produced material is rational (that the material's creator was thinking rationally, applying sanity). The point of a sanity test is to rule out certain classes of obviously false results, not to catch every possible error. A rule-of-thumb or back-of-the-envelope calculation may be checked to perform the test. The advantage of performing an initial sanity test is that of speedily evaluating basic function.

Contents

In arithmetic, for example, when multiplying by 9, using the divisibility rule for 9 to verify that the sum of digits of the result is divisible by 9 is a sanity test—it will not catch every multiplication error, but is a quick and simple method to discover many possible errors.

In computer science, a sanity test is a very brief run-through of the functionality of a computer program, system, calculation, or other analysis, to assure that part of the system or methodology works roughly as expected. This is often prior to a more exhaustive round of testing.

Use in different fields

Mathematical

A sanity test can refer to various orders of magnitude and other simple rule-of-thumb devices applied to cross-check mathematical calculations. For example:

Physical

Software development

In software development, a sanity test (a form of software testing which offers "quick, broad, and shallow testing" [1] ) evaluates the result of a subset of application functionality to determine whether it is possible and reasonable to proceed with further testing of the entire application. [2] Sanity tests may sometimes be used interchangeably with smoke tests [3] insofar as both terms denote tests which determine whether it is possible and reasonable to continue testing further. On the other hand, a distinction is sometimes made that a smoke test is a non-exhaustive test that ascertains whether the most crucial functions of a programme work before proceeding with further testing whereas a sanity test refers to whether specific functionality such as a particular bug fix works as expected without testing the wider functionality of the software.[ citation needed ] In other words, a sanity test determines whether the intended result of a code change works correctly while a smoke test ensures that nothing else important was broken in the process. Sanity testing and smoke testing avoid wasting time and effort by quickly determining whether an application is too flawed to merit more rigorous QA testing, but needs more developer debugging.

Groups of sanity tests are often bundled together for automated unit testing of functions, libraries, or applications prior to merging development code into a testing or trunk version control branch, [4] for automated building, [5] or for continuous integration and continuous deployment. [6]

Another common usage of sanity test is to denote checks which are performed within programme code, usually on arguments to functions or returns therefrom, to see if the answers can be assumed to be correct. The more complicated the routine, the more important that its response be checked. The trivial case is checking to see whether the return value of a function indicated success or failure, and to therefore cease further processing upon failure. This return value is actually often itself the result of a sanity check. For example, if the function attempted to open, write to, and close a file, a sanity check may be used to ensure that it did not fail on any of these actions—which is a sanity check often ignored by programmers. [7]

These kinds of sanity checks may be used during development for debugging purposes and also to aid in troubleshooting software runtime errors. For example, in a bank account management application, a sanity check will fail if a withdrawal requests more money than the total account balance rather than allowing the account to go negative (which wouldn't be sane). Another sanity test might be that deposits or purchases correspond to patterns established by historical data—for example, large purchase transactions or ATM withdrawals in foreign locations never before visited by the cardholder may be flagged for confirmation.[ citation needed ]

Sanity checks are also performed upon installation of stable, production software code into a new computing environment to ensure that all dependencies are met, such as a compatible operating system and link libraries. When a computing environment has passed all the sanity checks, it's known as a sane environment for the installation programme to proceed with reasonable expectation of success.

A "Hello, World!" program is often used as a sanity test for a development environment similarly. Rather than a complicated script running a set of unit tests, if this simple programme fails to compile or execute, it proves that the supporting environment likely has a configuration problem that will prevent any code from compiling or executing. But if "Hello world" executes, then any problems experienced with other programmes likely can be attributed to errors in that application's code rather than the environment.

The Association for Computing Machinery, [8] and software projects such as Android, [9] MediaWiki [10] and Twitter, [11] discourage use of the phrase sanity check in favour of other terms such as confidence test, coherence check, or simply test, as part of a wider attempt to avoid ableist language and increase inclusivity.

See also

Related Research Articles

<span class="mw-page-title-main">Acceptance testing</span> Test to determine if the requirements of a specification or contract are met

In engineering and its various subdisciplines, acceptance testing is a test conducted to determine if the requirements of a specification or contract are met. It may involve chemical tests, physical tests, or performance tests.

Software testing is the act of examining the artifacts and the behavior of the software under test by verification and validation. Software testing can also provide an objective, independent view of the software to allow the business to appreciate and understand the risks of software implementation. Test techniques include, but are not limited to:

<span class="mw-page-title-main">Digital electronics</span> Electronic circuits that utilize digital signals

Digital electronics is a field of electronics involving the study of digital signals and the engineering of devices that use or produce them. This is in contrast to analog electronics which work primarily with analog signals. Despite the name, digital electronics designs includes important analog design considerations.

In computer programming, a type system is a logical system comprising a set of rules that assigns a property called a type to every term. Usually the terms are various language constructs of a computer program, such as variables, expressions, functions, or modules. A type system dictates the operations that can be performed on a term. For variables, the type system determines the allowed values of that term. Type systems formalize and enforce the otherwise implicit categories the programmer uses for algebraic data types, data structures, or other components.

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.

Execution in computer and software engineering is the process by which a computer or virtual machine reads and acts on the instructions of a computer program. Each instruction of a program is a description of a particular action which must be carried out, in order for a specific problem to be solved. Execution involves repeatedly following a 'fetch–decode–execute' cycle for each instruction done by control unit. As the executing machine follows the instructions, specific effects are produced in accordance with the semantics of those instructions.

<span class="mw-page-title-main">Systems development life cycle</span> Systems engineering terms

In systems engineering, information systems and software engineering, the systems development life cycle (SDLC), also referred to as the application development life cycle, is a process for planning, creating, testing, and deploying an information system. The SDLC concept applies to a range of hardware and software configurations, as a system can be composed of hardware only, software only, or a combination of both. There are usually six stages in this cycle: requirement analysis, design, development and testing, implementation, documentation, and evaluation.

In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes. 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 is critical for continuous delivery and continuous testing.

In mathematics, the digit sum of a natural number in a given number base is the sum of all its digits. For example, the digit sum of the decimal number would be

<span class="mw-page-title-main">Continuous integration</span> Software development practice based on frequent submission of granular changes

In software engineering, continuous integration (CI) is the practice of merging all developers' working copies to a shared mainline several times a day. Nowadays it is typically implemented in such a way that it triggers an automated build with testing. Grady Booch first proposed the term CI in his 1991 method, although he did not advocate integrating several times a day. Extreme programming (XP) adopted the concept of CI and did advocate integrating more than once per day – perhaps as many as tens of times per day.

<span class="mw-page-title-main">Integer overflow</span> Computer arithmetic error

In computer programming, an integer overflow occurs when an arithmetic operation attempts to create a numeric value that is outside of the range that can be represented with a given number of digits – either higher than the maximum or lower than the minimum representable value.

In software testing, a test harness is a collection of stubs and drivers configured to assist with the testing of an application or component. It acts as imitation infrastructure for test environments or containers where the full infrastructure is either not available or not desired.

In software development, functional testing is a quality assurance (QA) process and a type of black-box testing that bases its test cases on the specifications of the software component under test. Functions are tested by feeding them input and examining the output, and internal program structure is rarely considered. Functional software testing is conducted to evaluate the compliance of a system or component with specified functional requirements. Functional testing usually describes what the system does.

Manual testing is the process of manually testing software for defects. It requires a tester to play the role of an end user where by they use most of the application's features to ensure correct behaviour. To guarantee completeness of testing, the tester often follows a written test plan that leads them through a set of important test cases.

There is considerable variety among software testing writers and consultants about what constitutes responsible software testing. Proponents of a context-driven approach consider much of the writing about software testing to be doctrine, while others believe this contradicts the IEEE 829 documentation standard.

API testing is a type of software testing that involves testing application programming interfaces (APIs) directly and as part of integration testing to determine if they meet expectations for functionality, reliability, performance, and security. Since APIs lack a GUI, API testing is performed at the message layer. API testing is now considered critical for automating testing because APIs now serve as the primary interface to application logic and because GUI tests are difficult to maintain with the short release cycles and frequent changes commonly used with Agile software development and DevOps.

Continuous testing is the process of executing automated tests as part of the software delivery pipeline to obtain immediate feedback on the business risks associated with a software release candidate. Continuous testing was originally proposed as a way of reducing waiting time for feedback to developers by introducing development environment-triggered tests as well as more traditional developer/tester-triggered tests.

In computer programming and software testing, smoke testing is preliminary testing or sanity testing to reveal simple failures severe enough to, for example, reject a prospective software release. Smoke tests are a subset of test cases that cover the most important functionality of a component or system, used to aid assessment of whether main functions of the software appear to work correctly. When used to determine if a computer program should be subjected to further, more fine-grained testing, a smoke test may be called a pretest or an intake test. Alternatively, it is a set of tests run on each new build of a product to verify that the build is testable before the build is released into the hands of the test team. In the DevOps paradigm, use of a build verification test step is one hallmark of the continuous integration maturity stage.

In software deployment, an environment or tier is a computer system or set of systems in which a computer program or software component is deployed and executed. In simple cases, such as developing and immediately executing a program on the same machine, there may be a single environment, but in industrial use, the development environment and production environment are separated, often with several stages in between. This structured release management process allows phased deployment (rollout), testing, and rollback in case of problems.

This article discusses a set of tactics useful in software testing. It is intended as a comprehensive list of tactical approaches to Software Quality Assurance (more widely colloquially known as Quality Assurance and general application of the test method.

References

  1. Fecko, Mariusz A.; Lott, Christopher M. (October 2002). "Lessons learned from automating tests for an operations support system" (PDF). Software: Practice and Experience. 32 (15): 1485–1506. doi:10.1002/spe.491. S2CID   16820529. Archived from the original (PDF) on 17 July 2003.
  2. Sammi, Rabia; Masood, Iram; Jabeen, Shunaila (2011). Zain, Jasni Mohamad; Wan Mohd, Wan Maseri bt; El-Qawasmeh, Eyas (eds.). "A Framework to Assure the Quality of Sanity Check Process". Software Engineering and Computer Systems. Communications in Computer and Information Science. Berlin, Heidelberg: Springer. 181: 143–150. doi:10.1007/978-3-642-22203-0_13. ISBN   978-3-642-22203-0.
  3. ISTQB® Glossary for the International Software Testing Qualification Board® software testing qualification scheme, ISTQB Glossary International Software Testing Qualification Board
  4. http://webhotel4.ruc.dk/~nielsj/research/publications/freebsd.pdf [ bare URL PDF ]
  5. Hassan, A. E. and Zhang, K. 2006. Using Decision Trees to Predict the Certification Result of a Build. In Proceedings of the 21st IEEE/ACM international Conference on Automated Software Engineering (September 18 – 22, 2006). Automated Software Engineering. IEEE Computer Society, Washington, DC, 189–198.
  6. http://jitm.ubalt.edu/XXIX-2/article4.pdf [ bare URL PDF ]
  7. Darwin, Ian F. (January 1991). Checking C programs with lint (1st ed., with minor revisions. ed.). Newton, Mass.: O'Reilly & Associates. p. 19. ISBN   0-937175-30-7 . Retrieved 7 October 2014. A common programming habit is to ignore the return value from fprintf(stderr, ...
  8. "Words Matter". 2020-11-20. Retrieved 2023-06-29.
  9. "Coding with respect". Android Open Source Project. 2022-11-16. Retrieved 2023-01-23.
  10. "Inclusive language/en-gb - MediaWiki". www.mediawiki.org. Retrieved 2023-01-23.
  11. "Twitter Engineering". Twitter. Retrieved 2023-01-23.