Top technical questions for a beginner at an interview

In this article, we have collected for you a list of the most common technical questions that are usually asked at technical interviews for the position of QA Intern. Of course, the questions below are not mandatory, but only an approximate scenario of the interview. The list includes general questions about testing theory, as well as more specific questions about testing on mobile devices and game testing.

1. What is the difference between bug, failure, and error?

Bug (defect) is a developer's (or designer's or other person's) mistake, i.e. when something goes wrong in the program and it gets out of control. For example, when the fields are not validated and as a result, incorrect data causes crashes or other malfunctions in the program. Or, if the program is built in a way that doesn't match what is expected of it from the start.

Failure – a malfunction (not necessarily hardware) in the operation of a component, the entire program, or the system. A program failure can indicate that there is a defect.

Error – a user error that occurs when a user tries to use the program in the wrong way. For example, they enter letters in fields where numbers are required (age, quantity of goods, etc.). In a good quality program, there must be error messages as a response to such cases.

2. What is the difference between QA and QC?

QA (Quality Assurance) – is a product quality assurance that includes the following processes:

• verification of technical specifications and software requirements;
• risk assessment;
• planning tasks to improve product quality;
• preparation of documentation, test environment, and data;
• testing;
• analyzing test results and creating bug reports and other documents.

QC (Quality Control) – product quality control, in other words::

• checking whether the software is ready for release;
• checking compliance with the requirements and quality of the project.

More details in the article: «Difference between QA and QC»

3. What are functional and non-functional testing? List their types.

Functional testing is the testing of all system functions to confirm that each program function works according to the specification.

In functional testing, we answer the question "Does the system work?", while in non-functional testing the question is: "How well does the system work?". Non-functional testing is designed to check those aspects of the software that can be described in the documentation but are not related to the functions of the software products.

Non-functional testing includes the following subtypes:

• stability testing;
• usability testing;
• acceptance testing;
• documentation testing;
• endurance testing;
• load testing;
• performance testing;
• compatibility testing;
• security testing;
• volume testing;
• stress testing;
• recovery testing;
• localization testing, internationalization, etc.

It is also worth highlighting separately structural testing and сhange-related testing (regression and retesting). 

More details in the article: «Types of testing overview»

4. What is the difference between Severity and Priority? Provide examples of real bugs with high priority and low severity and vice versa.

Severity is an attribute that describes the level of impact a bug has on the overall functionality of the product under test.

Priority is an attribute that determines the urgency of fixing the bug.

High priority and low severity

Any minor severity defects that can directly affect the user experience are automatically assigned to this category. This also includes bugs that should normally be fixed, but do not impact the application.

High severity and low priority

A defect that occurs in the functionality of the application (which has no workaround) and prevents from using the system, but is rarely used by the end user.

More information you can find in the article: «Severity and priority. Examples of the bugs with high severity and low priority and vice versa»

5. The essence and difference between validation and verification. 

Verification is a confirmation that specific requirements have been met. During verification, we ask the following question: "Is the product being created and tested in the right way?"

Validation – checking that the product meets the expectations and needs of users. During validation, the question is: "Are we creating the right product?"

See more information here:  «Verification and validation and validation in testing»

6. What is the essence and difference between such test documentation as a test plan, checklist, and test case?

Test Plan is a document that describes objectives, approaches, resources, and schedule of planned test activities. It defines the test objects, properties to be tested, tasks, those responsible for the tasks, the level of each tester's independence, the test environment, the test design method, the used entry and exit criteria, and the reasons for their selection, as well as any risks that require emergency planning.

The checklist is a control list that contains a number of necessary checks for testing.

A test Case is a set of steps, specific conditions, and parameters required to verify the implementation of the tested function or part of it.

7. What are the main attributes of a bug report and a test case?

A bug Report is a technical document that describes the situation or sequence of actions that led to the incorrect operation of the tested object, with the reasons and expected result.  

The summary is a brief description of the bug.

The description is a more detailed description of the bug if it is necessary.

Steps To Reproduce. All the steps must be described accurately to exactly reproduce the error.

Actual result. In this attribute, one must specify what is not working correctly, where, and under what conditions.

Expected result. It is indicated how exactly the system should work according to the tester. 

Attachments. It can be a screenshot, video, or log file. 

Priority (Priority of the defect).

Severity (Severity of the defect)

Status: The main attribute that defines the current state of the bug. 

Defect environment. Components and Environment are defect attributes that indicate where this defect is reproduced (iOS, Android, Windows, Mac and their versions, browser names, and versions). 

