What
is Testing?
To ensure that whether developed
application is working according to the customer requirements or not.
Why to test?
Testing becomes absolutely essential
to make sure the software works properly
and does the
work that it
is meant to
perform.
What to test?
Any
working product which
forms part of
the software application
has to be tested. Both data and programs must be tested.
How often to test?
When
a program (source
code) is modified
or newly developed, it has
to be tested.
Who tests?
Programmer, Tester and Customer
Need
for Testing:
The need of testing is to find out
errors in the application. The good reasons of testing are:
Ø Quality
Assurance.
Ø Verification
and validating the product/application before it goes live in the market.
Ø Defect
free and user friendly, Meets the customer requirements.
What
is Quality?
The
standard of something as measured against other things of a similar kind; the degree of excellence of
something .Our objective is to exceed the client satisfaction by delivery of
quality product and services.
What
is Software Testing?
Software
testing is a process used to identify the correctness, completeness, and quality
of developed computer software.
In
simple words, software testing is an activity to check whether the actual
results match the expected results and to ensure that the software system
is defect free.
What
is a Product and a Project?
Project:
1. Specifications will be given by Client
2. Client views / requirements will be considered
3. End user is one
4.Once developed it will be finished
Eg: Wipro, TCS like companies
Product:
1. Company designs product
2. Company with own views (based on market) develops product
3. End users are more than one
4. Never ending process
5. Customization is possible.
Eg: Microsoft and their products like MS_Office, MS Visual Studio
Ways
of Projects:
Manual
to Automation
Client
is having any software up to now. So Client is asking the software company to
develop the new software.
Migration
Client
is already having software with that client is facing some problems. So client
is asking for same software in another environment.
Enhancements
Client is already having software, in
order to increase the business he will go for some new business plans. That new
business planned software will be developed by the software company and attach
it to the existing software.
Maintenance
Client is already having software and
using that. At the time of using the software if any problems occurs then the
software company will give the support.
SDLC (Software Development
Life Cycle)
Ø A
Software Process is a set of related activities that leads to the production of
a software product.
Ø The
phases that are necessary to develop and maintain a software system is called
“SDLC”. The steps are shown in the graph above.
Phases
in SDLC:
Requirements
Gathering
In this Phase, information is
gathered from the client. Mainly this is done by the business analyst. The
documents prepared in this document are:
Business/Customer/User
Requirement Document Specification (BRS/CRS/URS)
Analyzing
In
this Phase, Software team will analyze the requirement and prepare requirement
document that will explain every functionality that are needed by the owner.
The requirement document will be the main document for the developers, testers
and database administrators. In other words, this is the main document that
will be referred all the project affected members.
The
documents prepared in this phase is Software
Requirement Specification (SRS), prepared based on the BRS.
Design
Analysis
and Design phases are very crucial in the whole development cycle. During this phase,
the software’s overall structure is defined. Depends on the type and scope of
the project, architects will go for different types of designs like Use Case
Design, User Interface Design, E-R Designs like Sequential diagram, Collaboration
diagram, class diagram, e.t.c.
The
designs are mainly divided into two types,
High
Level Design (HLD) – Describes the overall flow of project.
Low
Level Design (LLD) – Describes the internal logic.
Coding
Developers
will develop the code based on the design and requirement documents. It is not
possible to develop the total code at a time. So, developers will prepare
coding for the small parts of the project and then by joining the developed
code will form a Module also called Unit Testing. Combining the modules is
called integration testing.
Once
one part of the application or project is developed it will be released to the
testing department as a build for testing purpose.
Development
Manager, Development Leads, Senior Developers and Developers involved in this
phase.
Testing
Testing
team will receive the builds from development department. In this phase testing
team will test the application output wise. Testing Team use different
techniques to test the application consistency. At the time of testing the
application testing team will get the defects or Bugs and that bugs will report
to the development team for code modification. This is a cycle process up to
the defect free application.
Implementation
Once
the application is stable in testing phase then it will be ready for release.
Technical team will install the project in the client location along with that
software company will hand over all the version wise artifacts to the client.
Maintenance
Once the projector application is
released, Client will use the application. If any issues comes at the time of
using by the client, Software company will give the support to the client.
SDLC
Models:
There
are various software development approaches defined and designed which are used/employed
during development process of software, these approaches are also referred as
"Software Development Process Models". Each process model follows a particular
life cycle in order to ensure success in process of software development.
Waterfall Model
Waterfall
approach was first Process Model to be introduced and followed widely in Software
Engineering to ensure success of the project. In "The Waterfall"
approach, the whole process of software development is divided into separate
process phases. All these phases are cascaded to each other so that second
phase is started as and when defined set of goals are achieved for first phase
and it is signed off, so the name "Waterfall Model". All the methods
and processes undertaken in Waterfall Model are more visible. Used when Project
requirements are Standard
Advantages
of Water fall Model:
Simple
and easy to use.
Easy
to manage due to the rigidity of the model – each phase has specific
deliverables and a review process.
Phases
are processed and completed one at a time.
Works
well for smaller projects where requirements are very well understood.
Disadvantages
using Water Model:
Adjusting
scope during the life cycle can kill a project
No
working software is produced until late during the life cycle.
High
amounts of risk and uncertainty.
Poor
model for complex and object-oriented projects.
Poor
model for long and ongoing projects.
Poor
model where requirements are at a moderate to high risk of changing.
When to use the Waterfall Model:
Requirements are very well known
Product definition is stable
Technology is understood
New version of an existing product
Porting an existing product to a new platform.
Prototype
Model:
When
client is not clear about the requirements.
S/W
initiates, develop prototypes à submit
to client à client
selects one Prototype.
Advantages
of Prototyping Model
When
prototype is shown to the user, he gets a proper clarity and 'feel' of
the functionality of the software and he can suggest changes and
modifications.
It
reduces risk of failure, as potential risks can be identified early and
mitigation steps can be taken.
Disadvantages
of Prototyping Model:
Prototyping
is usually done at the cost of the developer. So it should be done using
minimal resources.
Once
we get proper requirements from client after showing prototype model, it may be
of no use. That is why; sometimes we refer to the prototype as
"Throw-away" prototype.
It
is a slow process. Too
much involvement of client is not always preferred by the developer. Too many changes can
disturb the rhythm of the development team.
Incremental
Model:
What
is Incremental Model?
Construct a partial implementation of a total system
Then slowly add increased functionality
The incremental model prioritizes requirements of the
system and then implements them in groups.
Each subsequent release of the system adds function to
the previous release, until all designed functionality has been implemented.
Advantages
of Incremental Model
Develop high-risk or major functions first
Each release delivers an operational product
Customer can respond to each build
Uses “divide and conquer” breakdown of tasks
Lowers initial delivery cost
Initial product delivery is faster
Customers get important functionality early
Risk of changing requirements is reduced
Disadvantages
of Incremental Model
Requires good planning and design
Requires early definition of a complete and fully
functional system to allow for the definition of increments
Well-defined module interfaces are required.
Total cost of the complete system is not lower
When to use the Incremental Model
Most of the requirements are known up-front but are
expected to evolve over time
A need to get basic functionality to the market early
On projects which have lengthy development schedules
On a project with new technology
Spiral Model
We
use when Project is large. Client will give new requirements when we deliver a
product.
Spiral Model Strengths
Provides early indication of insurmountable risks,
without much cost
Users see the system early because of rapid
prototyping tools
Critical high-risk functions are developed first
The design does not have to be perfect
Users can be closely tied to all lifecycle steps
Early and frequent feedback from users
Cumulative costs assessed frequently
Spiral Model Weaknesses
Time spent for evaluating risks too large for small or
low-risk projects
Time spent planning, resetting objectives, doing risk
analysis and prototyping may be excessive
The model is complex Risk assessment expertise is required
Spiral may continue indefinitely
Developers must be reassigned during non-development
phase activities May be hard to define objective, verifiable milestones
that indicate readiness to proceed through the next iteration.
When to use Spiral Model
When creation of a prototype is appropriate
When costs and risk evaluation is important
For medium to high-risk projects
Users are unsure of their needs;
Requirements are complex,
new product line
Significant changes are expected (research and
exploration)
Rapid Application Model (RAD)
Requirements planning phase. User description phase –
automated tools capture information from users.
Construction phase –
productivity tools, such as code generators, screen generators, etc. inside a
time-box. (“Do until done”) Cut over phase -- installation of the system, user
acceptance testing and user training
RAD Model Strengths
Reduced cycle time and improved productivity with
fewer people means lower costs
Customer involved throughout the complete cycle
minimizes risk of not achieving customer satisfaction and business needs
Focus moves from documentation to code.
Uses modelling concepts to capture information about
business, data, and processes.
RAD Model Weaknesses
Accelerated development process must give quick
responses to the user
Risk of never achieving closure. Hard to use with
legacy systems
Developers and customers must be committed to
rapid-fire activities in an abbreviated time frame.
When to use RAD Model?
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
V-Shaped SDLC Model
Major activities in this V-model are verification and validation
of the product.
Verification is nothing but “whether we are developing the project
or not?
Validation is nothing but “Whether the developed application is correct
or not?
Testing of the product is planned in parallel with a
corresponding phase of development
V-Shaped Strengths
Emphasize planning for verification and validation of
the product in early stages of product development. Each deliverable must be
testable
Project management can track progress by milestones.
Easy to use
V-Shaped Weaknesses
Does not easily handle concurrent events
Does not handle iterations or phases
Does not easily handle dynamic changes in requirements
Does not contain risk analysis activities
When to use the V-Shaped Model
Excellent choice for systems requiring high
reliability hospital patient control applications
All requirements are known up-front.
Solution and technology are
known.
Fish
Model
This is a process
oriented company's development model. Even though it is a time consuming and
expensive model, One can be rest assured that both verification and validation
is done paralley by separate teams in each phase of the model. So there are two
reports generated by the end of each phase , one for validation and one for
verification. Because all the stages except the last delivery and maintenance
phase is covered , by the two parallel processes, the structure of this model looks
like a skeleton between two parallel lines, hence the name fish model.
Advantages
of Fish Model:
Due
to thorough verification and validation Fish Model yields a quality product.
Disadvantages of Fish Model:
It is more time
consuming, more expensive.
Agile
Process
Agile software development
is a conceptual framework for undertaking software engineering projects that
embraces and promotes evolutionary change throughout the entire life-cycle of
the project. When the client
requirements are changing rapidly we use Agile Process.
Again different models
are available in this Agile Process:
Scrum Model
Agile Modeling
Extreme Programming
Agile Unified Process
Scrum
Model:
In
Scrum, the product backlog is divided into succinct work cadences, known as
Sprints, which are typically one week to four weeks in duration. The Sprints
are of fixed duration and never extended.
At the
start of a sprint, a Sprint Planning Meeting is held and team members commit to
delivering fixed set of features (Sprint Backlog) from the product backlog.
During the Sprint, the chosen set of features does not change.
Throughout
the Sprint, Daily Sprint Meetings (Duration: 15 Minutes) are conducted to share
the progress. At the end of the sprint, the sprint backlog features are done;
they are coded, tested, and integrated into the evolving product or system.
At the
end of the sprint a Sprint Review Meeting is conducted in which the team
reviews the Sprint with stakeholders, demonstrates what they have built, and
obtains feedback that can be incorporated in the next Sprint.
Scrum
development inevitably involves learning, innovation, and surprises, emphasizes
taking a short step of development, inspecting both the resulting product and
the efficacy of current practices, and then adapting the product goals and
process practices.
Product
Owner: The Product Owner is responsible for maximizing return on
investment (ROI) by identifying product features, translating these into a
Product Backlog (prioritized feature list), deciding which features should be
at the top of the backlog for the next Sprint, and continually re-prioritizing
and refining the backlog.
Scrum Master: The
person responsible for the Scrum process, making sure it is used correctly and
maximizes its benefits.
Team: A
cross-functional group of people responsible for managing itself to develop the
product, mainly consisting of developers, testers, analyst, designer, architect
etc.
In the simple words we
define it as :
Client will give the
small requirements usually called as UserSTORIES
Developers will take each
story at a time , develop & pass it to testing team
Testing team test it and
deliver to client if passed or else to developers for modification.
Client will test it again
and accept it if he likes it.
Sprint:
Sprint is nothing but one
lifecycle in project development. Each Sprint contains some no.of stories,
We have some sprint
meetings at starting & ending of sprint.
Requirement
change Management Process:
When a request for
requirement change comes from the client then requirement change management
process will be undertaken by the Change Control Board(CCB).
CCB wont accept change
blindly,will perform Impact Analysis.
Accept if passed the
Impact Analysis else CCB will reject that change.
Major
activities in Requirement change Management Process:
Performing Impact
Analysis
Maintaining Requirement
Change Log.
Budjet Renewal, Time-Line
Renewal
Version
Controlling Manually:
When we are controlling
the document versions manually we are going to maintain a server repository where all designations will
store the documents.
Steps
to Connect to the Server Repository:
Step I: 
Run.
Step II : Enter the server IP
Address and Click on OK.
Step III : Enter Username , Password
and Click on OK.
After clicking on OK button it will display the Server
Repository related file.
Folder
Structure:
Version
Controlling using Version Controlling
Tool(VSS):
Microsoft Visual SourceSafe (VSS) is a source control software package oriented towards small software development
projects. Like most source control systems, SourceSafe creates a virtual library of computer files. While most commonly
used for source code, SourceSafe can actually handle
any type of file in its database, but prior versions have been
shown to be unstable when confronted with large amounts of non-textual data
(images, binary executables, etc.).
History
of VSS:
VSS was initially
developed by One Tree software company and later taken over by Microsoft
Corporation. In VSS we have different versions. They are : VSS 6.0 ; VSS 2005 ;
VSS 2008.
Architecture
of VSS:
VSS is available in 2
ways. They are (i) VSS Client Software , (ii)
VSS Server Software.
Vss Client Software is
going to be installed in Clients machine (local system) and VSS Server software
is going to be maintained in the inbuilt database in the server.
Through VSS Client we are
going to connect to server software.
