Overview of frequently asked questions about software testing at interviews and answers to them

The software life cycle (SLC) is the period of time that begins with the advent of the software concept and ends when the use of the software is no longer possible. The software life cycle typically includes the following steps: concept, requirements description, design, implementation, testing, installation and commissioning, operation and support, and, sometimes, decommissioning phase. These phases may overlap or be iterated.

The software development life cycle (SDLC) is a concept that describes a set of activities carried out at each stage (phase) of software development.

Quality Assurance (QA) is a set of measures covering all technological stages of development, production and operation of software and undertaken at different stages of the software life cycle to ensure the required level of quality of the product.

Quality assurance is defined in the ISO 9000: 2005 Standard for Quality Management Systems. Fundamentals and vocabulary ”as“ part of quality management aimed at creating confidence that quality requirements will be met. ”

Quality management is presented in the same standard as “coordinated management of the organization in relation to quality,” and the note states that it “usually includes the development of quality policies and objectives, quality planning, quality management, quality assurance and quality improvement ".

Quality control (QC) is a set of actions taken on the software during the development process to obtain information about its current status in terms of readiness for release, compliance with the recorded requirements and compliance with the stated quality level of this software.

Software testing is a process that contains all life cycle activities, both dynamic and static, related to the planning, preparation and evaluation of a software product and the associated results of work in order to determine that they meet the described requirements and show that they are suitable for the stated purposes and for the determination of defects.

From this definition it becomes clear that software testing involves two different processes:
Validation: proven by objective research results confirming that the requirements for a particular specific use of an application have been met. [ISO 9000]
Verification: proof of the objective results of the research that certain requirements have been met. [ISO 9000]

The purpose of testing (test objective, test target) is the reason or goal of developing and executing a test.

Basic goals:

• provide software cleansing from errors (you can not provide 100% coverage, but you must do everything possible, and ensure that obvious errors are corrected);
• ensure that the software meets the original requirements and specifications;
• provide confidence in the software (users, customers, etc.).

The simple answer is as soon as possible! In more detail:

• when software testing is carried out at an early stage, you can easily influence the design, since its change at this stage is not so expensive than at later stages;
• in turn, the earlier the error is detected, the cheaper it is for the company;
• Testing can also begin before the actual software acquisition (static testing), which is really important, as it reduces the complexity of the dynamic testing phase. There is an opinion that many errors that were found in the dynamic testing stage could and should have been fixed in the static testing stage;
• testing at the early stages (studying requirements, specifications, business cases, etc.) will provide the tester with more knowledge about the software, help to identify logical and technical errors that would affect the software, its final design and cost.

The simple answer is a management decision that is most likely to be made based on:

• test coverage;
• risk analysis;
• deterioration testing.

A more detailed study of this issue will help the coolest article by Michael Bolton in his blog with different there heuristics "piñata" and "dead horse."

Entry criteria are a set of general and specific conditions for continuing the process with a specific task, for example, the testing phase. The purpose of entry criteria is to prevent the start of a task, which may require more (unhelpful) efforts than to eliminate unfinished entry criteria.

Simply put, for you, as a future tester, the entry criteria should be understood as the basic conditions that must be met before you and your team can begin testing.

The exit criteria are a set of general and specific conditions agreed in advance with the interested parties so that the process can be officially considered completed. The goal of the exit criteria is to prevent the opportunity when the task is considered completed, but there are still some incomplete parts of the task. Exit criteria are used for reporting as well as planning when to stop testing.

Simply put, both the entry criteria determine the beginning of the test, and the exit criteria define its end and the software is ready for the next stage of the life cycle (implementation, etc.).

• internal automation tools;
• a series of software products Selenium ;
• MS VS ;
• JUnit ;
• Test Complete ;
• LoadRunner ;
• Testing Anywhere ;
• WinRunner .

In addition - the results of a steep survey on automated testing.

Any problem / software bug caused by the following behavior:

• software crash or display of invalid notification;
• Software provides invalid results;
• Software failed to execute as expected (any deviation from expected results).

The real question to which we are looking for the answer is: do we build the product correctly?

The verification process is performed to ensure that each stage of the software development life cycle (development, testing, etc.) is built on the basis of predefined requirements (requirements) and specifications (specifications) and without any deviations from them. (see number 7)

The real question to which we are looking for the answer is: are we building the right product?