Read more in the article: «Main attributes of bug-reports»

A test Case is a set of steps, specific conditions, and parameters required to verify the implementation of the tested function or part of it.

Test Case ID is a sequence number.

Test Summary – name, summary, or title.

Preconditions – a list of all the necessary preparation actions (configuring the program, test environment) to execute the test case.

Test Steps are the steps that are required to pass the test. 

Expected result – the expected behavior of the system for the actions specified in the steps.

8. What are the characteristics of a good test case?

A good test case covers both positive and negative scenarios and performs only one action at a time that does not overlap with others.

Characteristics of a good test case:

• the test suite should not be excessive but minimal and sufficient; it is recommended to use division into equivalence classes; 
• the test case shouldn't be too simple or too complex; 
• the test case must be precisely defined;
• the test case must be unified;
• the test case must be unambiguous and clear.

9. What is Use Case/User Stories?

A Use Case is a list of actions, a scenario in which a user interacts with an application or program to perform an action and achieve a specific goal.

Find more in the article: «What is a use case and what is it for?»

A User Story is an informal, general explanation of the software's functions written from the point of view of the end user. Its purpose is to formulate what value the software functionality brings to the customer. 

Find more in the article: «What is a user story and how to write it?»

10. What is the difference between regression testing and retesting?

Regression testing is performed to check whether the existing functionality is working properly and to check for the absence of third-party errors after updating the build (making changes or modifications to the system). It is executed only after adding a new feature (additional software functionality) or a significant change in the system's functionality.

Retesting is performed to confirm that errors are fixed and to check the work of functionality. Retesting is executed in the same environment and with the same data but in the new build. 

More details in the article: «Types of testing overview»

11. Defect Lifecycle

The Defect Lifecycle is a sequence of stages through which a defect goes from its creation to its final closure. To make it easier to understand, it is displayed in the form of a diagram with possible statuses and actions that lead to a change in these statuses.

New – a bug is reported to the bug tracking system for the first time.

Assigned – the defect report is assigned to the appropriate developer/programmer.

Open – the developer takes the bug report into work to analyze and fix it.

Fixed – the developer has made the necessary changes to the code and tested these changes on his/her own. A bug report with this status is returned to the tester.

Retesting in standby mode – after fixing the defect, the developer has provided specific code for retesting by the tester. Testing is under review by the tester.

Re-testing – at this stage, the tester retests the updated code provided by the developer to check whether the defect has been fixed or not.

Verified – if the defect is not reproduced, the tester confirms that the defect has been fixed.

Reopened – if the defect is still reproduced even after it has been fixed by the developer, the tester reopens it and assigns it back to the developer. This defect goes through the bug life cycle again.

Closed – if the tester is sure that the defect no longer exists, then they close it. This status means that the defect has been fixed, tested, and approved.

Duplicate – if the defect is repeated twice or there are two bugs with the same cause, one of them is assigned with this status.

Rejected – if the developer finds the defect to be unreasonable or insignificant and will not be considered for correction or implementation, they reject it.

Deferred – the defect assigned with this status is expected to be fixed in future versions. There can be several reasons for assigning this status: the priority of the defect is low, there is a lack of time, and the defect will not cause major failures in the software product.

Not a bug – this status is assigned if there will be no changes made to the application's functionality. For example, if the customer asks to change the color or size of buttons or text, this is not a defect, but simply a change in the application design.

Find more in the article: «Life cycle of the program defect»

12. What are positive and negative testing?

Positive testing involves using scenarios that correspond to the normal (regular, expected) behavior of the system. With its help, one can determine that the system does exactly what it was designed to do.

Negative testing is defined as testing that uses scenarios that correspond to abnormal behavior of the tested system. For example, exceptional situations or incorrect data. 

More information in the article: «Positive and Negative Testing»

13. Give a definition of white box and black box testing.

Black box testing is a special method of testing software operation, in which the entire functionality of a product is examined without analyzing the source code. Testers create logically clear test cases based solely on the requirements of the project specification.

For example, a tester checks a website without knowing the specifics of its implementation, using only the input fields and buttons provided by the developer. The source of the expected result is the specification.

White box testing is a special method of software testing, where the internal structure and technical features of the software are thoroughly known to the tester. 

For example, a tester, who is most often a programmer, examines the implementation of the input field code on a web page, identifies all the expected (both correct and incorrect) and unexpected user inputs, and compares the actual result of the program execution with the expected result. The expected result is determined by how the program code should work.

14. What are SDLC and STLC?

