Wednesday, December 10, 2014

The ultimate series of Software testing interview questions (Part 3)

Software testing interview questions
Continuing the previous articles in my series I added few more great questions that relevant for the “Theoretical” side if testing.

Q1: Explain software “requirements”?

Requirements are gathered from the company customer (Sometimes there are no clients that specifically demand the software, so the requirements are based on company vision (Startups are a great example...)), the requirements represent the expected and demanded needs that the client wished to get from the future software.

Q2: Explain “Endurance” testing


Testing technique that used to determine the effect of the tested software against the host system, this type of tests are performed under a long executions and may take a while to get the expected results, examples: 

-     Memory leaks.
-     System I\o.
-     Database deadlocks.
-     CPU overloads
-     Etc.

Q3: Explain “Severity” of a bug? 


The severity of a bug, is measured based on how the defect affects the software or any other bad impact that he cause and may lead to deviation from the original requirements. Bug severity is determined by the tester that reports about the incident.

In addition, when the tester needs to determine the severity of the incident, he need to answer few basic questions:
-     How this bug will affect the testing process?
-     How this bug will affect the client?
-     What's the impact on the system?
-     How this error affects the testing timelines?
-     Does this bug block other tests?
-     Etc.

Q4: Explain “Severity” levels? 


Every company can determine their own scale for the severity levels, but based on my experience there are few mandatory levels that relevant for all: 

Severity levels: 

·    Blocker/show-stopper - the software or specific component are not suitable for use/testing (Total failure, System crushes Etc.) and there is no workaround.

-     The system will crash when user presses the “Start” button.
-     The system will fail to start after a corrupted installation.
-     The system cause hardware failures that resolved a software shutdown.

·    Critical - Major functionality does not function as it should, there is a workaround that may affect the integrity of the tests.


-     The software can crash randomly, while using different functionalities.
-     The software produces inconsistent results, the basic requirements are failed to be answered.

·    Major - minor functionality is affected, there is no impact on other components, and there is a quick and valid workaround.


The user cannot use a specific functionality, but can use the same functionality by accessing it from different modules.

·    Minor - minor impact on the specific location, there is no need to create a workaround, the software integrity is not affected.


-     Spellcheck errors
-     Resolving errors
-     Enhancements
-     Change request
-     Etc.

Q5: Explain “Priority” of a bug?


The priority of a bug is determined by how urgently this bug should be fixed, when determine this category, the owner should answer few basic questions:

-     How this bug affects the timelines?
-     How this bug affects the testing process?
-     Can the tester proceeds with is tests?
-     How this bug affects other testers?
-     What are the costs of fixing this bug?
-     Should we change the software requirements?
-     Etc.

Q6: can you start your tests without a working build?


There is only one answer, yes! Remember that there are two types of testing methodologies (Static and Dynamic), that allow the tester to start his test without a working build (Static method). 

Furthermore, you must start your test before the software is available for testing, the main reason is that bug that found by the “Static” method will be more cost effective than the bugs that found on the “Dynamic” tests.

Q7: Explain software “Build”?


A collection of hundreds source code files, that compiled together to create an executable software. The ability to create software builds is crucial for every testing process, the first build will holds the original code and newer builds will contain the bug fixes or any other code modifications.

Q8: Explain static analysis?


Any activity that used to analyze the tested software, but without the involvement of code execution.

Q9: Explain test Driver/Harness? 


Any coded application/tool that has the ability to execute test cases.

Q10: Explain “Traceability” matrix?


A basic documentation that specifies the relationships between the test requirements and the corresponding test case.

Q11: What is the MAIN difference between Quality Assurance (QA) and Quality Control (QC)? 


There are many differences, the main one is that quality assurance (QA) is the activity to measure and improve the testing process, Quality control from the other end, is the process that used to insure the quality of the product (The actual Testing process).

Friday, December 5, 2014

The ultimate series of Software testing interview questions (Part 2)

Software testing interview questions
Continuing the previous article (Link), I attached an addition 15 questions that relevant for the“Theoretical” side if testing. 

