Tutorial QA

5/12/2018 Tutorial QA - slidepdf.com

http://slidepdf.com/reader/full/tutorial-qa 1/16

Testing Program-

Stage-1

What is the SDLC?

The systems development life cycle is a project management technique that divides complex projects into smaller, more easily managed segments or phases.

Segmenting projects allows managers to verify the successful completion of project phases

before allocating resources to subsequent phases.

Type of SDLC models-

1) Water fall model

2) Prototype model (application developed without functionality)

3) Spiral model

4) Agile model

5) Butterfly Model

6) Itterative model7) RAD model (Rapid application development) that means every Company has its own

Model.

Waterfall model-

The waterfall all model is a sequential software development model (a process for the creation of

software) in which development is seen as flowing steadily downwards (like a waterfall) through

several phases.

The following phases are followed perfectly in sequential order

Requirements specification

DesignCoding

Implementation & Maintenance

Integration & Testing

http://www.selectbs.com/glossary/what-is-a-software-development-process.htm

http://www.selectbs.com/glossary/what-is-a-software-development-process.htm



Fig:-1-WaterFall Model.

Requirement Specification-

– A statement of the functions and behavior of the system required by its users & operators

– General Requirements-

1. Defines broad & detailed objectives of the system

2. e.g., reliable, correct, efficient, user-friendly, expandable

– Gives relationship of Qualitative & Quantitative System Goals.

Design-

Keeping the requirements in mind the system specifications are translated in to a software

representation. In this phase the designer emphasizes on

i) Algorithm

ii) Data structure

iii) Software Architecture

iv) Interface design

In this phase various components always comes first those are input, output, processing and files.

Designer is responsible for all these things. The system design is nothing but a platform for howwell a programmer code. The design phase leads to an output for the next phase i.e. Formal

Requirement Statements.

Requirement

specification

Design

Coding

Implementation &

Maintenance

Integration &

Testing



Coding-

In this phase programmer starts his coding in order to give a full sketch of product. In other words

system specifications are only converted in to machine readable compute code. But sometimes it

is tough for coding people to maintain the design .So for that reason examination and re-

examination of the requirement statement is necessary.

Implementation & Maintenance

- The implementation phase involves the actual coding or programming of the software. Theoutput of this phase is typically the library, executables, user manuals and additional software

documentation. The maintenance phase is the longest phase of the SDLC. In this phase the

software is updated to:

-fulfill the changing customer need-adapt to accommodate change in the external environment

-correct errors and oversights previously undetected in the testing phase.

-enhance the efficiency of the software.

Integration & Testing-

In this phase all programs (models) are integrated and tested to ensure that the complete systems

meet the software requirements. The testing is concerned with verification and validation. Apart

from this Unit testing and Integration testing is done in order to test all classes and functions etc.

Integration testing is done by including unit together with other unit and testing them whole.

Advantages-

1. It can be implemented for all size projects.

2. It leads to a concrete and clear approach to software development.

3. In this model testing is inherent in every phase.

4. Documentation is produced at every stage of model which is very helpful for people who

are involved.

Disadvantage-

The waterfall model is the oldest and the most widely used paradigm.



Prototype Models:

The

Prototyping paradigm (fig-1) begins with communication .the software engineer and customer

meet and define the overall objectives for the software,identifly whatever requirement are known,

and outline areas where further definitions mandatory .a prototyping iteration is planned quickly

and modeling(in the form of a quick design”)occurs. The quick design focuses on a representation

of those aspects of the software that will be visible to the customer/end user (e.g. human interface

layout or output display formats).the quick design leads to the construction of a prototype. the

prototype is deployed and the evaluated by the customer/user feedback is used to refine

requirement for the software iteration occurs as the prototype is turn satisfy the needs of the

customer, while at the same time enabling the developer to better understand what need to be

done.

Constructionof prototype

Deployment

delivery

&feedback

Communication

Quick plan

ModelingQuick design



Ideally, the prototype serves as a mechanism for identifying software requirement. If a working

prototype is built, the developer attempts to make use of existing program fragments or applies

tool (e.g. report generator, window managers) that enable working programs to be generated

quickly.

Advantages-

• Customers can see steady progress.

• This is useful when requirements are changing rapidly, when the customer is reluctant to

commit to a set of requirements or when no one fully understands the application area.

Disadvantages-

• It is impossible to know at the outset of the project how long it will take.

• There is no way to know the number of iterations that will be required

Spiral Model-

Spiral model when the requirements are enhancing

Planning, Risk Analysis, Engineering, Construction & Release & Customer Evaluation.

Customer Communication: Tasks required to establish effective communication between

developer and customer.

Planning: Tasks required to define resources, timelines, and other project related information.

Risk Analysis: Tasks required to assess both technical and management risks.