The Software Development Life Cycle is a period that begins from the moment a decision is made to create a software product and ends when it is completely withdrawn from use.

More details in the article: «Popular Software Development Life Cycles»

Software Testing Life Cycle (STLC) is a process that consists of a certain number of separate parts, has an end goal, and is performed throughout the entire software development life cycle. The main stages of testing include requirements analysis, test design process, development, testing and debugging, operation, and maintenance. 

More details in the article: «Stages of software testing»

15. What is test design? Basic test design techniques. 

Test Design is one of the early stages of the software testing process, where test cases are planned and designed in accordance with quality criteria, project requirements, and testing goals. The main goal of test design is to cover the entire functionality with the minimum number of tests. For this purpose, different design techniques are used, such as general rules and recommendations, regarding creating tests during the testing process.

Test design techniques: Boundary Value Analysis, Exhaustive Testing, Equivalence Partitioning, Error Guessing, Pairwise Testing, Cause/Effect, Decision Table, etc. 

More information about test design techniques you can find in the following articles:

«Equivalence Partitioning and Boundary Values»

«Pairwise testing»

«Defect prediction as a test design technique»

16. What is cross-browser testing?

Cross-browser testing is testing using different browsers to check whether a website (web application) can be displayed and function properly in all browsers. This is because any of the browsers has its own add-ons, and plug-ins, as well as differences in desktop and mobile versions.

Find more in the article:

«Cross browser testing: reasons and executors to perform»

17. What are the peculiarities of testing applications on mobile devices?

Main points to pay special attention to when testing applications on mobile devices: 

• screen size and touch interface,
• phone resources,
• different screen resolutions and OS versions,
• application response to external interruptions; 
• checking the operation of updates, 
• advertising in the mobile application,
• localization check.

Find more in the article:

«Peculiarities of mobile application testing»

18. Types of mobile applications. Explain the difference between Native, Web App, Hybrid App.

Native apps are mobile applications written in programming languages approved by software developers for each specific platform, and therefore organically embedded in the corresponding operating systems. Applications are downloaded through app stores (App Store, Google Play, etc.) and meet the requirements of these stores. Native apps can work in full or partially without an internet connection, so users are less dependent on the quality of the connection and can use the app where and when it is convenient for them.

Mobile web applications (Web apps) – a mobile version of a website with advanced interactivity. The difference between a web application and a responsive website layout is rather small, as both use standard web technologies, and the speed of operation is limited by the quality of the Internet connection. At the same time, web programs are not available in specialized app stores and usually require the phone's browser to work.

Hybrid apps - Mobile application generators help create cross-platform applications that are close in functionality and quality to native applications. It is a combination of native and web applications. Such apps are installed through official stores, have limited access to smartphone and tablet hardware, and allow setting up push notifications. They are also usually cheaper than native apps.

Read more in the article: «Types of mobile applications»

19. What are log files? How to take logs on mobile devices?

Logs are files that contain information about the server or computer operation, in which certain programs and user actions are recorded.  

To take logs on Android devices, use such tools as Minimal ADB, and Android Studio. In iOS devices, you can use the following tools: iTunes, iMazing, and XCode (for MacOS).

Read more in the article: «How to obtain logs from Android device»

«Getting iOS crash logs»

20. What game mechanics and game genres do you know?

Game mechanics are a set of rules that define how the player and the interface interact. For example, Achievement, Appointment mechanics, Avoidance, Behavioural contrast, Behavioural impulse, Grateful performance, Cascading mechanics, Chains of events, Friendly games, Circumstance, Countdown, Deterrents, Endless games, Termination, Fixed intermediate rewards mechanics, Fixed reward relationships mechanics, Intermediate reward mechanics, Lottery, Modifiers, Privacy, Progressive dynamics, Reward ratio mechanics, Real-time and delayed time, Reinforcement, Physical goods distribution, Status, Variable intermediate reward mechanics, Variable reward relationship mechanics, Fun once Fun always, Virtual items, etc.

Read more in the article: 

«Game mechanics: types and features of testing»

A game genre is a group of games united by common characteristics of the game process (gameplay). For example, action games (platform games, fighting games, shooters, arcade games, survival games, sports games, simulators, racing); strategies (economic, tower defense, military, card games); role-playing games or RPGs (educational, adventure, quests, puzzles, browser games,  a text-based and online role-playing games).

Read more in the article: «Game genres»

Of course, the list of questions is not complete, but it will help you to recall the basic concepts and refresh your knowledge of testing theory to successfully pass the interview for the QA Intern position.