Q1: Explain the “Verification” process


The real question that we need to answer is: Are we building the product right?
The verification process is executed to make sure that each phase of the SDLC cycle (Development, Testing Etc.) is built based on the predefined requirements and specifications (in other we want to make sure that each step is meet the predefined requirements and without any deviation from it).  

Q2: Describe different activities of the verification process


-     Analysis of different testing aspects (Timelines, Resources, testing tools Etc.)
-     Statement, Condition and decision coverage
-     Reviews (Technical, documentations Etc.)
-     Walk-throughs
-     Inspections

Q3: can you provide verification examples for based on “Testing” levels?  


Level 1: Unit testing

Verifying the software design implementation

Level 2: Integration

Testing the integrations between all the corresponding components until the software can move to the next level (System).

Level 3: System 

Ensuring that the system meets the predefined requirements and specifications (Notice, The validation process is the actual testing that performed while running the code.)

Level 4: Acceptance

Ensure that the system meets the client requirements.

Q4: Explain the “Validation” process


The real question that we need to answer is: Are we building the right product?
The process that allows the tester to evaluate the software after the development stage is done and before the software released to the customer, in this process, we need to ensure that the software is working based on the user needs.

Remember, the validation process embraces the “Dynamic” side of testing, where the actual software is tested and evaluated against the predefined SRS documentation.

Q5: Explain few reasons that lead to software bugs? 


There are too many, this list will do the trick:
-     Human errors (Design process).
-     Human errors (Implementation process).
-     Changing requirements while the software is under testing.
-     Failure to understand the predefined requirements and specifications.
-     Time pressures.
-     Poor testing prioritization.
-     Migrations between versions.
-     Software complexity.

Q6: Explain “Test Procedure”?


A documented algorithm that provides a detailed instructions for how to execute a test case.

Q7: Explain software component?


In its basic, software components are small software items that built from small units that integrated together, examples:
-     Classes
-     Stored procedures.
-     Functionality of Binary trees.
-     Methods
-     Etc.

Q8: Explain “Code” Coverage?


In code coverage, we want to determine which part in code are tested with a dedicated “Test”  cases, and which part are not yet executed (And should be…) during the testing matrix. Code coverage allows the project owner to see the testing progress/coverage and get control on the project status. 

Q9: Explain “Code” inspection?


Testing technique that determines the quality of the application source code, in this testing process. The engineer that set as the code owner review the code for a group of people that make the inspection with different types of tools, Examples: 

-     Inspection made to the code logic
-     Inspection made to the code Design
-     Checklists against the design requirements and specifications
-     Different suggestions to improve the inspected code.
-     Comparing the code design to the industry coding standards
-     Different questions about the issues that that programmer encountered while coding the
-     Etc.

Q10: Explain “Code” complete?


Very simple term that relevant to specific phased of the SDLC process, when speaking about “Code” complete, we actually want to say that the code implementation is completed (The entire software functionality is implemented successfully). 

In addition, reminder that although the code is fully implemented, there are always new bugs that discovered in the testing cycles/Clients, that doesn’t affect the fact that No more coding is needed based on the original requirements and specifications

Q11: Explain “Code” walk-through?


Don’t confuse with code “inspection”… code “walk-through” is a testing technique that used to review the code implementation by the programmer and the testing team, during this walk through the code is executed with a few simple tests to determine the quality of the code and the code logic.

Q12: Explain software “Debugging”? 


The most basic process to search and remove any risks that may cause software errors/bugs.

Q13: Explain “Emulator”? 


Any object (System/Software) that simulate the same behavior of the original software, using emulators, we can use the same inputs that used to test the original software and examine the outputs (should be the same results as the original software).

Q14: Explain software “Specifications”?


Specifications comes from the customer needs, in the first interaction the customer provides few requirements that translated into high detailed design that will use by the engineering team.

Stage 1: Requirements
Stage 2: Analyze and investigation
Stage 3: Requirements translated into specifications.

Q15: Explain “Coding”? 


Any programing activity that generates a source code.

My Presentations