Engineering: Tasks required to build one or more representatives of the application.



Construction & Release: Tasks required to construct, test, install and provide user support (e.g.,

documentation and training)

Customer evaluation: Tasks required to obtain customer feedback based on evaluation

Advantages

• High amount of risk analysis

• Good for large and mission-critical projects.

• Software is produced early in the software life cycle.

Disadvantages

• Can be a costly model to use.

• Risk analysis requires highly specific expertise.

• Project’s success is highly dependent on the risk analysis phase.

• Doesn’t work well for smaller projects.

The Butterfly Model

The testing activities for testing software products are preferable to follow the Butterfly Model .The following picture depicts the test methodology.

Fig: Butterfly Model

In the Butterfly model of Test Development, the left wing of the butterfly depicts the Test

Analysis. The right wing depicts the Test Design, and finally the body of the butterfly depicts theTest Execution. How this exactly happens is described below.

Test Analysis

Analysis is the key factor which drives in any planning. During the analysis, the analyst

understands the following:

Test Exe

Test Analysis Test D

Test Execution

Test Design



• Verify that each requirement is tagged in a manner that allows correlation of the tests for that

requirement to the requirement itself. (Establish Test Traceability)

• Verify traceability of the software requirements to system requirements.

• Inspect for contradictory requirements.

• Inspect for ambiguous requirements.

•

Inspect for missing requirements.• Check to make sure that each requirement, as well as the specification as a whole, is

understandable.

• Identify one or more measurement, demonstration, or analysis method that may be used to

verify the requirement’s implementation (during formal testing).

• Create a test “sketch” that includes the tentative approach and indicates the test’s objectives.

During Test Analysis the required documents will be carefully studied by the Test Personnel, and

the final Analysis Report is documented.

The following documents would be usually referred:

1. Software Requirements Specification.

2. Functional Specification.

3. Architecture Document.4. Use Case Documents.

The Analysis Report would consist of the understanding of the application, the functional flow

of the application, number of modules involved and the effective Test Time.

Test Design

The right wing of the butterfly represents the act of designing and implementing the test cases

needed to verify the design artifact as replicated in the implementation. Like test analysis, it is a

relatively large piece of work. Unlike test analysis, however, the focus of test design is not to

assimilate information created by others, but rather to implement procedures, techniques, and data

sets that achieve the test’s objective(s).

The outputs of the test analysis phase are the foundation for test design. Each requirement or design construct has had at least one technique (a measurement, demonstration, or analysis)

identified during test analysis that will validate or verify that requirement. The tester must now

implement the intended technique.Software test design, as a discipline, is an exercise in the prevention, detection, and elimination of

bugs in software. Preventing bugs is the primary goal of software testing. Diligent and

competent test design prevents bugs from ever reaching the implementation stage. Test design,

with its attendant test analysis foundation, is therefore the premiere weapon in the arsenal of developers and testers for limiting the cost associated with finding and fixing bugs.

During Test Design, basing on the Analysis Report the test personnel would develop the

following:

1. Test Plan.2. Test Approach.

3. Test Case documents.

4. Performance Test Parameters.

5. Performance Test Plan.

Test Execution

Any test case should adhere to the following principals:



1. Accurate – tests what the description says it will test.

2. Economical – has only the steps needed for its purpose.

3. Repeatable – tests should be consistent, no matter who/when it is executed.

4. Appropriate – should be appropriate for the situation.

5. Traceable – the functionality of the test case should be easily found.

During the Test Execution phase, keeping the Project and the Test schedule, the test casesdesigned would be executed. The following documents will be handled during the test execution

phase:

1. Test Execution Reports.

2. Daily/Weekly/monthly Defect Reports.

3. Person wise defect reports.

After the Test Execution phase, the following documents would be signed off.

1. Project Closure Document.2. Reliability Analysis Report.

3. Stability Analysis Report.

4. Performance Analysis Report.5. Project Metrics.

RAD model-

RAD is a linear sequential software development process model that emphasis an extremely short

development cycle using a component based construction approach. If the requirements are well

understood and defines, and the project scope is constraint, the RAD process enables a

development team to create a fully functional system with in very short time period.

RAD model has the following phases:

1. Business Modeling: The information flow among business functions is defined by

answering questions like what information drives the business process, what information

is generated, who generates it, where does the information go, who process it and so on.

2. Data Modeling: The information collected from business modeling is refined into a set

of data objects (entities) that are needed to support the business. The attributes (character

of each entity) are identified and the relation between these data objects (entities) is

defined.

3. Process Modeling: The data object defined in the data modeling phase are transformed

to achieve the information flow necessary to implement a business function. Processing

descriptions are created for adding, modifying, deleting or retrieving a data object.4. Application Generation: Automated tools are used to facilitate construction of the

software; even they use the 4th GL techniques.

