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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 2/16
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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 3/16
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.
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 4/16
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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 5/16
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.
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 6/16
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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 7/16
• 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:
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 8/16
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-
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 9/16
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.
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 10/16
- 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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 11/16
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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 12/16
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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 13/16
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-
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 14/16
• 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:
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 15/16
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
5/12/2018 Tutorial QA - slidepdf.com
http://slidepdf.com/reader/full/tutorial-qa 16/16
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
Top Related