A process that allows a tester to evaluate software after the development stage before transferring it to the customer. In this process, we must make sure that the software is developed based on user needs.

Remember, validation covers the dynamic side of testing, where certain software is tested and evaluated against a given SRS documentation.

A document describing the sequence of actions during the test. Also known as manual testing script.

Basically, software components are small software items that are built from still small units that are in turn integrated together (classes, methods, stored procedures, binary trees, etc.).

Code coverage is an analysis method that determines which parts of the software were tested (covered) with a test suite and which were not, for example, operator coverage, coverage of alternatives or condition coverage.

Code inspection or code review is a systematic check of the program source code to detect and correct errors that go unnoticed during the initial development phase. The purpose of viewing is to improve the quality of the software product and improve the skills of the developer.
During the inspection process, problems such as errors in string formatting, race condition (memory condition), memory leak (buffer overflow) can be found and fixed, which improves the security of the software product. Version control systems make it possible to conduct joint code inspection. In addition, there are special tools for joint code inspection.
Software for automated code inspection simplifies the task of viewing large pieces of code by systematically scanning it to detect the most known vulnerabilities.

A simple term related to a particular SDLC stage. Saying “the code is complete”, we actually mean that its implementation is complete (all software functionality has been successfully implemented). Although even if the code is fully implemented, there are always new errors detected during testing.

A walkthrough is a testing technique used to review the progress of the code by the programmer and the testing team, and during parsing the code is executed using several simple tests to determine its quality and logic.

Debugging is the process of searching, analyzing, and eliminating the causes of failures and errors in software.

To understand where the error occurred, it is necessary:

• find out the current values ​​of variables;
• find out which way the program was run.

There are two complementary debugging technologies.

• Using debuggers - programs that include a user interface for step-by-step program execution: operator by operator, function by function, with stops on some lines of the source code or when a certain condition is reached.
• Output of the current state of the program using output statements located at critical points of the program — on the screen, printer, loudspeaker, or to a file. Outputting debug information to a file is called logging.

Emulation is the reproduction of the work of a program or system (and not some scanty part of it) while preserving its key properties and principles of operation. Emulation executes the program code in an environment familiar to this code, consisting of the same components as the emulated object.

Simulation is a reproduction of the work of the original program purely virtual, on the engine of a special program (a course development tool, for example). The simulation only simulates the execution of the code, and does not copy it, everything is virtually 100%, all the "make-believe".

Consequently:

A software emulator is a full-featured counterpart of the original software, or its version, which may have a number of restrictions on the functionality, capabilities, and behavior of the software.

Software simulator is a model of original software in which the logic of this software is implemented (partially or completely), software behavior is simulated, its interface is copied.

Simulator in the completeness of the functions / parameters taken into account is narrower than the emulator. An object is emulated, and its properties, functions, or behavior are simulated.

The specifications are a text file describing what to test in the test data. It indicates what results the program should receive. The test code finds the real results calculated on the live code. A test engine produces a verification of the specification and the calculated results.

We obtain the specification from the customer by analyzing, examining his requirements and transferring them to a qualitatively new, more detailed level at which the development team will use them.

Coding (coding) - is the process of writing software code, scripts, in order to implement a specific algorithm in a specific programming language.

Some confuse concepts such as programming and coding directly. Coding is only part of programming, along with analysis, design, compilation, testing and debugging, maintenance (In narrow circles, coding can also be called “coding.” However, according to Wiki, this term is rarely used in literature.).

Requirement (requirement) - a set of statements regarding the attributes, properties or qualities of the software system to be implemented. Created in the process of developing software requirements as a result of requirements analysis.

Requirements can be expressed in the form of textual statements and graphical models.

In the classical technical approach, a set of requirements is used at the design stage of software (software). Requirements are also used in the software testing process, since tests are based on certain requirements.

The requirements development phase may have been preceded by a feasibility study, or a conceptual phase of project analysis. The requirements development phase can be broken down into requirements identification (collection, understanding, consideration and clarification of the needs of stakeholders), analysis (integrity and completeness check), specification (requirements documentation) and validation.

The task of testing stability (stability) / reliability (reliability) is to check the performance of the application during long-term (many hours) testing with an average load level. The execution time of operations can play a minor role in this type of testing. At the same time, the absence of memory leaks, server restarts under load, and other aspects affecting precisely the stability of work come out on top.

Criticality (severity) is the importance of the impact of a particular defect on the development or operation of a component or system.

