SDLC Models

  i.        Waterfall Model

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.

V-Shaped SDLC Model:

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

  iii.        Prototyping Model

 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:

1. 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.
2. 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.

  iv. Iterative life cycles:

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

       v.   Spiral SDLC Model:

-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)

  vi.        Rapid Application Development

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

·         

Part of the Agile, Scrum, XP glossary:

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:

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.