5. Testing and Turn over: Many of the programming components have already been tested

since RAD emphasis reuse. This reduces overall testing time. But new components must

be tested and all interfaces must be fully exercised.

Advantage-



RAD reduces the development time and reusability of components help to speed up development.

All functions are modularized so it is easy to work with.

Disadvantage-

Large projects RAD require highly skilled engineers in the team. Both end customer and

developer side.

Iterative Model-

An iterative lifecycle model does not attempt to start with a full specification of requirements.

Instead, development begins by specifying and implementing just part of the software, which can

then be reviewed in order to identify further requirements. This process is then repeated,

producing a new version of the software for each cycle of the model. Consider an iterative

lifecycle model which consists of repeating the following four phases in sequence:

A Requirements phase, in which the requirements for the software are gathered and analyzed.Iteration should eventually result in a requirements phase that produces a complete and final

specification of requirement

Design phase, in which a software solution to meet the requirements is designed. This may be a

new design, or an extension of an earlier design.

http://www.onestoptesting.com/sdlc-models/iterative-model.asp













- An Implementation and Test phase, when the software is coded, integrated and tested.

- A Review phase, in which the software is evaluated, the current requirements are reviewed, and

changes and additions to requirements proposed.

Iterative software development lifecycle is rigorous validation of requirements, and verification

(including testing) of each version of the software against those requirements within each cycle of

the model. The first three phases of the example iterative model is in fact an abbreviated form of

a sequential V or waterfall lifecycle model.

Advantages-

Early delivery of parts of the functionality for use.

Feedback from the 'live' usage of the delivered increments.

This feedback can be used to prevent similar issues in later deliveriesStaggered cash flows, both for the user organization and the software

Organization.

High priority features are incorporated in early deliveries, and 'GOLD- PLATING' is reduced.

Re-prioritization is possible in the course of the project.

Essential features can be delivered with smaller teams

Disadvantages -

1. Total development costs are higher

2. Total time period for the delivery of the entire functionality is higher.

3. The planning the delivery increment is critical to the success. Wrong planning

Can result in a disaster.

4. The first few deliveries need to be designed for compatibility with subsequent

Deliveries. Poor design of initial deliveries can result in a major rework, costAnd time overruns and inconvenience to the users.

Agile model- Agile model when the customer requirements suddenly changing.

Software is developed for customer's requirements; customer satisfaction is most important,

for the success, the level of motivation of software developers is very important, andCommunication, cooperation, teamwork, and not competition, should be the keywords.

Agile aims to reduce risk by breaking projects into small, time-limited modules or

timeboxes ("iterations") with each interation being approached like a small, self-contained mini-

project, each lasting only a few weeks. Each iteration has it own self-contained stages of analysis,

design, production, testing and documentation. In theory, a new software release could be done at

the end of each iteration, but in practice the progress made in one iteration may not be worth a






release and it will be carried over and incorporated into the next iteration. The project's priorities,

direction and progress are re-evaluated at the end of each iteration.

Agile's aims and characteristics include:

• Customer satisfaction by rapid, continuous delivery of useful software

• Working software is delivered frequently (weeks rather than months)

• Working software is the principal measure of progress.

• Even late changes in requirements are welcomed.

• Close, daily, cooperation between developers and customers

• Face-to-face conversation is the best form of communication.

• Projects are built around motivated individuals, who should be trusted (rather than micro-managed)

• Continuous attention to technical excellence and good design.

• Simplicity

• Self-organising teams

Advantages: - Testing and Developing will be done Simultaneously, There is continous

intercation with the Custonmer.

Disadvantages: - Cost is the main criteria here,

V model-

V-Stands for verification and validation. This model defines conceptual mapping in between

development stage and testing stages..

V-model consists of multiple stages of developing process. Each embedding with multiple stages

of testing process.

The following diagram depicts the ‘V’ Model

Verification Validation

(Static Testing) (Dynamic Testing)

Unit Tests

Integration Tests

System Tests

Acceptance Tests

Detailed Design

Architecture

Specification

Requirements

Coding



The diagram is self-explanatory. For an easy understanding, look at the following table:

SDLC Phase Test Phase

1. Requirements 1. Build Test Strategy.

2. Plan for Testing.

3. Acceptance Test Scenarios Identification.

2. Specification 1. System Test Case Generation.

3. Architecture 1. Integration Test Case Generation.

4. Detailed Design 1. Unit Test Case Generation

The responsibility for testing between the Project & Software Quality Assurance (S.Q.A.) is

as follows:

• Unit testing & integration testing: performed by development team also called white box

testing

• Functional & system testing: performed by we the test engineer also called black box

testing

• User acceptance testing: performed by customer site people with involvement of our

testing team

• Technology Compliance Testing is the responsibility of the Systems Installation &

Support Group.

