Interview Questions Part 2

-->

Q.  What is a Risk? What are the important components of the risk?

A. Risk is a condition that will result in loss.
The important components of risk are a) Probability the risk will occur b) Impact of the risk c) Frequency of occurrence

Q.  What is walkthrough and inspection?                 

A. Walkthrough is there for both Testing and Coding.
Walkthrough for testing means brief review of documents, Test cases, Test script etc.
Walkthrough for Coding means review the coding for whether the Developer follows the Coding standards or not.

Inspection is job of Quality Control (QC). He can conduct Inspections and Audits on the project at any time to check whether the process is going on correctly or not.
I will tell y one example for Test Engineer, QA, QC
Take an Examination Center: In that

• Test Engineer is Examiner
• QA is sitting squad
• QC is a flying squad

Q. What is Release Acceptance Testing?
What is Forced Error Testing?
What is Data Integrity Testing?
What is System Integration Testing

A.  Following are the details regarding Release Acceptance Testing, System Integration Testing, Data Integrity Testing

1. Release Acceptance Testing
Lets consider the following example:
The business says a bank plans to plan to test a cards application in 3 releases: Release 1, 2 & 3.
Each release has few enhancements (functionalities) like Chargeback’s, Fraud reporting etc.,
Testing these enhancements release wise is termed as Release Acceptance Testing

2. System Integration Testing
Clubbing all the modules of an application together and testing it as one single system is termed as System Integration Testing

3. Data Integrity Testing
Consider the scenario below:
When some external data (like Flat Files) are transmitted into to your application you expect complete communication of data (say for example if you are expecting Rs.5000/- from the external file to be populated as Rs.5000/- in Transaction Amount field in your application then you are looking out for Integrity of data transferred from external interface to your application. This is Data Integrity Testing
No idea about Forced Error Testing.

Q.  What is the Compatibility testing difference between testing in IE explorer and testing in Firefox?

A. In IE we can look perfectly the web pages where as in Firefox some images and text are not displayed properly

Q.  How do u conduct boundary analysis testing for "ok" pushbutton?

A. There is no boundary value analysis for "Ok" Push-Button.

Q. What is the strength and weakness in testing?

A. Strength: Judgeemnt skills, patience, pessimistic in nature, strong desire quality Weakness: like, i love coffee so i drink coffee every hour

Q.  What do we do when there is a known bug at the time of software release?

A.  If there is any open bug at the time of release we mention in the release note which we send with the release, in open list of issues. As we know if client finds that we have mentioned the issue in release note he will not be worried about the type of testing being done on the application. But if he himself finds that bug it will hurt our company image.

Q.  What is "bug leakage?" and what is "bug release?"

A. The bugs un discovered in the previous stage / cycles is called bug leakage for that stage/cycle. Eg. Suppose you have completed System Testing (ST)
and certified the application as fully tested and send it for UAT. but UAT certainly uncovers some of the bugs which are not found at ST stage. so bugs are leaked from ST stage to UAT. this is called bug leakage.

Q.  Which of the following statements about regression testing are true?
(1) Regression Testing must consist of a fixed set of tests to create a baseline
(2) Regression Testing should be used to detect defects in new features
(3) Regression Testing can be run on every build
(4) Regression Testing should be targeted to areas of high risk and known code change
(5) Regression Testing, when automated, is highly effective in preventing defects

A.  1 4 and 5 are correct

Q. How can we perform testing without expected results?

A. Main concept in testing is the expected result. By knowing the expected behavior of the application or system from SRS and FDS, we can derive a test case. When executed the derived test cases, actual result is noted. Any deviation from the expected is considered as a defect.

In Adhoc testing, there is no need of a test case, but if we want to log a defect, we should know the expected behaviour of the application or a system.

There is only one possibility for this question according to me. Exploratory testing.
An interactive process of concurrent product exploration, test design, and test execution. The heart of exploratory testing can be stated simply. The outcome of this test influences the design of the next test. Tester will explore the product or application and will note down the expected result and will design a test case and execute the test.

Q. What is defect leakage?

A. If any defect which we could not find out in system test environment then it is called as defect leakage.

Q. What are the parameters of Quality cost?

A.  Quality cost or Cost of quality depends on the time factor that is at what time the bug is detected. If the bug is detected at the time of release then the cost of quality will increase & if the bug is detected at requirement phase then the cost of quality will be very less. So the conclusion is the main parameter of Quality cost is "Time at which bug is detected".

Q. Could we test window's calculator through win runner. for e.g. if I have to show get the value of calculator buttons.

A. yes, we can test the window's calculator using win Runner and also you can show the values of buttons.

Q. What is SQA Activities?

A. SQA activities - suggesting & reviewwing the process docuemtents
Example - reviewing project management plan, etc

Q.  What is the difference in writing the test cases for Integration testing and system testing

A. Integration Testing:
Mostly the integration Testing is not done by Test Engineer.
Integration testing test case includes a partial amount of the conditions used for system testing.
System testing = Functionality Testing + Integration + Unit (Complete round of testing)

Q. What is a deliverable ? Can you please mention the names of deliverables in your current project .

A. Test Deliverables:-
1.Test plan document
2.Test case document
3. Test strategic document
4.test script document
5.test scenario document
6.test log document
7.coding guidlines document
8. automation procedure document

Q. What metrics used to measure the size of the software?

A.  There are 4 ways in which u can measure the program size1)Lines of code i.e.LOC2)Function points3)McCabe's complexity metric which is the number of decisions(+1) in a program4)Halstead's metrics that are used to calculate program length

