Software Testing Interview-Questions

There are three main category of defect as –

Wrong Defect

Missing Defect

Extra Defect.

To prepare Acceptance Testing Plan we would require to compile the following documents

• Requirement Document
• Input from Customer
• Project Plan

A Risk is a condition which has a probability to result in a loss. Risk can be controlled by applying different scenarios but cant eliminated Hence the stronger the Software Testing effort the risk can be controlled.

SDLC is the fundamental process that is followed to engineer a software is referred as SDLC i.e Software Development Life Cycle. It comprises of various phases through which a software goes during its entire life cycle, which are: Requirement Gathering & Analysis, Designing, Development, Testing and Maintenance.

In sql DML Command are – Insert, Update, Delete.

Agile manifesto are:

• Individual & Interactions,
• Working Software,
• Customer Collaboration, and
• Responding to change.

.apk (Android application package)

Re-Testing: When a Developer fixes an assigned bug then it is again tested by the tester to check the current status of assigned bug, this process of confirming the fixation of bug is referred as Re-testing. Also known as Confirmation testing.
Regression Testing: The process of making sure that whether any newly done modification to the code/ the application environment has not badly affected the correctly working functionalities is referred as Regression Testing [It can be carried out after re-testing, with each incremental build i.e. when new functionalities are added].
Unit Testing: To check individual Module/component is referred as Unit Testing. It is also called as Component/Module/Program testing. Generally it is carried out by the Developers using white box testing techniques.

Software testing is an activity in which the testers find out the loopholes in the application by detecting the bugs at an early stage of software development and checks that whether the application is giving any unanticipated behavior.

The activity which is carried out before coding phase is referred as verification or static testing. Here the documents like requirement, SRS, Architecture document, etc are checked. While validation which is also referred as dynamic testing is the process of testing the developed application/product, here it is also checked that whether the developed software is according to the specified requirements or not.

QA means Quality Assurance is focused on improving the process that needs to be followed for developing an application for e.g to improve the quality of requirement document, SRS, Design document. While QC i.e. Quality Control is mainly focused on providing the corrective solutions to solve the faults in the product. Where as Testing is majorly focused on finding the bugs in the application/ product before deploying it in the market.

The objective of load testing is to check whether the application can behave correctly with anticipated number of users without degrading the performance for e.g. checking the performance of application when the expected load i.e. say 50,000 users are accessing the application at the same time. Where as the objective of Stress testing is to break the application to check whether it can recover from crash or not. Stress can be given by increasing the number of users beyond the capacity of application or by reducing the resources for e.g. processor speed, memory size, etc.

Functional testing is mainly concerned about the application’s features while non functional testing is focused on the quality attributes of application for e.g. performance, usability, etc. Functionalities are basically derived from the customer’s requirements i.e. they are the mandatory things while non-functional parameters can indirectly affects the application/business if they are absent and not upto the mark.

Test plan is referred as super/ master document while test strategy is mostly the sub-set/sub-document of test plan. Test plan comprises of all of the tasks that needs to be carried out to test the application while test strategy mainly describe details about the testing approach and in test strategy it doesn’t matter who is testing it, so it is generic i.e. any change in the team’s testers does not meet to be updated where as a test plan is updated time to time say if Tester-A who will be testing Module ‘X’ if substitutes another Tester-B then test plan document will be updated.

Here is the list of Verification technique –

Formal review,

Informal review,

walk through,

Technical review

Inspection.

Requirement document, SRS/FRS, Design/Architecture documents, Use cases, etc.

Testing performed with invalid input data or out of range data then it is referred as negative testing for e.g. if the accepted number of digits i.e. numbers in mobile number field is 10 and if you are inputting 12 digits then it is negative testing. Positive testing is done with valid data only i.e. in the range data, its purpose is to check whether the functionality is working correctly with expected input or not where as the objective of negative testing is to confirm that the functionality should not accept any invalid data and also it should display proper error/warning message to the user.

QA process should be started after collecting the requirement i.e. from the requirement analysis phase and it should be incorporated through-out the SDLC life cycle.

Firstly I will prioritize the test cases in the test suit. For this one can use risk/impact analysis and also according to the modules that are most oftenly used by the end-users. If applicable I will automate some test cases.

Yes

To measure the test coverage one can make use of trace ability matrix from which I can check the requirement coverage, also number of test cases run, etc and If in scope I can record and test for various combinations and versions of OS, browsers, devices.

Following proper re-testing & regression testing with updated set of test cases, I will immediately update it in the test ware and also mentioning its testing environment.

First of all I will try to gather as much relevant information from different artifacts and online that are available and with that knowledge I will approach to the corresponding stakeholders according to their continent hours and will put forward my query/concern.

17. What is the Key principles of Software Testing.

The fundamental testing process is based on seven testing principles, which are:

• Testing shows presence of defects;
• Exhaustive testing is impossible;
• Early Testing;
• Defect Clustering;
• Testing is context dependent;
• Pesticide Paradox; and
• Absence of errors is fallacy.

Test scenarios defines the test ability of applications i.e.  to identify what to test, which is also referred as test possibility.

Test cases are developed to test whether the application is behaving as expected or not i.e. to check if its giving the correct result or not (for this proper template is followed).

Severity is basically to identify if a functionality is failing or if its not giving the correct result than till what extent it will affect the application/business i.e. how much it will impact. Priority  is relative means the tester defines the priority level according to its importance or urgency to fix the bug. Which bug to fix first is decided based on its priority level and also on its severity level.

Function ID, Function Name, Test Case ID, Test Case Objective, Test Steps, Test Data, Expected Result, Actual Result, Status, Testing Type, Remark (according to organizations this format can vary, it can have some additional fields as well).

Function ID, Function Name, Test Case ID, Test Case Objective, Test Steps, Test Data, Expected Result, Actual Result, Defect ID, Defect Summary, Priority, Severity, Defect Type, Defect status/stage(according to organizations this format can vary, it can have some additional fields as well).

Load runner is an automation testing tool, basically used for performance testing of application by virtually putting it under real world load. There are three components of load runner: Virtal User Generator, Controller and analysis and its process flow is as described below:

1. Identify the scenario that you want to test and record user actions using Virtual user generator then replay your recorded actions.
2. Create controller scenario: Here identify your goal for e.g. you want to give load in terms of large number of users starting at random intervals OR you want to check the response time then run the scenario.
3. Analyse the result using analysis. It will generate different graphs depicting the performance of the application e.g. hits/second, response time, etc.

BVA i.e. boundary value analysis is a black box testing technique. Its main aim is to test the behaviour of functionalities nearer or closest to the boundary values. This technique can be used in designing the test cases. BVA E.g.: Suppose in a chatting application, if the limit of members in a group is minimum 2 and maximum 150 then try to create group by taking boundary values like:

• TC1 (at lower boundary): Try to create group using 1 member (negative testing); then create group using 2 members (positive testing).
• TC2 (at upper boundary): Try to create group using 151 members (negative testing); then try to create group using 150 members (positive testing).

Smoke testing is carried out when the application is in its initial builds/ versions say for e.g. build 1, build 2 to check whether the main functionalities of the application are working correctly or not and it does not carried out in much detail. If smoke testing passes then further process can be carried out in more detailed system testing and in developing newer builds. Sanity testing is like specialized testing. In this the newly added functionalities of the build will be tested. The objective is to check whether the new functionalities are working fine or not and also it can be checked whether the bugs of previous build are fixed or not. If it passes then the detailed system testing can be carried out. Before sanity testing multiple round of regression testing is already carried out.