{
  "id": "enwiki-001351534663",
  "slug": "software-testing-tactics",
  "title": "Software testing tactics",
  "qid": "",
  "lead": "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 (traditionally called by the acronym \"QA\")) and general application of the test method (usually just called \"testing\" or sometimes \"developer testing\").",
  "body": "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 (traditionally called by the acronym \"QA\")) and general application of the test method (usually just called \"testing\" or sometimes \"developer testing\"). ==Installation testing== Installation testing evaluates whether a software system can be successfully installed in its intended environments (including operating systems, hardware, and specific system configurations). This tactic may also verify upgrade and uninstall procedures, as well as check for incorrect configurations and errors during setup. ====Visual testing==== The aim of visual testing is to provide developers with the ability to examine what was happening at the point of software failure by presenting the data in such a way that developers can easily find the required information, and the information is expressed clearly. At the core of visual testing is the idea that showing someone a problem (or a test failure), rather than just describing it, greatly increases clarity and understanding. Visual testing therefore requires the recording of the entire test process – capturing everything that occurs on the test system in video format. Output videos are supplemented by real-time tester input via picture-in-a-picture webcam and audio commentary from microphones. Visual testing provides a number of advantages. The quality of communication is increased drastically because testers can show the problem (and the events leading up to it) to the developer as opposed to just describing it, eliminating the need to replicate test failures in many cases. Developers obtain all necessary evidence of a test failure and can instead focus on identifying and fixing its root cause. Visual testing is particularly well-suited for environments that deploy agile methods in their development of software, since agile methods require closer cooperation between testers and developers, as well as collaboration within small teams. Ad hoc testing and exploratory testing are important methodologies for checking software integrity, because they require less preparation time to implement, while the important bugs can be found quickly. In ad hoc testing, where testing takes place in an improvised, impromptu way, the ability of a test tool to visually record everything that occurs on a system becomes very important in order to document the steps taken to uncover the bug. Visual testing is gathering recognition in customer acceptance and usability testing, because the test can be used by many individuals involved in the development process. For the customer, it becomes easy to provide detailed bug reports and feedback, and for program users, visual testing can record user actions on screen, as well as their voice and image, to provide a complete picture at the time of software failure for the developers. ==Compatibility testing== A common cause of software failure (real or perceived) is a lack of its compatibility with other application software, operating systems (or operating system versions, old or new), or target environments that differ greatly from the original (such as a terminal or GUI application intended to be run on the desktop now being required to become a web application, which must render in a web browser). For example, in the case of a lack of backward compatibility, this can occur because the programmers develop and test software only on the latest version of the target environment, which not all users may be running. This results in the unintended consequence that the latest work may not function on earlier versions of the target environment, or on older hardware that earlier versions of the target environment was capable of using. Sometimes such issues can be fixed by proactively abstracting operating system functionality into a separate program module or library. ==Smoke and sanity testing== Sanity testing determines whether it is reasonable to proceed with further testing. Smoke testing consists of minimal attempts to operate the software, designed to determine whether there are any basic problems that will prevent it from working at all. Such tests can be used as build verification test. ==Functional vs non-functional testing== Functional testing refers to activities that verify a specific action or function of the code. These are usually found in the code requirements documentation, although some development methodologies work from use cases or user stories. Functional tests tend to answer the question of \"can the user do this\" or \"does this particular feature work.\" Non-functional testing refers to aspects of the software that may not be related to a specific function or user action, such as scalability or other performance, behavior under certain constraints, or security. Testing will determine the breaking point, the point at which extremes of scalability or performance leads to unstable execution. Non-functional requirements tend to be those that reflect the quality of the product, particularly in the context of the suitability perspective of its users. ==Continuous testing== 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 includes the validation of both functional requirements and non-functional requirements; the scope of testing extends from validating bottom-up requirements or user stories to assessing the system requirements associated with overarching business goals. ==Software performance testing== Performance testing is generally executed to determine how a system or sub-system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage. Load testing is primarily concerned with testing that the system can continue to operate under a specific load, whether that be large quantities of data or a large number of users. This is generally referred to as software scalability. The related load testing activity of when performed as a non-functional activity is often referred to as endurance testing. Volume testing is a way to test software functions even when certain components (for example a file or database) increase radically in size. Stress testing is a way to test reliability under unexpected or rare workloads. Stability testing (often referred to as load or endurance testing) checks to see if the software can continuously function well in or above an acceptable period. There is little agreement on what the specific goals of performance testing are. The terms load testing, performance testing, scalability testing, and volume testing, are often used interchangeably. Real-time software systems have strict timing constraints. To test if timing constraints are met, real-time testing is used. ==Usability testing== Usability testing is to check if the user interface is easy to use and understand. It is concerned mainly with the use of the application. ==Accessibility testing== Accessibility testing may include compliance with standards such as: Americans with Disabilities Act of 1990 Section 508 Amendment to the Rehabilitation Act of 1973 Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) ==Security testing== Security testing is essential for software that processes confidential data to prevent system intrusion by hackers. The International Organization for Standardization (ISO) defines this as a \"type of testing conducted to evaluate the degree to which a test item, and associated data and information, are protected so that unauthorised persons or systems cannot use, read or modify them, and authorized persons or systems are not denied access to them.\" ==Development testing== \"Development testing\" is a software development process that involves synchronized application of a broad spectrum of defect prevention and detection strategies in order to reduce software development risks, time, and costs. It is performed by the software developer or engineer during the construction phase of the software development lifecycle. Rather than replace traditional QA focuses, it augments it. Development Testing aims to eliminate construction errors before code is promoted to QA; this strategy is intended to increase the quality of the resulting software as well as the efficiency of the overall development and QA process. Depending on the organization's expectations for software development, Development Testing might include static code analysis, data flow analysis, metrics analysis, peer code reviews, unit testing, code coverage analysis, traceability, and other software verification practices. ==A/B testing== A/B testing is basically a comparison of two outputs, generally when only one variable has changed: run a test, change one thing, run the test again, compare the results. This is more useful with more small-scale situations, but very useful in fine-tuning any program. With more complex projects, multivariant testing can be done. ==Concurrent testing== In concurrent testing, the focus is on the performance while continuously running with normal input and under normal operational conditions, as opposed to stress testing, or fuzz testing. Memory leaks, as well as basic faults are easier to find with this method. ==Conformance testing or type testing== In software testing, conformance testing verifies that a product performs according to its specified standards. Compilers, for instance, are extensively tested to determine whether they meet the recognized standard for that language. ==References== ==External links==",
  "categories": [
    "22915009",
    "22920470",
    "22921416",
    "22923558",
    "22937203",
    "22937300",
    "22946277",
    "23031222",
    "23051158",
    "23117742",
    "23118434",
    "2330768",
    "23603337",
    "24745122",
    "26083081",
    "28269686",
    "43006338",
    "68471559"
  ],
  "license": "CC BY-SA 4.0",
  "source_uri": "https://en.wikipedia.org/w/index.php?oldid=1351534663",
  "content_hash": "",
  "created_at": null,
  "updated_at": 1777384604.0,
  "claims": [],
  "contradictions": [],
  "confidence": 0.6,
  "csl": {
    "id": "enwiki-001351534663",
    "type": "webpage",
    "title": "Software testing tactics",
    "author": [
      {
        "family": "Anticloud FZ LLE",
        "literal": "Anticloud FZ LLE"
      }
    ],
    "container-title": "encyclopegia.org",
    "publisher": "Anticloud FZ LLE",
    "publisher-place": "Dubai, United Arab Emirates",
    "URL": "https://encyclopegia.org/a/software-testing-tactics",
    "issued": {
      "date-parts": [
        [
          2026,
          11,
          14
        ]
      ]
    },
    "accessed": {
      "date-parts": [
        [
          2026,
          11,
          14
        ]
      ]
    },
    "license": "CC BY-SA 4.0",
    "DOI": "eo1:enwiki-001351534663",
    "isBasedOn": "https://en.wikipedia.org/w/index.php?oldid=1351534663",
    "note": "Immutable snapshot enwiki-001351534663"
  }
}