Review common questions on software testing at job interviews and answers

the Main purpose of this article is to help to overcome the fear that arises from the testers (both beginners and experienced) for the upcoming interviews in connection with ignorance of the future.

A secondary goal is to gather the main issues that most likely will be asked at the interview. As a novice tester, I have already accumulated some experience of preparing to interview for the position, and I can see that even specialized QA forums don't cope with this goal, and maybe put it in front of him at all.

The list of issues of course not final and does not claim to ritual, and acts only as a guide in the preparation of specialists with testing.

Actually a question:

the
1. Explain the term "life cycle software".

   the Life cycle of the software (SLC) is the period of time beginning with the moment of conception and ending when the use is no longer possible. The lifecycle of software typically involves the following stages: concept, requirements specification, design, implementation, testing, installation and commissioning, maintenance and support and, sometimes, the stage of decommissioning. These phases can overlap each other or be performed iteratively.
   
   
   
the
2. Explain the term "life cycle software development".

   Lifecycle software development (SDLC) is a concept that describes a set of activities performed at each stage (phase) of software development.
   
   
   
the
3. Explain the advantage of using a life cycle model of software development (SDLC).

   the
   • provide a framework for the project (methodology, activity...);
   the
   • provide a visualization of the progress of the project;
   the
   • help the company in effective and successful completion of the project (cost reduction, reducing time for development and testing, improving the quality of the final product);
   the
   • reduce risks associated with software development process;
   the
   • providing a special mechanism for tracking the progress of the project.

   
   
   
   
the
4. What are the main phases of the life cycle model of software development?

   the
   1. of the decision (idea) about the necessity of creation;
   the
   2. Gathering and analyzing requirements;
   the
   3. Design (System and software) based on the requirements;
   the
   4. Coding on the basis of the design of the system;
   the
   5. Test;
   the
   6. Introduction to user experience;
   the
   7. Support (including fixation found in the user environment errors).
   the
   8. decommissioning (rarely).

   
   
   
   
the
5. Explain what is quality Assurance (Quality Assurance)?

   quality Assurance (QA) is a set of activities covering all technological stages of development, release and operations, and undertaken at different stages of the life cycle, to ensure the required level of quality of the product.
   
   Quality assurance is defined in ISO 9000:2005 "quality management System. Basic provisions and vocabulary" as "part of quality management focused on providing confidence that quality requirements will be fulfilled".
   
   Quality management in this standard is presented as "coordinated activities to direct and control an organization with regard to quality" and in a note says that it "usually involves the development of policies and objectives in the field of quality, quality planning, quality control, quality assurance and quality improvement".
   
   
   
the
6. Explain what a quality Control (Quality Control)?

   quality Control (QC) is the set of actions undertaken over the development process, for information about his current status in the aspects of readiness for issue, compliance with fixed requirements and compliance with the declared level of quality.
   
the
7. Explain what is software testing?

   Testing is the process, containing all activity life cycle, both dynamic and static for the planning, preparation and evaluation of a software product and the associated results of operations to determine that they meet the described requirements, and to show that they are suitable for the stated purposes and definitions of the defects.
   
   From this definition it becomes clear that software testing involves two different processes:
   Validation (validation): proven objective results of the study confirm that the specific requirements for a particular use application was made. [ISO 9000]
   Verification (verification): proven objective results of the study confirm that certain requirements have been met. [ISO 9000]
   
   
   
