Tuesday, October 30, 2007

Monday, October 29, 2007

Download some of the important documents here


Software Testing 1



Software Testing 2



QTP Documents



Web Testing



QTP Tutorial



Silk User Guide



Use Case Testing




VB SCRIPT

QA, QC FAQs

1. What is the difference between quality, Quality Control and Testing?

Quality Assurance: A set of activities designed to ensure that the development and/or maintenance process is adequate to ensure a system will meet its objectives.
Quality Control: A set of activities designed to evaluate a developed work product.
Testing: The process of executing a system with the intent of finding defects.

2. Every project need a tester ?

Which projects may not need independent test staff? The answer depends on the size and context of the project, the risks, the development methodology, the skill and experience of the developers, and other factors.

3. What is 'Software Quality Assurance'?

Software QA involves the entire software development PROCESS - monitoring and improving the process, making sure that any agreed-upon standards and procedures are followed, and ensuring that problems are found and dealt with. It is oriented to 'prevention'.

4. what is Verification and Validation?

Verification: "Are we building the product right?", i.e., does the product conform to the specifications.
Validation: "Are we building the right product?", i.e., does the product do what the user really requires

5. What are Test Deliverables?

Test Plan, Test Case, Defect-Fault, and Status Report are the sets of test deliverables in any testing phase.

6. What is a 'walkthrough'?

'walkthrough' is an informal meeting for evaluation or informational purposes. Little or no preparation is usually required.

7. What's an 'inspection'?

An inspection is more formalized than a 'walkthrough', typically with 3-8 people including a moderator, reader, and a recorder to take notes. The subject of the inspection is typically a document such as a requirements spec or a test plan, and the purpose is to find problems and see what's missing, not to fix anything.

8. What makes a good Software Test engineer?

A good test engineer has a 'test to break' attitude, an ability to take the point of view of the customer, a strong desire for quality, and an attention to detail. Tact and diplomacy are useful in maintaining a cooperative relationship with developers, and an ability to communicate with both technical (developers) and non-technical (customers, management) people is useful.

9.How do you perform integration testing?

To perform integration testing, first, all unit testing has to be completed. Upon completion of unit testing, integration testing begins. Integration testing is black box testing. The purpose of integration testing is to ensure distinct components of the application still work in accordance to customer requirements.

10.What's a 'test case'?

A test case is a document that describes an input, action, or event and an expected response, to determine if a feature of an application is working correctly. A test case should contain particulars such as test case identifier, test case name, objective, test conditions/setup, input data requirements, steps, and expected results.

Risk Analysis

Risk's associated with projects are analyzed and mitigation's are documented in this document. Types of risk that are associated are
1. Schedule Risk: Factors that may affect the schedule of testing are discussed.
2. Technology Risk: Risks on the hardware and software of the application are discussed here
3. Resource Risk: Test team availability on slippage of the project schedule is discussed.
4. Support Risk: Clarifications required on the specification and availability of personnel for the same is discussed.

Plan-Do-Check-Act (PDCA)


Software development process is comprised of the following four components:-
Plan : Devise a Plan. Define your objective and determine the strategy and support methods required to achive that objective.
Do: Execute the plan : Create the conditions and perform the necessary training to execute the paln.Make sure every one throughly understands the objectives and the plan.
Check:Check the result :Check to determine whether work is progessing according to the plan and whether the expected results are obtained .Check for performance of the set procedures, changes in conditions, or abnormalities that may appear.
Act: Take necessary action: if your checkup reveals that the work is not being performed according to plan or that results are not what was anticipated , devise measures for appropriate action.Testing only involves only check component of the plan- do -check -act(PDCA) cycle.

SDLC Model

Every system or project has a "life cycle": a birth, life, and death. Here's a simple example of how it works.


Simple English

Techno-babble

Who Does What

Real-Life Example

Birth

"Vision
Statement"

Management or Marketing or Customer says "Wouldn't it be great if ..."

I'm the Chief Executive Officer of this company and I need a nice suit for shareholder meetings.

Basic
Needs

"Business
Requirements"

Business Analyst talks with stakeholders and documents the requirements.

I want to hide my big gut and make me look presentable and sophisticated and successful. Jeans and a T-shirt just won't do.

Specific
Needs

"Functional
Requirements"

Business Analyst and/or Systems Analyst investigates business requirements and available technology, develops a detailed plan and specifications.

Tailor proposes a 3-piece suit, wool, dark colour, with pin-stripes, expansion waist, etc.

Detailed
Design

"System Design
Document"

Systems Analyst produces detailed description of all processes, transaction files, etc.

Tailor shows CEO a drawing of proposed suit and how sophisticated he will appear.

Making
It

"Development"

Programmer uses Functional Requirements document and System Design document to write code.

Tailor cuts the cloth.

Basic
Testing

"Unit Testing"

Programmer tests the code he has written, on his own machine.

Tailor fits the bits of cloth together on a flat table, making sure everything will connect, and he hasn't reversed the sleeves.

Testing
Related
Things

"System Testing"

Programmers test related modules in a separate system test environment. Links or interfaces to other systems are "dummied out" or faked, as they are only interested in that one system at this time.

Tailor works on only the suit jacket, hanging it on a clothes dummy or mannequin. He does not work on the vest or trousers, just concentrates on the jacket. When done with the jacket, he works on the vest, and later the trousers.

Bringing
the
Parts
Together

"Integration
Testing"

Programmers and other testers test related systems in a separate Integration Test environment, similar to Production environment. They test the flow of data from one system to another, ensuring everything hangs together properly.

Tailor puts trousers, vest, jacket on a mannequin and ensures everything hangs together properly. Note that a mannequin is an approximation of the real thing.

At this point, the system is theoretically finished, and ready for production.
But the most important part has not yet been done: Acceptance.

Is it
what we
wanted?

"Acceptance
Testing"

Users test the software, with the original Business Requirements as a reference, ensuring the software does what the business wants, and poses minimal risk to the company.

CEO tries on the suit, and if acceptable, pays for it. If not acceptable, changes are made.

Use it

"Production"

Software is in regular use for 17.5 years.

CEO wears the suit at each shareholders
meeting for 17.5 years.

Death

"De-commissioned"

Software is replaced by something better.

CEO donates suit to Salvation Army.