Q.  Let us know your understanding of Audits ?

A. Audit comes under QA. Its a checking of the processes in the organistion which are define are followed by the employee.
In this every product is audited for the process, that its going as per the organistion's define process or not. Reviwing the documents, matrix related to the product are checked.

Q.  What are the contents of Risk management Plan? Have you ever prepared a Risk Management Plan ?

A.  In general it consist of types risk associated and mitigation for it. It also consist of severity. In general RMP is created by PM and updated by Module Leads when needed.

Q. How can you say your project testing is completed? Explain the various factors?

A.  There are so many factors to know this answer.. some main factors are.....
1) Dead line of your Project reaches
2) Your Estimated Budget over.
3) Acives Customer's Requirement with certain percentage of test case passed.
etc......

If you have any quarries/feed back send me on - knowthetesting@gmail.com

Thank you

Ram

Defect Reporting Guidelines

The key to making a good report is providing the development staff with as much information as necessary to reproduce the bug. This can be broken down into 5 points:

1. Give a brief description of the problem
2. List the steps that are needed to reproduce the bug or problem
3. Supply all relevant information such as version, project and data used.
   
4. Supply a copy of all relevant reports and data including copies of the expected results.
5. Summarize what you think the problem is.

When you are reporting a defect the more information you supply, the easier it will be for the developers to determine the problem and fix it.

Simple problems can have a simple report, but the more complex the problem– the more information the developer is going to need.

For example: cosmetic errors may only require a brief description of the screen, how to get it and what needs to be changed.

However, an error in processing will require a more detailed description, such as:

1) The name of the process and how to get to it.

2) Documentation on what was expected. (Expected results)

3) The source of the expected results, if available. This includes spread sheets, an earlier version of the software and any formulas used)

4) Documentation on what actually happened. (Perceived results)

5) An explanation of how the results differed.

6) Identify the individual items that are wrong.

7) If specific data is involved, a copy of the data both before and after the process should be included.

8) Copies of any output should be included.

As a rule the detail of your report will increase based on a) the severity of the bug, b) the level of the processing, c) the complexity of reproducing the bug.

Anatomy of a bug report

Bug reports need to do more than just describe the bug. They have to give developers something to work with so that they can successfully reproduce the problem.

In most cases the more information– correct information– given the better. The report should explain exactly how to reproduce the problem and an explanation of exactly what the problem is.

The basic items in a report are as follows:

Version: This is very important. In most cases the product is not static, developers will have been working on it and if they’ve found a bug– it may already have been reported or even fixed. In either case, they need to know which version to use when testing out the bug.

Product: If you are developing more than one product– Identify the product in question.

Data: Unless you are reporting something very simple, such as a cosmetic error on a screen, you should include a dataset that exhibits the error.

If you’re reporting a processing error, you should include two versions of the dataset, one before the process and one after. If the dataset from before the process is not included, developers will be forced to try and find the bug based on forensic evidence. With the data, developers can trace what is happening.

Steps: List the steps taken to recreate the bug. Include all proper menu names, don’t abbreviate and don’t assume anything.

After you’ve finished writing down the steps, follow them - make sure you’ve included everything you type and do to get to the problem. If there are parameters, list them. If you have to enter any data, supply the exact data entered. Go through the process again and see if there are any steps that can be removed.

When you report the steps they should be the clearest steps to recreating the bug.

Description: Explain what is wrong - Try to weed out any extraneous information, but detail what is wrong. Include a list of what was expected. Remember report one problem at a time; don’t combine bugs in one report.

Supporting documentation:

If available, supply documentation. If the process is a report, include a copy of the report with the problem areas highlighted. Include what you expected. If you have a report to compare against, include it and its source information (if it’s a printout from a previous version, include the version number and the dataset used)

This information should be stored in a centralized location so that Developers and Testers have access to the information. The developers need it to reproduce the bug, identify it and fix it. Testers will need this information for later regression testing and verification.