Blog

All articles

Software testing. Part 4. The principles, types of software testing and so on

This article is devoted to the principles of software testing, static and dynamic testing, research and ad-hoc testing as well as the life cycle of the bug, stages of software development, decision table, qa / qc / test engineer and link diagram.

Principles of testing

Principle 1 – Testing shows the presence of defects

Testing can show that defects are present, but can not prove that they are not. Testing reduces the likelihood of defects in the software, but even if defects have not been detected, this does not prove its correctness.

Principle 2 – Exhaustive testing is impossible

Full testing using all combinations of inputs and preconditions is physically impracticable, except for trivial cases. Instead of exhaustive testing, risk analysis and prioritization should be used to more accurately focus testing efforts.

Principle 3 – Early testing

To find defects as early as possible, testing activities should be initiated as early as possible in the life cycle of the software or system development, and should be focused on specific goals.

Principle 4 – Defects clustering

The testing effort should be concentrated in proportion to the expected, and later real, defect density of the modules. As a rule, most of the defects detected during testing or leading to the main number of system failures are contained in a small number of modules.

Principle 5 – Pesticide paradox

If the same tests are run many times, eventually this set of test scenarios will no longer find new defects. To overcome this “pesticide paradox”, test scenarios should be regularly reviewed and adjusted, new tests must be versatile to cover all software components or systems and find as many defects as possible.

Principle 6 – Testing is concept depending

Testing is performed in different ways depending on the context. For example, software in which security is critical is tested differently than an e-commerce site.

Principle 7 – Absence-of-errors fallacy

Detecting and fixing defects will not help if the created system does not suit the user and does not meet his expectations and needs.

Static and dynamic testing

Static testing differs from dynamic testing in that it is performed without running the product code. Testing is carried out by analyzing code (code review) or compiled code. The analysis can be done either manually or with the help of special tools. The purpose of the analysis is to identify early errors and potential problems in the product. Also for static testing is the testing of the specification and other documentation.

Research / ad-hoc testing

The simplest definition of research testing is the development and execution of tests at the same time. What is the opposite of the scenario approach (with its predetermined testing procedures, whether manual or automated). Research tests, unlike scenario tests, are not defined in advance and are not performed in strict accordance with the plan.

The difference between ad hoc and exploratory testing is that theoretically, anyone can ad hoc, but for carrying out exploratory it is necessary to master and master certain techniques. Note that certain techniques are not just testing techniques.

Requirements

Requirements is a specification (description) of what should be implemented.

Requirements describe what needs to be realized, without detailing the technical side of the solution. What, not how.

Specification requirements:

  • Correctness
  • Unambiguousness
  • Completeness of the set of requirements
  • Consistency of the set of requirements
  • Verifiability (testability)
  • Traceability
  • Understandability

Life cycle of a bug

Stages of software development

The stages of software development are the stages that software development teams go through before the program becomes available to a wide range of users. Software development begins with the initial stage of development (the “pre-alpha” stage) and continues with the stages at which the product is modified and modernized. The final stage of this process is the release to the market of the final version of the software (“public release”).

The software product undergoes the following steps:

  • analysis of requirements for the project;
  • designing;
  • implementation;
  • product testing;
  • implementation and support.

Each software development stage is assigned a specific sequence number. Also each stage has its own name, which characterizes the readiness of the product at this stage.

Software development life cycle:

  • Pre-alpha
  • Alpha
  • Beta
  • Release Candidate
  • Release
  • Post release

Decision table

Decision table is an excellent tool for ordering complex business requirements that must be implemented in the product. The decision tables provide a set of conditions, the simultaneous execution of which should lead to a specific action.

QA / QC / Test Engineer

Thus, we can build a hierarchy of quality assurance processes: Testing is part of QC. QC is part of QA.

Link diagram

The link diagram is a quality management tool based on the definition of logical relationships between different data. This tool is used to compare the causes and effects of the problem under study.

Summarizing such a detailed analysis of the software testing topic , we can say that this process is a very important and indispensable stage in the development of a product. The work of the test engineer, if it is properly and step-by-step, helps to identify as many bugs and shortcomings as possible and release the most efficient final product.