1. It is the diagrammatical representation of various development & testing stages.

2. The V-model promotes the idea that the dynamic test stages (on the right hand side of the

model) & the V-Model has little to say about static testing on the left hand side.

3. There is rarely a perfect, one-to-one relationship between the documents on the left hand side

and the test activities on the right.

V-Model Dig is as follows-

SRS/BRS User Acceptance

Design /Analysis System Testing

HLD Integration Testing

SDLC LLD Unit Testing STLC

Coding



1. S/w development process starts with req. gathering and analysis. From real client analyst

Category people prepare BRS and SRS documents.

SRS- Software requirements specification is defining functional requirements to be developed

and system requirements to be used.

BRS- is defining the requirements of the customer to be developed as new software.

2. Design: design category people prepare HLD’s & LLD's.

HLD-Designing the overall architecture of system from root module to leaf module.

LLD defines the internal architectural correspondence model (or) functionality.

3. This model is combination of s/w quality assurance (SQA) & s/w quality control (SQC) with

SDLC.

SQA- monitory and measuring the strength of development process is called SQA.

SQC- The validation of the S/W product with respect to the customer requirements and

expectation called SQC.

Use Cases:-

Use Case Diagram

Use case is a description of the interaction between the user and the system. This can also be

described as a way of using specific part of application’s functionality. A Complete collection of

use cases describes all the ways that a user can manipulate a Software system.

Use cases are a very powerful method of describing requirements. They form basis for

• Software Design

• Test Cases

• User documentation

• GUI design

Use cases are written during the requirement phase of the software project. Use cases are written

in a plain English language that user can easily understand. Business analysts that have been

specially trained to develop use cases should write them.

Rational Rose is a tool that can be effectively used to model and also write use cases. However

most use cases are written in MSWord as everyone can easily access them.

Use cases are basically of two types-



• Concrete: Concrete use case is the one that stands alone to accomplish a single goal

• Abstract: Abstract use case is used by more than one use cases but may not have a

specific user oriented goal.

Use case templates-

Use Case Name-

State a concise, results-oriented name for the use case. These reflect the tasks the user needs to be

able to accomplish using the system. Include an action verb and a noun. Some examples:

• View part number information.

• Manually mark hypertext source and establish link to target.

• Place an order for a CD with the updated software version.

Goal-

Without a goal a use case is useless. There is no need for a use case when there is no need for any

actor to achieve a goal. A goal briefly describes what the user intends to achieve with this

use case.

Actors-

An actor is a person or other entity external to the software system being specified who interacts

with the system and performs use cases to accomplish tasks. Different actors often correspond to

different user classes, or roles, identified from the customer community that will use the product.

Name the actor that will be initiating this use case and any other actors who will participate in

completing the use case.

Fig-Actor Inheritance

Trigger- Identify the event that initiates the use case. This could be an external business event or

system event that causes the use case to begin, or it could be the first step in the normal

flow

Preconditions-

List any activities that must take place, or any conditions that must be true, before the use casecan be started. Number each precondition. Examples:

1. User’s identity has been authenticated.

2. User’s computer has sufficient free memory available to launch task.

Postconditions-

Describe the state of the system at the conclusion of the use case execution. Number each

postcondition. Examples:



1. Document contains only valid SGML tags.

2. Price of item in database has been updated with new value.

Use Case Relationships-

Includes-

In one form of interaction, a given use case may include another. The first use case often depends

on the outcome of the included use case. This is useful for extracting truly common behaviors

from multiple use cases into a single description. The notation is a dashed arrow from the

including to the included use case, with the label "«include»". This usage resembles a macro

expansion where the included use case behavior is placed inline in the base use case behavior.

There are no parameters or return values.

Tip: Apply «include» When You Know Exactly When To Invoke The Use Case

Extend-

In another form of interaction, a given use case (the extension) may extend another. This

relationship indicates that the behavior of the extension use case may be inserted in the extended

use case under some conditions. The notation is a dashed arrow from the extension to the

extended use case, with the label "«extend»". This can be useful for dealing with special cases

(when A extends B, A is a special case of B), or in accommodating new requirements during

system maintenance and extension.

Modelers use the «extend» relationship to indicate use cases that are "optional" to the base use

case. Depending on the modeler's approach "optional" may mean "potentially not executed with

the base use case" or it may mean "not required to achieve the base use case goal."

To make the points at which extension may occur explicit extension points may be defined in a

use case which are listed in a compartment below the use case.

Tip: Apply «extend» When A Use Case May Be Invoked Across Several Use Case Steps



Benefits-of Use Cases-

• Well written Use cases have proven to be easily understandable by business users, and

thus to act as a bridge between them and software developers.

• Use cases can put requirements in context, describing them in clear relationship to

business tasks

Tutorial QA

Documents

Transcript of Tutorial QA