Classic Waterfall
The first introduced Process Model is Waterfall Model hence it is basic mode of SDLC which is also known as mother of all other model. It is simple to understand and use. It is referred to as a linear-sequential life cycle model where each phase should be executed fully before the next phase can begin. This model is basically used for the project where there are no uncertain requirements and small. Here testing starts only when the development is complete. The phases do not overlap in waterfall model.
Discover the Waterfall Model's Sequential Phases in Software Testing: Uncover the structured approach to testing, understand its significance, and explore activities at each stage for ensuring high-quality software outcomes.
1️⃣ Requirements Analysis — understanding and analyzing the software requirements to create comprehensive test plans and strategies. Testers collaborate with stakeholders to gather requirements and define testable criteria based on functionality, performance, security, and other aspects.
2️⃣ Design — creating detailed test cases, test scenarios, and test data based on the requirements and design specifications. Testers also develop test environments and prepare testing tools and resources needed for the upcoming testing phases.
3️⃣ Implementation — executing the test cases and scenarios developed earlier to validate the software against the specified requirements. Testers report defects or issues found during testing and work closely with developers to resolve them before moving to the next phase.
4️⃣ Testing — comprehensive testing activities, including unit testing, integration testing, system testing, and acceptance testing. Testers verify that the software functions correctly, meets performance expectations, and fulfills user requirements according to the predefined test plans.
5️⃣ Deployment — conducting final acceptance testing to ensure the software is ready for deployment. They verify that all identified defects have been addressed, and the software meets the quality standards before it is released to the production environment.
6️⃣ Maintenance — conducting regression testing to ensure that software updates or changes do not introduce new defects. They also monitor the software in the live environment, gather user feedback, and contribute to ongoing improvements and enhancements to maintain software quality over time.
Waterfall Strengths
Easy to understand, easy to use
Provides structure to inexperienced staff
Milestones are well understood
Sets requirements stability
Good for management control (plan, staff, track)
Works well when quality is more important than cost or schedule
Waterfall Deficiencies:
All requirements must be known upfront
Deliverables created for each phase are considered frozen – inhibits flexibility
Can give a false impression of progress
Does not reflect problem-solving nature of software development – iterations of phases
Integration is one big bang at the end
Little opportunity for customer to preview the system (until it may be too late)
Defects were being found too late in the life cycle, as testing was not involved until the end of the project. Testing also added lead time due to its late involvement
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.
1.The V-model provides guidance that testing needs to begin as early as possible in the life cycle.
2.It also shows that testing is not only an execution-based activity. There are a variety of activities that need to be performed before the end of the coding phase. These activities should be carried out in parallel with development activities, and testers need to work with devel-opers and business analysts so they can perform these activities and tasks and produce a set of test deliverables.
3. The work products produced by the developers and business analysts during development are the basis of testing in one or more levels.
4.By starting test design early, defects are often found in the test basis documents.
5.A good practice is to have testers involved even earlier, during the review of the (draft) test basis documents.
6. The V-model is a model that illustrates how testing activities (verification and validation) can be integrated into each phase of the life cycle.
7. Within the V-model, verification testing takes place especially during the early stages, e.g. reviewing the user requirements, and late in the life cycle, e.g. during user acceptance testing.
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
When it can be modified to handle changing requirements beyond analysis phase
Solution and technology are known
In this Prototype Model before designing phase, a prototype is developed, tested, reviewed and approved by the customer, after that design will be ready for coding, testing, installation and maintenance will takes place. This prototype is prepared based on the customer requirements. Prototype testing is checking for the required components are present or not.
By using this prototype, customer can understand the requirements of desired system and also the customer can get an “actual feel” of the system. It is an attractive idea for complex and bigger systems.
There are 2 approaches for this model:
- Rapid Throwaway Prototyping –
This technique offers a useful method of exploring ideas and getting customer feedback for each of them. In this method, a developed prototype need not necessarily be a part of the ultimately accepted prototype. Customer feedback helps in preventing unnecessary design faults and hence, the final prototype developed is of a better quality.
- Evolutionary Prototyping –
In this method, the prototype developed initially is incrementally refined on the basis of customer feedback till it finally gets accepted. In comparison to Rapid Throwaway Prototyping, it offers a better approach which saves time as well as effort. This is because developing a prototype from scratch for every iteration of the process can sometimes be very frustrating for the developers
Main Phases
1. Requirements gathering
2. Quick design
3. Build prototype
4. Customer evaluation of prototype
5. Refine prototype
Iterate steps 4.and 5. to “tune” the prototype
6. Engineer product
Prototyping
Advantages –
- The customers get to see the partial product early in the life cycle. This ensures a greater level of customer satisfaction and comfort.
- New requirements can be easily accommodated as there is scope for refinement.
- Missing functionalities can be easily figured out.
- Errors can be detected much earlier thereby saving a lot of effort and cost, besides enhancing the quality of the software.
- The developed prototype can be reused by the developer for more complicated projects in the future.
- Flexibility in design.
Disadvantages –
- Costly w.r.t time as well as money.
- There may be too much variation in requirements each time the prototype is evaluated by the customer.
- Poor Documentation due to continuously changing customer requirements.
- It is very difficult for the developers to accommodate all the changes demanded by the customer.
- There is uncertainty in determining the number of iterations that would be required before the prototype is finally accepted by the customer.
- After seeing an early prototype, the customers sometimes demand the actual product to be delivered soon.
- Developers in a hurry to build prototypes may end up with sub-optimal solutions.
- The customer might lose interest in the product if he/she is not satisfied with the initial prototype.
Use –
The Prototyping Model should be used when the requirements of the product are not clearly understood or are unstable. It can also be used if requirements are changing quickly. This model can be successfully used for developing user interfaces, high technology software-intensive systems, and systems with complex algorithms and interfaces. It is also a very good choice to demonstrate the technical feasibility of the product.
Not all life cycles are sequential. There are also iterative or incremental life cycles where, instead of one large development time line from beginning to end, we cycle through a number of smaller self-contained life cycle phases for the same project. As with the V-model, there are many variants of terative life
cycles.
A common feature of iterative approaches is that the delivery is divided into increments or builds with each increment adding new functionality. The initial increment will contain the infrastructure required to support the initial build functionality. The increment produced by an iteration may be tested at several levels as part of its development. Subsequent increments will need testing for the new functionality, regression testing of the existing functionality, and inte-gration testing of both new and existing parts. Regression testing is increasingly important on all iterations after the first one. This means that more testing will be required at each subsequent delivery phase which must be allowed for in the project plans. This life cycle can give early market presence with critical func-tionality, can be simpler to manage because the workload is divided into smaller pieces, and can reduce initial investment although it may cost more in the long run. Also early market presence will mean validation testing is carried out at each increment, thereby giving early feedback on the business value and fitness-for-use of the product.
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
Incremental Model Strengths:
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
Incremental Model Weaknesses:
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 (some will be developed long before others)
Total cost of the complete system is not lower
When to use the Incremental Model:
Risk, funding, schedule, program complexity, or need for early realization of benefits.
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
-Objective: overcome problems of other models, while combining their advantages
-Key component: risk management (because traditional models often fail when risk is neglected)
-Development is done incrementally, in several cycles-Cycle as often as necessary to finish.
Main Phases
Ø Determine objectives, alternatives for development, and constraints for the portion of the whole system to be developed in the current cycle.
Ø Evaluate alternatives, considering objectives and constraints: identify and resolve risks
Ø Develop the current cycle’s part of the system, using evolutionary or conventional development methods (depending on remaining risks); perform validation at the end
Ø Prepare plans for subsequent phases.
Advantages of Spiral Model
-Most realistic for approach for large systems envelopment
-Allows identification and resolution of risks early in the development
• 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
Problems with Spiral Model
-Difficult to convince customer that this approach is controllable
-Requires significant risk assessment expertise to succeed
-Not yet widely used: efficacy not yet proven.
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
Long-term project commitment unwise because of potential changes to economic priorities
Users are unsure of their needs
Requirements are complex
New product line
Significant changes are expected (research and exploration)
Rapid Application Development (RAD) is formally a parallel development of
functions and subsequent integration.
Components/functions are developed in parallel as if they were mini projects, the developments are time-boxed, delivered, and then assembled into a working prototype. This can very quickly give the customer something to see and use and to provide feedback regarding the delivery and their requirements. Rapid change and development of the product is possible using this methodology. However the product specification will need to be developed for the product at some point, and the project will need to be placed under more formal controls prior to going into production. This methodology allows early validation of technology risks and a rapid response to changing customer requirements
Requirements planning phase (a workshop utilizing structured discussion of business problems)
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”)
Cutover phase -- installation of the system, user acceptance testing and user training
RAD Strengths:
Reduced cycle time and improved productivity with fewer people means lower costs
Time-box approach mitigates cost and schedule risk
Customer involved throughout the complete cycle minimizes risk of not achieving customer satisfaction and business needs
Focus moves from documentation to code (WYSIWYG).
Uses modeling concepts to capture information about business, data, and processes.
RAD Weaknesses:
Accelerated development process must give quick responses to the user
Risk of never achieving closure
Hard to use with legacy systems
Requires a system that can be modularized
Developers and customers must be committed to rapid-fire activities in an abbreviated time frame.
When to use RAD:
Reasonably well-known requirements
User involved throughout the life cycle
Project can be time-boxed
Functionality delivered in increments
High performance not required
Low technical risks
System can be modularized
================================================================================
AGILE METHODOLOGY
Topics Covered:
Agile and Scrum Process
• What is Scrum and Scrum Team
• What is Sprint
• What is User Story
• How to give story points / How to estimate user story
• What is Definition of Done and Definition of Ready
• Different Sprint Activities:
• Sprint Planning / Backlog Refinement / Sprint Review / Sprint Retrospective
Jira Tool
• How to install and configure JIRA tool
• How to create an EPIC/User Stories in JIRA
• Creating sprints in Jira
• Sprint life cycle in JIRA
• Backlogs in JIRA
• Creating bugs in Jira
• How to write test cases in JIRA with Zephyr plugin
• Creating Test Cycles and Execute Test cases in Jira
ProductBacklog:
All the new requirementss/EPIC/userstories are available
What is Agile?
AGILE is a methodology that promotes continuous iteration of development and testing throughout the software development life cycle of the project. Both development and testing activities are concurrent unlike the Waterfall method.
What
is Agile Testing?
Unlike the WaterFall
method , Agile Testing can begin at the start of the project with continuous
integration between development and testing. Agile Testing is not sequential
(in the sense its executed only after coding phase) but continuous.
Agile team works as
single team towards a common objective of achieving Quality .Agile Testing has
shorter time frames called iterations (say from One to Four weeks ). This
methodology is also called release or delivery driven approach since it gives
better prediction on the workable products in short duration of time.
Methodologies
of Agile Testing
There are various methodologies present in
agile testing and those are listed below:
Scrum
SCRUM is an agile development method which concentrates
particularly on how to manage tasks within a team based development
environment. Basically, Scrum is derived from activity that occurs during rugby
match. Scrum believes in empowering the development team and advocates working
in small teams (say- 7 to 9 members). It consists of three roles and their
responsibilities are explained as follows:
Scrum Master:
Master is responsible for setting up the
team, sprint meeting and removes obstacles to progress
Scrum Master – ensures Scrum process is followed; not
the team leader
Product owner
The Product Owner
creates product backlog, prioritizes the backlog and is responsiblefor the
delivery of the functionality at each iteration
Product Owner – is voice of customers; should not be
same person as Scrum Master
Product owner create the user stories(new functions/features)
Scrum Team
Team manages its own
work and organizes the work to complete the sprint or cycle
Product Backlog
This is repository where requirements are
tracked with details on the no of requirements to be completed for each
release. It should be maintained and prioritized by scrum master and it should
be distributed to the scrum team. Team can also request for new requirement
addition or modification or deletion
Phases of Scrum
testing:
There are three phases of scrum testing
,elaborated as follows:
Test Design
Ø
User stories are used
for development of test cases .User stories are written by the product owner.
User stories are short description of functionalities of the System Under Test.
Example for Insurance Provider is –Premium can be paid using online system
Ø
Test Cases are
developed based on user stories which should be reviewed/approved by business
analysts/QA manager/product Manager and the customers
Test Execution
Ø
Test execution is
carried out in a lab where both tester and developer work hand in hand.
Ø
Defect are logged in
Defect Management tool which are tracked on a daily basis. Defects can be
discussed during scrum meeting
Ø
Defects are retested
as soon as it is fixed and deployed for testing
Test Automation
Ø
This also gains
importance due to short delivery timelines
Ø
Test Automation can be
achieved by utilizing various opensource or paid tools available in the market
.
Ø
This proves effective
in ensuring that everything that needs to be tested was covered. Sufficient
Test coverage can be achieved with the close interaction with the team.
Managing
Sprint(Cycle) meeting
is held at the beginning to decide the scope of sprint, understand the product
backlog, task estimates and assignments
Daily 15 minutes
meeting will be held where participants answer three questions.
o
Last 24 hours tasks
o
Plan for next 24 hours
tasks
o
What are all obstructions
of the tasks?
Sprint Burn down
Charts
Each day, Scrum Master records the estimated
remaining
work for the sprint. This is nothing but the Burn Down Chart.
It is
updated daily.
Process flow of scrum
Process flow of scrum testing is as follows:
Each iteration of a
scrum is known as Sprint
Product backlog is a
list where all details are entered to get end product
During each Sprint,
top items of Product backlog are selected and turned into Sprint backlog
Team works on the
defined sprint backlog
Team checks for the
daily work
At the end of sprint,
team delivers product functionality
AGILE DEVELOPMENT MODEL
- Agile methods break tasks into smaller iterations, or parts do not directly involve long term planning. The project scope and requirements are laid down at the beginning of the development process.
- All the team member should work together to deliver a quality product.
- Management is also involved continuously in this project.
- It is one of the most widely used process in software development world as it helps teams to deliver the work faster in small increments with less issues.
General terminologies used in Agile process
- Product Backlog – User stories(requirements are split into user stories) will be added here. For any sprint, user stories will be picked from product backlog and worked upon.
- Epic – It is the complete feature or requirement which needs to be implemented.
- User story – An Epic is split into user stories based on the complexity or work involved in order to develop it. User story is generally part of Epic. In case of small feature, it will be a single user story.
- Story points – It is a measurement to define the complexity of the user story from dev and QA perspective. This activity will be done in Sprint planning.
- Burn down chart – This is a pictorial graph representation of time and work. This is drawn with the help of the time spent on tasks along with the work. Team need to burn the hours on daily basis for the work accomplished against the tasks.
Agile Process:
- Customer satisfaction by rapid, continuous delivery of useful software Here in Agile process, we can monitor the project progress every day.
- Every release is implemented in iterations or sprints. Every iteration or sprint consists of 2 or 3 weeks in general. However, this sprint duration varies from project to project and also to sprint to sprint as well sometimes.
- Many meetings were involved in this Agile process to know the progress of the release in each sprint.
Agile Meetings:
- Sprint Planning meeting is conducted before the start of the sprint to discuss the user stories that can be covered in that particular sprint.
- Daily stand up/Scrum is conducted to know the work done by each in the team. Mainly the below things are discussed,
- What work is done yesterday
- What work is planned for today
- What work is planned for tomorrow
- Any impediments to complete the work
Agile Meetings:
- Sprint Review meeting is conducted at the end of the sprint to discuss the progress and where does the team stand for that sprint. However this is a optional meeting which is conducted based on the projects/companies as required.
- Sprint Retrospective meeting is conducted once a sprint is completed and next sprint got started. Following things will be discussed,
- What went well in the last sprint
- What didn’t went well in the last sprint
- What can be done to improve or perform well in the ongoing sprint
- Defect Triage meeting is conducted to review and have a proper action on the defects. Dev team, testing team and sometimes the Product owner also will be involved in this meeting. Defects identified in the particular sprint will be triaged and assigned to respective team or deferred sometimes depending on the defects.
- Sprint Planning meeting is conducted before the start of the sprint where the user stories for that particular sprint and the timelines for the same would be planned.
can you explain to me the Definition of Ready in agile scrum?
Definition of Ready (DoR) is a set of criteria agreed upon by the Scrum team, used to define when a product backlog item is considered ready to be worked on. The Definition of Ready ensures that the team is fully prepared to start working on a product backlog item and that all necessary information and dependencies have been addressed. This helps to reduce the risk of delays or rework and ensures that the team can focus on delivering value. The DoR typically includes information such as clear and well-defined user stories, sufficient requirements, and necessary resources and dependencies being in place
can you explain to me the Definition of done in agile scrum?
The Definition of Done (DoD) is a set of criteria agreed upon by the Scrum team, used to define when a product backlog item is considered complete and ready to be accepted by the product owner. The Definition of Done provides a shared understanding of what constitutes a high-quality product increment and helps ensure that everyone on the team is aligned on what needs to be delivered. It typically includes a list of technical and non-technical requirements that must be met before a product backlog item can be considered done.
can you explain to me the Acceptance criteria in agile scrum?
Acceptance Criteria are a set of specific, testable conditions that a product backlog item must meet in order to be considered complete and accepted by the product owner. The acceptance criteria help to define what success looks like for each product backlog item and provide clear and measurable definitions for the team to work towards. This helps ensure that the team is aligned on what needs to be delivered and provides a way for the product owner to confirm that the product backlog item meets their expectations. Acceptance criteria can include functional requirements, performance criteria, usability standards, and other conditions that must be met before the product backlog item is considered done
Advantages:
- Customer satisfaction by rapid, continuous delivery of useful software.
- Working software is delivered frequently (weeks rather than months).
- Weekly release are expected if any large requirement are split so that development and testing is completed in the week scheduled.
- Customers, developers and testers constantly interact with each other.
- Daily cooperation between business people and developers.
Disadvantages:
- Sometimes in Agile methodology the requirement is not very clear hence it’s difficult to predict the expected result.
- In few of the projects at the starting of the software development life cycle it’s difficult to estimate the actual effort required.
- Because of the ever-evolving features, there is always a risk of the ever-lasting project.
- For complex projects, the resource requirement and effort are difficult to estimate.
Agile velocity
·
Velocity is a metric that predicts how much work an Agile software development team can
successfully complete within a two-week sprint (or similar time-boxed period).
Velocity is a useful planning tool for estimating how fast work
can be completed and how long it will take to complete a project. The metric is
calculated by reviewing work the team successfully completed during previous
sprints; for example, if the team completed 10stories during a two-week sprint and each
story was worth 3 story points, then the team's velocity is 30
story points per sprint.
Generally, velocity remains somewhat constant during a development
project, which makes it a useful metric for estimating how long it will take a
team to complete a software development project. If the product backlog has 300
story points, and the team is averaging 30 story points per sprint, it can be
estimated that team members will require 10 more sprints to complete work. If
each sprint lasts two weeks, then the project will last 20 more weeks. If a
team member is moved to another project, however, or new members are added --
the velocity must be recalculated.
v=🔺x/🔺t= Number of total story points / One
iteration
Velocity is a measurement of how much the team gets done in an
iteration ( called as Sprint in Scrum ). Velocity is what actually got done in
the last iteration not what is planned.
In Scrum it is measure in Story points. Each feature in scrum is
a story. A story has points. Points can be anything you come up with.
Examples are 1, 2, 4, 8 , 16
5, 10 15 and so on.
A story depending on its complexity is given certain story
points. So if the team does 6 stories that are 8 story points that iteration ,
the teams velocity is 48 story points.
What is a story point ?
Story point is a arbitrary measure used by Scrum teams. This is
used to measure the effort required to implement a story.
How to give story points / How to estimate user story?
Story points are a method used in Agile Scrum to estimate the relative size and complexity of product backlog items, such as user stories. The following is a general approach for estimating user stories with story points:
Understand the user story: Make sure everyone on the team has a clear understanding of what the user story entails and what needs to be delivered.
Use relative sizing: Instead of trying to estimate the exact effort required to complete a user story, use relative sizing to compare it to other user stories that have already been estimated.
Use a standardized scale: Teams typically use a Fibonacci-based scale (e.g. 1, 2, 3, 5, 8, 13, 21) to estimate user stories, as this reflects the uncertainty that often surrounds software development estimates.
Involve the team: Encourage collaboration and teamwork by involving the entire team in the estimation process. This helps ensure that everyone is aligned and that the estimate is based on a shared understanding of the user story.
Re-estimate regularly: User stories are likely to change as the project progresses, so be prepared to re-estimate them as needed to reflect these changes.
Remember, the goal of story point estimation is not to produce an exact estimate, but rather to provide a rough idea of the relative size and complexity of the user story, and to help the team plan and prioritize their work
What are different way to size stories?
Why do we do story points, not hours?
ike Cohn talks a lot about this in his book Agile
Estimation and Planning. You can use any measure to size stories.
Teams use different sizing techniques
T Shirt Sizing
X Small, Small , Medium , Large , Xtra Large
or
Coffee Sizing
Small, Tall, Grande
You can pick any sizing technique. Make up one if needed.
This is mainly done as we as humans and as managers are better
at abstract terms. If we use hours as a way to size stories,then the managers
in the room have questions, teams dont immediately feel comfortable with hours.
Sizing keeps the planning meeting at a fast pace.
A general measure you can use for T Shirt sizing is how
many days it take to complete a story
Small story – 1-3 days
Medium – 3- 5 days
Large – 5 – 7 days
X Large > 10 days
In order to convert a story size to a number you can use either
factorial, Fibonacci or Squares.
Sizing Techniques
If in a sprint your team does two small stories and two
medium then your velocity is 9 * 2 + 4 * 2 = 26 ( if you are following
the squares techique). Square is simple and works quite well.
