Guru99

Question 1

What is software testing?

Answer 1

an activity to check whether the actual results match the expected results and to ensure that the software system is Defect free.

Question 2

AUT

Answer 2

Application Under Test

In simple terms, Software Testing means Verification of Application Under Test (AUT).

Question 3

3 categories of software testing

Answer 3

1. Functional testing (unit testing, integration testing, etc.)
2. Non-functional testing (performance, endurance, load, usability, etc.)
3. Maintenance (regression, maintenance)

Question 4

The 7 testing principles

Answer 4

1) Exhaustive testing is not possible
2) Defect Clustering
3) Pesticide Paradox
4) Testing shows a presence of defects
5) Absence of Error - fallacy
6) Early Testing
7) Testing is context dependent

Question 5

Principle: Exhaustive testing is not possible

Answer 5

We can’t test every test case, so we need the optimal amount of testing based on the risk assessment of the application.

Question 6

Principle: Defect Clustering

Answer 6

a small number of modules contain most of the defects detected

Question 7

Principle: Pesticide Paradox

Answer 7

If the same tests are repeated over and over again, eventually the same test cases will no longer find new bugs.

Question 8

Principle: Testing shows a presence of defects

Answer 8

Software testing talks about the presence of defects and doesn’t talk about the absence of defects.

Question 9

Principle: Absence of Error - fallacy

Answer 9

It is possible that software which is 99% bug-free is still unusable. It must also fulfill customer requirements.

Question 10

Principle: Early Testing

Answer 10

Testing should start as early as possible in the Software Development Life Cycle. Defects in requirements or design are captured early, too.

Question 11

Principle: Testing is context dependent

Answer 11

Different types of software need to perform different types of testing.

Question 12

SDLC

Answer 12

Software Development Life Cycle

Question 13

STLC

Answer 13

Software Testing Life Cycle

Question 14

The V model

Answer 14

Requirement analysis System testing
High level design Integration testing
Low level design Unit testing
Coding

Question 15

Phases of STLC

Answer 15

Requirements analysis
Test planning 
Test case development 
Test environment setup
Test execution
Test cycle closure

Question 16

Types of testing that could be manual or automated

Answer 16

Black Box Testing
White Box Testing
Unit Testing
System Testing
Integration Testing
Acceptance Testing

Question 17

Unit testing

Answer 17

Unit Tests isolate a section of code and verify its correctness. A unit may be an individual function, method, procedure, module, or object. Developers write unit tests during the coding phase.

Question 18

Unit testing advantages

Answer 18

Allows for refactoring at a later date.
New developers can learn functionality of the code.
Can test parts without waiting for others to complete.
Find and fix errors faster than in integration testing, where errors are hard to trace down.

Question 19

Integration testing

Answer 19

A type of testing where software modules are integrated logically and tested as a group.

Data transfer between modules is tested thoroughly.

Question 20

Big-bang integration testing

Answer 20

Wait for all modules to be developed before beginning testing. Convenient for small systems.

Disadvantage: time consuming waiting for developers, difficult to trace root cause of defects, and high-risk modules are not prioritized

Question 21

Incremental integration testing

Answer 21

Testing is done by joining two or more modules that are logically related. Then the other related modules are added and tested as they are available.

Top-down (higher layers first): create stubs.
Bottom-up: create drivers

The focus is mainly on the interfaces & flow of data/information between the modules. Priority is to be given for the integrating links rather than the unit functions which are already tested.

Question 22

Stub

Answer 22

Is called by the Module under Test

Question 23

Driver

Answer 23

Calls the Module to be tested

Question 24

System testing

Answer 24

System testing is a level of testing that validates the complete and fully integrated software product. The purpose of a system test is to evaluate the end-to-end system specifications.

Includes usability testing, load testing, regression testing, recovery testing, migration testing, functional testing, hardware/software testing, etc.

Question 25

Compiler vs. Interpreter

Answer 25

A compiler transforms source language into object language (machine language, binary code). Generates output program (in the form of exe) which can be run independently from the original program. Ex: C, C++, C#, Java An interpreter converts the program one line at a time, it does not produce any intermediate object code, and compilation and execution happen simultaneously. Ex: Python, Matlab

Question 26

Compiler vs interpreter programming steps

Answer 26

Compiler: 1. Create the program. 2. Compile will parse or analyses all of the language statements for its correctness. If incorrect, throws an error 3. If no error, the compiler will convert source code to machine code. 4. It links different code files into a runnable program (know as exe) 5. Run the Program Interpreter: 1. Create the Program 2. No linking of files or machine code generation 3. Source statements executed line by line DURING Execution

Question 27

Linker

Answer 27

In the compiler, the linker links several object (and library) files to generate an executable. Building a complete program involves writing source code for the program in either assembly or a higher level language like C++. The source code is assembled (for assembly code) or compiled (for higher level languages) to object code, and individual modules are linked together to become the machine code for the final program. In the case of very simple programs the linking step may not be needed. In other cases, such as with an IDE (integrated development environment) the linker and compiler may be invoked together.

Question 28

Machine code

Answer 28

binary (1's and 0's) code that can be executed directly by the CPU