the
8. What are the main goals of software testing?

   testing Purpose (test objective, test target) — this is the reason or the purpose of development and test execution.
   
   Main purpose:
   the

   the
   • to provide a purification from errors (You can't provide 100% coverage, but You need to do everything possible to ensure that obvious errors have been corrected);
   the
   • to convince that meets the original requirements and specifications;
   the
   • to provide confidence in the software (users, customers, etc.).

   
   
   
   
the
9. When should I start testing?

   the Simple answer is as soon as possible! More details:
   the

   the
   • when testing is conducted at an early stage, you can easily affect the design, as change at this stage is not so costly than at later stages;
   the
   • in turn, the sooner an error is detected, the cheaper it costs the company;
   the
   • testing can begin prior to actual receipt BY (static testing), what is really important, as it reduces the complexity of the spending dynamic the testing phase. There is a perception that many of the errors that are found in the stage of dynamic testing, could and should have been recorded under static testing;
   the
   • testing in the early stages (study of requirements, specifications, business cases, etc.) will provide the tester more knowledge about the SOFTWARE will help to detect logical and technical errors that would affect the software, its ultimate design and value.

   
   
   
   
the
10. When to stop testing?

    the Simple answer is the management solution which is likely to be made based on:
    the

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

    
    A more detailed study of this question will help the coolest Michael Bolton in his blog there are different heuristics "piñatas" and "dead horse".
    
    
    
the
11. What are the main levels of software testing?

    Component (component)/ a unit testing (module, unit testing) is testing of the individual components [IEEE 610];

    Integration testing (integration testing) is testing that is performed to detect defects in the interfaces and interaction between integrated components or systems.
    
    You should also understand what is big-bang testing top-down, bottom-up and incremental testing;
    
    

    System testing (system testing) is the process of testing the system as a whole to verify that it meets specified requirements;

    Acceptance testing (acceptance testing) is a formal test in relation to the needs, requirements and business processes of the user, for the purpose of determining compliance with system acceptance criteria (exit criteria that must be met for a component or system, in order to be accepted by the user, customer or other authorized person) [IEEE 610] why follow such species, of which it is desirable not to forget:
    the

    1. user acceptance testing (user acceptance testing);
    the
    2. production acceptance testing (factory acceptance testing) — acceptance testing is conducted on the side of software product developer and carried out by employees of the supplier in order to determine or not a component or system both software and hardware requirements;
    the
    3. third-party acceptance testing (site acceptance testing) is user acceptance testing or the customer on your side. Conducted to determine how compliance to the business process and to ensure that the system or component meets the needs of the user or customer. Usually includes testing how the software and technical resources;
    the
    4. operational acceptance testing (operational acceptance testing) is the operational testing phase acceptance testing, usually performed by a user and/or staff with administrator access in the production environment (possibly stimulirovannoe), focusing on functional aspects (resilience, behavior resources, ustanavlivaet and technical compliance).
    
    

    alpha testing (alpha testing) is simulated or actual operational testing by potential users/customers or an independent test team on the side of the developers, but outside the innovating organization. Alpha testing is often applied to box as internal acceptance testing;

    Beta testing (beta testing) — this operational test potential and/or existing clients/customers on the outside in no way associated with the developers, to determine whether a component or system satisfies the requirements of the client/customer and fits the business processes. Beta testing is often conducted as a form of external acceptance testing of finished software to get feedback from the market;

    
    
    
    
the
12. What is the entry criteria?

    entry Criteria (entry criteria) is a set of General and specific conditions to proceed with a particular task, e.g. test phase. The purpose of criteria of an entrance — preventing the beginning of a task which may require more (useless) work than on addressing not passed the criteria of the entrance.
    
    To put it simply for You, as a future tester, entry criteria should be understood as the basic conditions that must be met before You and Your team can begin testing.
    
    
    
the
13. what are some examples that explain the entry criteria for testing.

    the
    • all the defects that apply to the early stages (design) are closed and verified;
    the
    • code is tested through Unit tests.
    the
    • basic functionality is ready for testing;
    the
    • there is documentation that defines the requirements;

    all testers are familiar with the architecture;

    all testers are familiar with the objectives of the project; the

    • prepared the test environment;
    the
    • available for use build;
    the
    • approved the test plan and/or test cases.

    
    
    
    
the
14. What is exit criteria?

    exit Criteria (exit criteria) are a set of General and specific conditions agreed in advance with stakeholders to ensure that the process could officially be considered complete. The purpose of exit criteria is to prevent a task from being considered completed when there are still outstanding parts of the task. Exit criteria are used to report against and to plan when to stop testing.
    Simply put, as entry criteria define the beginning of testing, and exit criteria define its end and ready for the next stage of the life cycle (introduction, etc.).
    
    
    
the
15. what are some examples that explain the exit criteria for testing.

    the
    • all predetermined region ON how "risky" tested and such status is lowered/removed;
    the
    • all errors are thoroughly documented and communicated to the management/shareholders/customers;
    the
    • all tests with high priority are passed and, accordingly, are marked as "Pass";
    the
    • documentation requirements SRS (requirements Specification);
    the
    • STR is approved by the project owner;
    the
    • tested architecture;
    the
    • no serious or critical errors do not remain open;
    the
    • 90-95% of all tests done.

    
    
    
    
the
16. what are some tools that can be used for automated testing.

    the
    • internal automation tools;
    the
    • series software Selenium;
    the
    • MS VS;
    the
    • JUnit;
    the
    • Test Complete;
    the
    • LoadRunner;
    the
    • Testing Аnywhere;
    the
    • WinRunner.

    
    In addition, results cool survey for automated testing.
    
    
    
the
17. How do you explain the Bug/Defect/Error in?

    Any problem/bug in that caused by the following behaviour:
    the

    the
    • a breakdown or display void notice;
    the
    • provides invalid results;
    the
    • failed to perform as expected (any deviation from the expected results).

    
    
    
    
the
18. Explain the verification process.

    the Real question we seek the answer: if we are building the product right?
    
    The process of verification (verification) is performed to ensure that each stage of the development lifecycle (development, testing, etc.) based on predefined requirements (requirements) and specifications (specifications) and without any deviations from them. (see # 7)
    
    
    
the
19. Describe the different activities of the verification process.

    the
    • analysis of various aspects of testing (time, resources, personnel, cost, testing tools, etc.);

    coating the (statement coverage) — percentage of operators performed a set of tests to their total; the coverage conditions (condition coverage) — percentage of outcomes of conditions that were tested by the test Suite. 100% coverage conditions require that each separate condition in each expression of the solution was checked as True and False; the coverage alternatives (decision coverage) is the percentage of the results of the alternatives that has been tested by the test Suite. One hundred percent coverage decisions involves one hundred percent coverage of the branches and one hundred percent coverage of operators;

    peer review (review) — assessment of the condition of the product or project to establish discrepancies from planned results and to propose for improvement. Examples of review include management review, informal review, technical analysis, inspection and analysis;

    parse (walkthrough) — this is a walkthrough conducted by the author of the document to gather information and ensure a common understanding of the content of the document;

    inspection (inspection) — a type of equitable analysis based on visual inspection of documents to find errors. For example, violations of development standards and lack of documentation of a higher level. Most formal methods of peer review and therefore always based on a documented procedure.

    
    
the
20. Give examples of verification depending on the test levels. (see No. 11)

    the
    1. unit testing (unit testing):
       -verification of the implementation of the software design.
    the
    2. Integration testing (integration testing):
       -testing the integration between all relevant parts to that as you move to the next level (system).
    the
    3. System testing (system testing):
       -ensuring system compliance with predefined requirements and specifications.
    the
    4. user Acceptance testing (acceptance testing):
       -make sure your system meets the requirements of the client.

    
    
    
    
the
21. Explain the validation process.

    the Real question we seek the answer: if we are building the right product?
    
    A process that allows the tester to evaluate the software after development to transfer it to the customer. In this process, we must ensure that developed based on user needs.
    
    Remember, the validation covers the dynamic side of testing, where certain software is tested and evaluated contrary to the given SRS document.
    
    
    
the
22. what are some reasons that lead to bugs in the software.

    the
    • human error (process design and process implementation);
    the
    • the requirements change while the software under test;
    the
    • lack of understanding of the requirements and specifications;
    the
    • lack of time;
    the
    • bad prioritization testing;
    the
    • bad orientation in versions;

    complexity.

    
    
    
    
the
23. What is the testing procedure (Test Procedure)?

    a Document describing the sequence of actions when performing the test. Also known as a manual test script.
    
    
    
the
24. What is software component?

    In General, software components are small items that are constructed from even smaller units, which in turn are integrated together (classes, methods, stored procedures, binary trees, etc.).
    
    
    
the
25. Explain the code Coverage.

    code Coverage (code coverage) is an analysis method that determines which parts have been tested (covered) by the test Suite and which are not, for example, plating operators, plating alternatives or coating conditions.
    
    
    
the
26. Explain the On code.

    On code (code inspection) or code review (code review) is systematic examination of source code program with the aim of detecting and correcting errors that went undetected in the initial phase of development. The purpose of viewing is to improve the quality of the product and improving the skills of the developer.
    In the process of inspection can be found and eliminated problems such as errors in format strings, race conditions (race conditions), memory leaks (memory leak) and a buffer overflow (buffer overflow), which improves the safety of a software product. The version control system provide an opportunity for a joint inspection of the code. In addition, there are special tools for joint inspection of the code.
    Software for automated code instrumentation simplifies the task of viewing large chunks of code, systematically scanning it to detect most known vulnerabilities.
    
    
    
the
27. What does the phrase Code complete?

    Simple term pertaining to a specific phase of SDLC. Speaking of "code complete", we actually mean that its implementation is complete (all functionality is implemented successfully). Although even if the code is fully implemented, there are always new bugs discovered during testing.
    
    
    the
28. What is the parsing (walkthrough) code?

    Parse (walkthrough) is a testing methodology used to review the implementation of the code by the programmer and the test team, during the parsing code runs a few simple tests to determine its quality and logic.
    
    
    
the
29. What is debugging?

    Debug (debugging) is a process of search, analysis and elimination of causes of failures and errors.
    
    To understand where the error occurred, we have:
    the

    the
    • to know the current values of variables;
    the
    • to figure out which way was carried out the program.

    
    There are two complementary debugging technologies.
    the

    the
    • Using debuggers — programs that include a user interface to step through a program: operators, function by function, with stops on some lines of source code or when reaching certain conditions.
    the
    • display the current state of a program using located at critical points of the program operators of the output to the screen, printer, loudspeaker or to a file. Outputting debug information to a file called logging.

    
    
    
    
the
30. What is an emulator and a simulator?

    Emulation is the playback operation of the program or system (and not some miserable part of it) with the preservation of key properties and principles. Emulation executes the code in the usual code for this environment, consisting of the same components that the emulated object.
    
    Simulation is the reproduction of the program operation of the original purely virtual, the engine is a special program (a means of course development, for example). The simulation only simulates the execution of the code, not copy it, virtual all 100%, all the "fun".
    
    Therefore:
    
    Emulator is a complete analogue of the original, or a version of it, which may provide some limitations on functionality, capability, and behavior.
    
    Simulator is the original model, which is implemented in the operating logic of this SOFTWARE (partially or fully), the simulated behavior is copied its interface.
    
    Simulator the completeness of the functions/count of parameters is narrower than the emulator. The object is emulated, and simulated its properties, function, or behavior.
    
    
    
the
31. What specification?

    Specification (specifications) is a text file with a description of what you want to test in the test data. It specifies what the results need to program. The test code finds a real, live code on the calculated results. And the test engine produces a reconciliation specifications and computed results.
    
    The specification received from the customer by analyzing, examining his requirements and translating them to a new, more detailed the level at which they will use team developer.
    
    
    
the
32. return to top

    Encoding (coding) is the process of writing software code, scripts, to implement a specific algorithm in a specific programming language.
    
    Some confuse concepts such as programming and coding. Coding is only part of the programming, along with analysis, designing, compiling, testing and debugging, maintenance (In the narrow circles of encoding can also be called "coding". However, if you believe the Wiki, in the literature this term is rarely used.).
    
    
    
the
33. What is the requirement?

    Requirement (requirement) — a set of statements concerning the attributes, properties or qualities of the software system to be implemented. Are in the process of developing software requirements, as a result of the requirements analysis.
    Requirements can be expressed in the form of textual statements and graphic patterns.
    
    In classical technical approach, the set of requirements used in the design stage of the software (SOFTWARE). Requirements are also used in the process of testing, as tests are based on specific requirements.
    
    Milestone requirements may have been preceded by a feasibility study or a conceptual analysis phase of the project. The development phase requirements can be broken down into the identification of requirements (gathering, understanding, reviewing and clarifying the needs of stakeholders), analysis (integrity and completeness), specification (documenting the requirements) and validation.
    
    
    
the
34. What is stability testing?

    Task test stability (stability) / reliability (reliability) is to check application performance during prolonged (hours) testing with a medium level of exertion. The operations can play in this type of testing a secondary role. Thus on the first place there is the absence of memory leaks, restarts of the servers under load and other aspects of the impact is on the stability.
    
    
    
the
35. Tell us about the criticality (severity) of the bug and generally accepted levels of criticality.

    Criticality (severity) is the importance of the impact of specific defect in the design or operation of a component or system.
    
    The criticality of the error is determined by the tester who found the bug, but before that he needs to answer the following questions:
    the

    the
    • As this error will affect the testing process?
    the
    • As this error will affect the customer?
    the
    • As this error affects the system?
    the
    • As this error affects the timing of the test?
    the
    • Blocks if this bug other tests?
    the
    • , etc.

    
    Each company can determine their own scale for severity (severity), but there are a few levels that are used by almost all commands:
    the

    Blocker/show stopper (blocking) or a specific component is not suitable for use/testing (a complete failure, a system crash, etc.) and no bypass.
    Examples: system will collapse when the user clicks the "start" button; the system does not start after injury to the installer; shutdown caused by hardware failures.

    Critical (critical) — the main functionality is not working as it should, there is a workaround that can affect the integrity of the test.
    Example: can randomly use Android trainer for running, using various features; produces conflicting results, the basic requirements unable to confirm.

    Major (important) — lose minor functionality, there is no impact on other components is quick and active bypass.
    Example: the User cannot use certain functionality directly, but can use it, taking advantage of access to it from different modules.

    Minor (minor, minor) — minor impacts on a specific location, there is no need to create a workaround integrity is not affected.
    Examples: spelling errors, enhancements, request for change

    
    
    
    
the
36. Tell us about the priority of the bug.

    Priority (priority) is the degree of importance assigned to bug. In other words, determines how urgently this bug needs to be fixed.
    
    Priority management tool, and before his identification of the latter must meet at least the following questions:
    the

    the
    • As the bug affects the timing?
    the
    • As the bug affects testing process?
    the
    • As the bug affects the work of other testers?
    the
    • Should we change the requirements?

    
    
    
    
the
37. What is Assembly?

    Build (build) — prepared for the use of the information product. Most often it is the executable (the binary file containing the executable code of the program).
    
    Suppose that the Assembly version number looks like this: 1.35.6.2
    

    the
    1. First identifier, the major version number.
    the
    2. Second identifier optional version number.
    the
    3. Third identifier, the build number.
    the
    4. Fourth identifier is the revision number.

    
    
    
    
the
38. is it Possible to start testing without a working build?

    Definitely, Yes! After all, there are two types of testing methodologies (static and dynamic) that allow the tester to start work without a working build of a static method, moreover, this method is more cost effective than "dynamic".
    
    
    
the
39. What is static analysis?

    Static analysis (static analysis) is the analysis of software artifacts such as requirements or code, carried out without execution of these software artifacts.
    
    
    
the
40. What is a test driver and test harness?

    Driver (driver) is a component or test tool that replaces a component that provides management and/or the calling of a component or system.
    
    Tying (harness) — this is a test environment that includes stubs and drivers necessary for the test.
    
    
    
the
41. What is the matrix trace?

    To measure coverage of the requirements, it is necessary to analyze product requirements and break them into paragraphs. Optionally, each item is associated with a test case that validates it. The totality of these links is the matrix trace (traceability matrix). Following connection, you can understand what requirements verifies test case.
    
    Tests are not requirements do not make sense. Requirements that are not associated with the tests is the "white spots", i.e. perform all the generated test cases, it is impossible to give an answer implemented this requirement in the product or not.
    
    
    
    
the
42. What is testing End-to-End?

    End-to-End testing is a type of testing where the tester uses (scenarios that examine the entire flow of execution) in terms of which most likely possesses the user.
    
    In addition, the tests will run combining several scenarios relevant to the real world:
    the

    the
    • run the software in an environment with delays in the communications network;
    the
    • run the software in an environment with low resources;
    the
    • Run on the other server equipment;
    the
    • Start the software in the same environment that has some other applications that consume resources of the server.

    
    
    
    
the
43. What is functional testing? What are the main types of functional testing? What types of functional tests, you know?

    Functional testing (functional testing) is testing that is 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 the interaction with other systems, and can be represented at all levels of testing: component or modular (Component/Unit testing), integration (Integration testing), system (System testing) priemones (Acceptance testing). Functional types of testing to consider the external behavior of the system.
    
    The following are some of the most common functional tests:
    

    Functional tests based on the functions performed by the system, and can be performed at all test levels (component, integration, system, acceptance). Typically, these functions are described in the requirements, functional specifications or use cases of the system (use cases). Functionality testing can be carried out in two aspects:
    the

    1. testing the term "requirements" (requirement-based testing) uses the specification of functional requirements for the system as a basis for the design of test cases (Test Cases). In this case, you need to make a list of what will be tested and what is not; to prioritize requirements based on risks (if not done in the requirements document), and based on this prioritize test scenarios (test cases). This will allow you to focus and not to miss when testing the most important functionality.
    the
    2. testing in the future "business processes" (business-process-based testing) uses knowledge of these business processes, which describe scenario of daily use of the system. In this perspective test scenarios (test scripts), usually based on the use cases of the system (use cases).
    
    

    Test security (security testing) is a test to assess the protection. The overall security strategy is based on three basic principles:
    the

    the
    • confidentiality;
    the
    • integrity;
    the
    • availability;
    currently, the most common types of security vulnerabilities in software are:
    the
    the
    • xss (cross-site scripting) is a type of software vulnerabilities (Web applications) at which, the generated server page execute malicious script to attack client;
    the
    • xsrf / csrf (request forgery) is a type of vulnerability that allows to exploit weaknesses in the HTTP Protocol, while attackers operate according to the following scheme: link to a malicious website set visit, trusted by the user, when you click on a malicious link runs a script that saves a user's information (passwords, payment information, etc.) or sending SPAM messages on behalf of a user or change access to user account, to gain full control over it;

    code injections (sql, php, asp etc) is a security vulnerability, whereby it becomes possible to launch an executable code with the aim of obtaining access to system resources, unauthorized access to data or damage the system;

    server-side includes (ssi) injection is a type of vulnerability using the insert server-side commands in the HTML code, or run them directly from the server; the

    • authorization bypass is a type of vulnerability that allows to gain unauthorized access to accounts or instruments of another user.
    
    

    Testing interoperability (interoperability testing) is the process of testing to determine the interoperability of a software product.
    

    
    Functional testing divided by the expected result for positive and negative tests:
    the

    Positive test uses only valid data and verifies that the application is properly executed the function call.

    Negative test operates as a correct and incorrect data (at least 1 incorrect parameter) and aims to test exceptional situations (triggers, validators), and also verifies that the called function is not executed when triggered by the validator.

    
    
    
    
the
44. What is functional testing?

    non-Functional testing (non-functional testing) is testing the attributes of a component or system that are not related to the functionality, i.e. reliability, efficiency, usability, maintainability, portability, etc. (tests done on all aspects that are not directly associated with a specific user action).
    
    
    
the
45. Some examples of tests that includes non-functional testing?

    Testing. Article based on information from habrahabr.ru