The criticality of the error is determined by the tester, who found a bug, but before that he must answer the following questions:

• How will this error affect the testing process?
• How will this error affect the customer?
• How does this error affect the system?
• How does this error affect the timing of testing?
• Does this error block other tests?
• Etc.

Each company can define its own scale for the degree of criticality (severity), but there are several levels that are used by almost all teams:

• Blocker / show-stopper (blocking) - software or a specific component is not suitable for use / testing (complete failure, system crash, etc.) and there is no workaround.
  Examples: the system crashes when the user presses the start button; the system does not start after damage to the installer; shutdown software caused by hardware failures.
• Critical - the main functionality does not work as it should, there is a workaround that may affect the integrity of the tests.
  Example: software can randomly crash using various functionalities; The software produces inconsistent results, the basic requirements can not be confirmed.
• Major (important) - the defeat of minor functionality, there is no effect on other components, and there is a fast and effective bypass.
  Example: A user cannot use certain functionality directly, but can use it by using access to it from different modules.
• Minor (minor, minor) - a minor impact on a particular place, there is no need to create a workaround, the integrity of the software is not affected.
  Examples: spelling errors, improvements, change request

The priority is the degree of importance assigned to the bug. In other words, it is determined how urgently this error should be corrected.

Priority is a management tool, and before defining it, the latter must answer at least the following questions:

• How does a bug affect the timing?
• How does a bug affect the testing process?
• How does a bug affect the work of other testers?
• What are the costs necessary to eliminate the bug?
• Should we change the software requirements?

Build - an information product prepared for use. Most often this is an executable file (a binary file containing the executable program code).

Suppose the build version number looks like this: 1.35.6.2

1. The first identifier is the major version number.
2. The second identifier is an additional version number.
3. The third identifier is the build number.
4. The fourth identifier is the revision number.

Of course - yes! After all, there are two types of testing methodology (static and dynamic), which allow the tester to start working without a working assembly by the static method, the more such a method is more cost-effective than the “dynamic” one.

Static analysis (static analysis) - is the analysis of software artifacts, such as requirements or software code, conducted without the execution of these software artifacts.

A driver is a software component or testing tool that replaces a component that provides control and / or a call to a component or system.

Harness is a test environment that includes the stubs and drivers needed to conduct a test.

To measure coverage of requirements, it is necessary to analyze product requirements and break them down into points. Optionally, each item is associated with test cases, checking it. The combination of these links is the traceability matrix. Tracing the connection, you can understand exactly what the requirements of the test case checks.

Non-requirements tests are meaningless. Non-test requirements are “white spots”, i.e. Having completed all the created test cases, it is impossible to give an answer whether this requirement is implemented in the product or not.

End-to-end testing is a type of testing where a tester uses software (scripts that examine the entire flow of execution) under conditions that the user most likely has.

In addition, the tests will work by combining several relevant scenarios in the real world:

• software launch in an environment with network communication delays;
• running software in an environment with low resources;
• Running software on other server hardware;
• Run the software in the same environment as some other applications that consume server resources.

Functional testing (functional testing) - is testing based on the analysis of the specification of the functionality of a component or system.

Functional tests are based on functions and features, as well as interactions with other systems, and can be presented at all levels of testing: component or module (Component / Unit testing), integration (Integration testing), system (System testing) and acceptance testing. . Functional types of testing consider the external behavior of the system.

:

1. , , (, , , ). , , (use cases). :
   
   • «» (requirement-based testing) (Test Cases). , , ; ( ), (test cases). .
   • «-» (business-process-based testing) -, . (test scripts), , (use cases).
   
   
2. T (security testing) — . :
   
   • ;
   • ;
   • ;
   :
   
   • xss (cross-site scripting) — (Web ), , , , ;
   • xsrf / csrf (request forgery) — , HTTP , : , , , (, ..), , , ;
   • code injections (sql, php, asp ..) — , , ;
   • server-side includes (ssi) injection — , HTML ;
   • authorization bypass — , .
   
   
3. (interoperability testing) — .
   

:

• , .
• ( 1 ) ( ), , .

(non-functional testing) — , , , , , , .. (, , ).

— , .

, , , . .

:

• ;
• ;
• ;
• ;

— () , . .

:

• ;
• ;
• - ;
• ;

(onversion testing) — , , .

— , (IEEE, W3C ..) .