Question 29

Object code

Answer 29

A portion of machine code that hasn't yet been linked into a complete program. It's the machine code for one particular library or module that will make up the completed product. An object file is the simplest binary file which comes from the compilation of a single translation unit (TU) into executable code. Usual extensions: .o or .obj (MSVC).

Question 30

Assembly code

Answer 30

Assembly code is plain-text and (somewhat) human read-able source code that mostly has a direct 1:1 analog with machine instructions. This is accomplished using mnemonics for the actual instructions, registers, or other resources. Examples include JMP and MULT for the CPU's jump and multiplication instructions.

Question 31

Header file

Answer 31

Contains C++ source code and they are mostly used to make declarations, i.e., they contain the stubs that tell the compiler about the "things" that exists (somewhere). Usual extensions: .hpp, .h, or .hxx.

Question 32

Source file

Answer 32

Contains C++ source code and they are exclusively used for definitions, i.e., the actual implementation of the "things" that make up the program or library. Usual extensions: .cpp, .C, or .cxx (normally, .c is reserved for C source files, not C++). An example of how a source file is organized: it first includes its corresponding header, then any other header it needs, and finally, the definitions of each of the declared elements of its corresponding header.

Question 33

Translation unit (TU)

Answer 33

A technical term for a source file, once the compiler has looked at all #include statements and substituted them for the header files they refer to. Once the pre-processor has finished, we can say that a translation unit (TU) has been fully formed from a source file with all its included headers fetched and copied into it, all its MACROs found-and-replaced, and all its conditional compilation blocks resolved.

Question 34

Static library (or static-link library)

Answer 34

A binary file which is very similar to an object file but is larger and usually the product of many object files combined into one file for convenience. The GNU stack refers to static libraries as archives, i.e., collections of object files. Usual extensions: .a or .lib (MSVC).

Question 35

Dynamic library (or dynamic-link library or shared object)

Answer 35

A binary file also created from a set of object files, but they are packaged as a standalone executable library (not a program). Usual extensions: .so (POSIX) or .dll (Windows).

Question 36

Executable program

Answer 36

This is a type of binary file that can be started and executed, i.e., it has an execution entry-point. In short, this is a program you can run. Usual extensions: (POSIX) or .exe (Windows).

Question 37

Pre-processor

Answer 37

Looks for # commands. The pre-processor is mostly a glorified find-and-replace tool. The step before compiling.

Question 38

Compiler static analysis

Answer 38

Between pre-processing and code generation, the compiler does some steps that involve terms like lexical analysis, syntax analysis, context-dependent grammars, semantic analysis, etc... Suffice it to say, broadly speaking, the compiler builds up an Abstract Syntax Tree (AST) and a symbol table.

Question 39

Build

Answer 39

Compiling is the act of turning source code into object code. Linking is the act of combining object code with libraries into a raw executable. Building is the sequence composed of compiling and linking, with possibly other tasks such as installer creation.

Question 40

Smoke Testing

Answer 40

Smoke Testing is performed after software build to ascertain that the critical functionalities of the program are working fine. It is executed before any detailed functional or regression tests. For Example, a typical smoke test would be - Verify that the application launches successfully, Check that the GUI is responsive ... etc.

Question 41

Sanity testing

Answer 41

Sanity testing is performed after receiving a software build with minor changes in code to ascertain that the bugs have been fixed and no further issues are introduced. The goal is to determine that it works roughly as expected. For instance, if your calculator gives the result of 2 + 2 =5, then, there is no point testing the advanced functionalities like sin 30 + cos 50.

Question 42

Smoke test vs. Sanity test

Answer 42

Smoke Testing has a goal to verify “stability” whereas Sanity Testing has a goal to verify “rationality”. Smoke Testing verifies the critical functionalities of the system whereas Sanity Testing verifies the new functionality like bug fixes. Smoke testing is a subset of acceptance testing whereas Sanity testing is a subset of Regression Testing. Smoke testing is documented or scripted whereas Sanity testing isn’t. Smoke testing verifies the entire system from end to end whereas Sanity Testing verifies only a particular component.

Question 43

Build VerificationTest

Answer 43

Smoke testing performed on a particular build is also known as a build verification test. Smoke tests can be functional tests or unit tests. Functional tests exercise the complete program with various inputs. Unit tests exercise individual functions, subroutines, or object methods.

Question 44

Regression testing

Answer 44

This testing is done to make sure that new code changes should not have side effects on the existing functionalities. It ensures that the old code still works once the latest code changes are done.

Question 45

Non-functional testing

Answer 45

A type of Software testing to check non-functional aspects (performance, usability, reliability, etc) of a software application. It is designed to test the readiness of a system as per nonfunctional parameters which are never addressed by functional testing. Non-functional testing parameters: security, reliability, survivability, availability, usability, scalability, interoperability, efficiency, flexibility, portability, re-usability

Question 46

Requirements Traceability Matrix (RTM)

Answer 46

Requirement Traceability Matrix (RTM) is a document that maps and traces user requirement with test cases. The main purpose is to validate that all requirements are checked via test cases such that no functionality is unchecked during Software testing.