Interview Questions Part 1

Q. Give me full explanation for SDLC process.

A. SDLC means Software Development Life Cycle.
In this approach following activities are carried out.
1. Requirements gathering
2.  Analysis and planning

3.  Design

4.  Coding

5. Testing

6. Maintenance

In this approach testing comes into picture after coding and conducted by same development people. Testing can be have a place in any of these stage depends on the Development Models.

Q.  What is the testing life cycle?

A. There is no standard, but it consists of:
Test Planning (Test Strategy, Test Plan(s), Test Bed Creation)
Test Development (Test Procedures, Test Scenarios, Test Cases)
Test Execution
Result Analysis (compare Expected to Actual results)
Defect Tracking
Reporting

OR

I have done some modification in the above answer , please find below the same :
Test Life Cycle :
1. Test Plan :
a)Test Scope
b)Test Strategy
c)Test scheduling
d)Test Estimation
e)Test Bed Creation
f)Test Techniques
2. Test Development:
a)Test Scenarios
b)Test Case Authoring
3. Test Execution
4. Result Analysis ( comparing the expected and actual result)
5.Defect Tracking -->
a)Filing of new defect
b)Verification of defect
c)closure of defect
6.Test Regression
7.Test Stop.

Q.  Difference between Configuration Management and Version Control.

A. Version Control is part of Configuration Management.
Read the following, you will understand.

Configuration Management is the approach used in managing the individual components (software & hardware) that make up the? System? It is important not to confuse ? Configuration Management?  with ? Change Management?
Change management is concerned with changes made to an item/s. Whereas Configuration Management is concerned with managing all of the individual items, and all of the items as a whole (System).

Software exists in two forms; non-executable (source code) and executable code (object code). When errors are found in the software, changes may be required to be made to the source code. When this situation occurs, it is imperative to be able to identify which version of code to change. There may also arise a situation where two Developers need to make changes to the code. If the Developers are unaware of the other updating the version, then both updated versions could be saved causing lost changes or worse. Also, Testers may not be aware of which version of code to test with causing further problems.

When testing is complete, a Test Leader will need to demonstrate that the testing has been completed on a specific version of code, a necessity to ensure correct test coverage.

It is not only software and hardware components that need to be controlled, but also documentation, as project members will need to ensure they work from the correct versions.

Configuration Management consists of the following four parts:
Configuration Identification
Configuration Control
Status Accounting
Configuration Auditing
Configuration Identification
This is the process of identifying all of the individual items that will be subject to version control within the project. Details such as version and status may be recorded.

Configuration Control
This activity ensures that any changes are controlled and monitored. A master copy should be kept in order for people to be able to check out the latest version of the document to avoid two people working on the same document version. Items such as ?dates?, ?version numbers? and ?updated by? are details that may be recorded. Once the item has been updated, the item can be checked back in, resulting in it becoming the master copy. A history will be displayed when multiple versions exist.
Status Accounting
this is the process of recording and reporting on the current status of the item. It is in effect the ability to be able to view the current state of the item.
Configuration Auditing
Configuration Auditing is used to ensure that the control process that is used is being correctly adhered to

Q.  How do you ensure the quality of the product?

A. The quality of the product can be ensure by look into the minimum bugs in a products as per the standard maintained by the organization for the clients. That means if a company is the six sigma oriented company then there should be at least  3-4 bugs per millions.

Q. What if there isn't enough time for thorough testing?

A. Since it's rarely possible to test every possible aspect of an application, every possible combination of events, every dependency, or everything that could go wrong, risk analysis is appropriate to most software development projects.

Use risk analysis to determine where testing should be focused. This requires judgment skills, common sense and experience. The checklist should include answers to the following questions:
* Which functionality is most important to the project's intended purpose?
* Which functionality is most visible to the user?
* Which functionality has the largest safety impact?
* Which functionality has the largest financial impact on users?
* Which aspects of the application are most important to the customer?
* Which aspects of the application can be tested early in the development cycle?
* Which parts of the code are most complex and thus most subject to errors?
* Which parts of the application were developed in rush or panic mode?
* Which aspects of similar/related previous projects caused problems?
* Which aspects of similar/related previous projects had large maintenance expenses?
* Which parts of the requirements and design are unclear or poorly thought out?
* What do the developers think are the highest-risk aspects of the application?
* What kinds of problems would cause the worst publicity?
* What kinds of problems would cause the most customer service complaints?
* What kinds of tests could easily cover multiple functionalities?
* Which tests will have the best high-risk-coverage to time-required ratio?

Q. What's normal practices of the QA specialists with perspective of software?

A. These are the normal practices of the QA specialists with perspective of software
[note: these are all QC activities, not QA activities.]
1-Desgin Review Meetings with the System Analyst and If possible should be the part in Requirement gathering
2-Analysing the requirements and the desing and to trace the desing with respect to the requirements
3-Test Planning
4-Test Case Identification using different techniques (With respect to the Web Based Applciation and Desktoip Applications)
5-Test Case Writing (This part is to be assigned to the testing engineers)
6-Test Case Execution (This part is to be assigned to the testing engineers)
7-Bug Reporting (This part is to be assigned to the testing engineers)
8-Bug Review and thier Analysis so that future bus can be removed by desgining some standards

Q. What is the difference between high level design and low level design?

A. Every software design is presenting with one high level design and one low level design.Because high level design is a system level document and low level desings are functionalise and modules level documents.

OR

High Level Document and Low Level Document are comes under Software Requirement Specifications (SRS). It comes under the Design phase which is in SDLC.

High Level Documents are design documents wat exactly meaning is what the customer wants this comes under HLDD.

Low Level Documents in this we have in which way client wants the application and describes about the procedures and sub routins and basic documents.

Q. What is the difference between Quality Assurance and Quality Control?

A. Quality assurance is set of activitates designed to ensure that maintenance process is adequate to ensure a system will meet it object.
Quality control is set of activitates designed to evaluate a developed work product

OR

Quality Assurance deals with Monitoring and Improving entire SDLC.
Quality Control(QC) deals with Walkthroughs, Reviews and Inspection.

If you have any quarries/feed back send me on - rampeddireddy2006@gmail.com, ram@examsinfo.in.

Thank you

Ram