Final SDLC Material With Agile

SOFTWARE DEVELOPMENT

LIFE CYCLE with AGILE TESTING

By

B V Ramana – Test Lead, CSTE and ISTQB Certified,

Scrum certified Professional,

Trained around 5000 professionals on Agile,

Director of Quality Though Technologies,

For Contact: [email protected]

mailto:[email protected]

TABLE OF CONTENTS

Software Development Models ………………………………..………..1

Importance of SDLC…………………………………………..………...2

Waterfall Model………………………………………………..………..5

V Model……………………………………………………….………...7

Iteration Model………………………………….…..…………….…….11

Agile Methodology……………………………….….…………….…...12

Scrum Framework……………………………………..…………….….13

Extreme Programming…………………………………..………………18

Interview Questions……………………………………….…………….21

QUALITY THOUGHT * [email protected] * Email: [email protected]

Phone: 9963486280, 040-40025423 www.QualityThoughtTechnologies.com

http://www.QualityThoughtTechnologies.com/



Software Development Models:

The Software Development life cycle (SDLC) model is: 1. An approach to have a sequence of steps to system or Software product2. To execute the process from start to finsih without revisiting any previous step

Why we need SDLC:

To Execute projects with proven frame work To define and focus roles and responsibilities To enforce planning and control To have consistency among deliverables To Increase productivity by executing the project in systematic manner To reduce the rework effort during project

SDLC Activities or Phases:

Project Initiation Phase:

This is 1st Phase in the project life cycle, as it involves starting up a new project.

A project is started by defining its:

Objectives Scope Purpose Deliverables

Also in this phase we hire the project team, setup the project office and review the project, to gain approval to begin the next phase. The Purpose of the Initiation phase is to start the project.

Concepts Development Phase:The Concept Development Phase may begin after the approval of the completion of the

initiation project status review and the approval to proceed to the Concept Development Phase.The focus of the phase is two-fold:

1. Evaluate feasibility of alternative and2. Clearly define and approve project scope, including the system, all deliverables and all

required activities. Planning:

Project Planning – Determines the project’s goals and results in a high-level view of the potential project. Proper Comprehensive project planning is essential to a successful IT project, and incomplete project planning and analysis are frequently root causes o project failure.






The purpose o the planning phase is to plan all project processes and activities required to ensure project success and to create a comprehensive set of plans, known as the project Management Plan (PMP), to manage the project from this phase until project termination.

Requirement Analysis:The Requirement Analysis Phase begins when the previous phase objectives have been

achieved. Documentation related to user requirements from the Concept Development Phase and the planning phase shall be used as the basis for further user needs analysis and the development of detailed requirements.

The Purpose of the Requirements Analysis Phase is to transform the needs and high level requirements specified in earlier phases into unambiguous (measurable and lestable), traceable, complete, consistent and stakeholder – approved requirements.

Design: During the Design Phase the system is designed ti satisfy the requirements identified in the

previous phases. The Requirements Identified in the Requirements Analysis Phase are transformation into a system design document that accurately describes the design of the system and that can be used as an input to system development in the next phase.The purpose of the design phase is to transform the requirements into complete and detailed system design specifications. Once the design is approved, the Development Team begins the Development Phase.

Development:

The Development phase features a key step in the project System construction. The previous phases lay the foundation for system development the following phases ensure that the product functions as required. To complete the development phase successfully, two elements are required.

1. A complete set of design specifications2. Proper processes standards and tools.

The purpose of the development phase is to convert the system design prototyped in the design phase into a working information system that addresses all documented system requirements. At the end of this phase, the working system will enter the test phase.

Testing:The test phase focuses on an empirical investigation in which the results describe the quality

of the system testing cannot confirm a system functions property under all conditions but can establish that it fails under specific conditions.In the test phase, testing of the system proves that the system meets all requirements, including those for performance and security.






The purpose of the test phase is to guarantee that the system successfully built and tested in the development phase meets all requirements and design parameters. After being tested and accepted the system moves to the implementation phase.

Implementation:The Implementation Phase has one key activity:Developing the new system in its target environment. Supporting actions include training end

users and preparing to turn the system over to maintenance personnel. The purpose of the implementation phase is to deploy and enable operations of the new information system in the production environment.

Operation and maintenance During the operations and maintenance phase, the information system’s availability and Performance in executing the work for which it was designed is maintained. System operations continue until the system’s termination date, when the next phase, disposition, begins. The purpose of the operations and maintenance phase is to ensure the information system is fully functional and performs optimally until the system reaches its end of life.

Waterfall methodology:

Before we actually dig into the beauty of agile, lets udnerstand what is water fall in reality:

Water fall never says we should not go back to second phase, once we are done with it and we are in 3rd phase. If that is so, there is no bugfix in water fall, because development comes before testing and you can not develop if you get a bug.

What is waterfall then?

Water fall says that, one can not visit the 2nd phase unless he / she is actually on second phase. Say, a tester can not start testing unless the project is moved from dev phase to testing phase. Basically one can not feel anything early.

History:

Winston Royce said in 1970 that: sneak peak testing

This means, a tester should feel the testing in a project even before we start with testing phase.






Waterfall Model main features are:

Whole process of software development is devided into separate phases Derives from its name, giving cascading effect from one phase to another phase Each ohase has well defined starting and ending point with identifiable deliveries to the next

phase. Most commonly used model

Block Diagram:

Waterfall Model Disadvantages:

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. Works well for smaller projects where requirements are very well understood.

Poor model where requirements are at a moderate to high risk of changing.

Rework would be more.






Waterfall vs. Agile:

Waterfall Agile

Heavy documentation Effective documentation

Dedicated teams Multi functional teams

Defined contracts of work Flexible scope of work

Manged by separate teams Self manageble

Every phase might not contain a delivery All phases are going to have live product as end result.

V Mode1:

The V-Model for Testing provides a structured development framework, emphasizing building quality in from the initial requirements stage through the final testing stage.

V-Model Desription:






• Development effort begins on the left-hand side of the V-Model with analysis and design activities

• Project is specified top down, making decisions and adding more detail at each new specification stage

• During each analysis or design stage on the left, a test plan is developed, which documents the test cases and expected results required to test the implementation of the specification in the corresponding testing activity on the right side

• When the design is complete, the build process begins• Once development is complete, the application moves through the testing activities on the

right hand side of the V• Testing done on the right side of then V-Model tests that the related specification on the left

side is properly implemented • During the earlier stages of testing, the focus is on individual components• As testing progresses, the focus in on functionality and achievement of the business case

The V Model demonstrates the relationships between each phase of development life cycle and its associated phase of testing .The V Model Illustrates how testing activities can be integrated into each phase of the software development Life cycle.



Test Phase OverviewTest Phase Overview

Testing Methodology

ProductionFunctionality

ParallelTest

Business/UserRequirements

User AcceptanceTest

Code

Assembly Test

Unit Test

Application Architecture

ProgramSpecifications

Integrated System Test

System Test

InterfaceSpecifications

ApplicationSpecifications

Project Charter/Business Case

BusinessRealization Test

Process Flow

Test PlanningTest Execution

KEY

Review






Test Process Flow OverviewTest Process Flow Overview

Test ApproachOutline Test Scope and ObjectivesConfirm Test Risks Update Regression Test ApproachDetermine updated Test Environment RequirementsConfirm MetricsUpdate Entry / Exit CriteriaCreate Test Work Plans and Test Resource Staffing

Test ApproachOutline Test Scope and ObjectivesConfirm Test Risks Update Regression Test ApproachDetermine updated Test Environment RequirementsConfirm MetricsUpdate Entry / Exit CriteriaCreate Test Work Plans and Test Resource Staffing

Execute TestDetermine Actual Test ResultsLog DefectsManage Defects

Execute TestDetermine Actual Test ResultsLog DefectsManage Defects

Prepare TestDevelop detailed Test ScriptsDefine and Create Test Data Define detailed Expected Results

Prepare TestDevelop detailed Test ScriptsDefine and Create Test Data Define detailed Expected Results

Test PlanIdentify new / updated Test Cases and Expected Results (high level)Update Test Case InventoryUpdate Test Script InventoryConfirm mapping of Test cases to RequirementsConfirm mapping of Test Cases to Test Scripts and Components.

Test PlanIdentify new / updated Test Cases and Expected Results (high level)Update Test Case InventoryUpdate Test Script InventoryConfirm mapping of Test cases to RequirementsConfirm mapping of Test Cases to Test Scripts and Components.

Establish Test EnvironmentEstablish Test Environment

Develop Test Approach

Develop Test Approach Plan TestPlan Test Prepare TestPrepare Test Execute TestExecute Test

Manage TestManage Test

During each phase of testing, a structured, repeatable test process is applied and a standard set of deliverables are created.

Develop Test Approach provides the objectives, schedule, environment requirements, and entry and exit criteria for the test stagePlan Test identifies test cases for the test stagePrepare Test defines test scripts, input data, and expected resultsEstablish Test Environment ensures that the environment is established and tested before test executionExecute Test performs the scripts contained in the test model, compares the actual results to expected results, and identifies and resolves discrepancies.

Testing Methodology






Test Phase Definitions Test Phase Definitions

Stage Overview Step in Delivery Lifecycle

The focus of testing is different across each test phase.

Test Executio

n Responsi

bility

Testing Methodology

Test Planning Responsi

bilityValidates that the development tasks (individual programs, modules, or components) appropriatelyimplement the functional/technical specifications.

Development Team Unit Test

Designers

Development Team

Tests the interaction of related programs to ensure proper function when integrated, as well as testing the program interfaces to validate that the design has been implemented appropriately.

Assembly Test Designers

Focus on validating that the application meets application requirements, workflow and performance targets. System test includes internal system testing, external system testing, and technical testing (performance, volume, stress) at the application level to validate the application meets performance requirements. May include conversion testing.

System Testing TeamSystem Test Designers

Validates application interfaces between adjacent systems are functioning correctly. Integration Test ensures business functions are supported across systems. Also includes technical testing (performance, volume, stress) at the application suite level to validate the application suite meets performance requirements. May include conversion testing

Integration System Testing TeamIntegrated System Test Designers

Allows users to review the system in a near-production context in order to validate business requirements and to prove correct operation in a business environment.

User Acceptance TestTeams/Business Unit(s)User Acceptance Test

Business Analysts and Users

Ensures new application functions properly compared to current production functionality.

Parallel TestParallel Test Team/

Business Unit(s)Business Analysts

and Users

Validates that the application can be deployed properly as required for a new application release. Includes installation and data conversion

Conversion Test Development TeamDevelopment Team




Iterative Development Model

Multiple cycles take place here, Cycles are divided up into smaller, more easily managed iterations. Each iteration passes through the requirements, design, implementation and testing phases.

Easier to test and debug during a smaller iteration.

More flexible – less costly to change scope and requirements.

A working version of software is produced during the first iteration, so you have working software early on during the software life cycle.

Iterative or Incremental Development Processes



Prototyping,

Rapid Application Development (RAD),

Rational Unified Process (RUP)

Agile development




Why Agile process is Important:

Agile is a software development process. In today’s rapid world, Project stake holders want immediate return on their investment. They don’t want to wait longer to get the full features product. As a result, now a day’s new software development and testing frameworks are catching momentum Agile approach.

In Agile projects are divided in top small features that are in turn developed and tested in specific time – frames called as sprint (small cycles).The main idea being – features should be developed and tested in specified small time-frames.

Introduction of Agile process:

Agile methods break tasks into small increments with minimal planning, and do not directly involve long-term planning.

Iterations are short time frames ("time boxes") that typically last from one to four weeks.

Each iteration involves a team working through a full software development cycle including planning, requirements analysis, design, coding, unit testing, and acceptance testing when a working product is demonstrated to stakeholders.

Team composition in an agile project is usually cross-functional and self-organizing.

Team members normally take responsibility for tasks that deliver the functionality an iteration requires.

They decide individually how to meet an iteration's requirements..

Most agile implementations use a routine and formal daily face-to-face communication among team members.

Principles of agile methods:

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 business people and developers






Face-to-face conversation is the best form of communication (co-location)

Projects are built around motivated individuals, who should be trusted

Continuous attention to technical excellence and good design

Simplicity

Self-organizing teams

Practical Implementations of Agile Methods:

Agile Modeling Agile unified Process Essential Unified Process (EssUP) Extreme Programming(XP) Feature Driven Development (FDD) Open Unified Process Scrum Linear development

Scrum Characteristics:

Scrum is a “process skeleton” which contains sets of practices and predefined roles. Scrum is an iterative, incremental framework for projects and product or application development. Scrum has become more and more popular software development and testing framework among organizations in the recent past. Many small to large sized it organizations have started to embrace scrum framework, as this can create excellent quality products in shorter and more quantifiable timeframes than any other traditional software development methodologies. This framework can save companies both time and money.

The main roles in Scrum are:

The name scrum is inspired from rugby game where team work is main key for the success.

An agile project management framework and development process where a team of 5 to 10 people produce increments of products every 14 to 30 days iteration based upon the priority of work set by the customer.

Products is designed and built iteratively and incrementally using the product development life cycle in 2 to 4 weeks duration.

At the end of iterations, product is delivered based upon the business value of the features as prioritized by the customers.

Customer reviews the product and provides feedback to the team.

The “Product Owner”, who represents the stakeholders and the business






Product owner is the one who decides on priorities of the requirements Product owner is not the person who allocates tasks to team members Product owner may / may not be client-but maintains characteristics Prodcut owner will not give technical suggetions to team members but decides on busuiness

The “Scrum Master”, who maintains the processes (typically in lieu of a project manager)

Scrum master is the one who acts as bridge between business and team, means acts as bridge between product owner and team (dev, test etc…)

Scrum master should be in a position to help any team member to accomplish their tasks by removing impediments in their way.

Scrum master should help everyone in the team, from the beginning to the release of every scrum.

Scrum master should not allocate tasks but helps in understanding business priorities. Scrum master coordinates with QA and UAT team in getting signoffs for the releases. Organizes the scrum calls / stand-up calls.

The “Team”, a cross-functional group of about 7 people who do the actual analysis, design, implementation, testing, etc.

Here, the cross-functional means, there is no separate tag like tester/developer or business user , rather every one is part of every group.

The above statement clarifies that, every one should be having exposure into multiple domains and technology.

Team members in agile are self organized and self manageble.

The “Management” folks are someone who is not responsible for any deliveries or someone who is not part of the group but someone who is interested in the project.

In Agile team, management doesnot invlove in the allocation of the tasks or priority defination of any activities.

Management is not allowed to speak in scrum calls.

Stand-up Calls

Agile beleives that, people can speak hours to gether in meetings but the output is valuable of 15mins worth a day, hence all meetings in agile methodology are stand up meetings, where people should stand and speak, hence they won’t speak more than 15mins-which is actually required for the project.

Note: Stand up call generally happens every day at the morning.

Generally, in a call below things are discussed:






What did you do yesterday? What are you going to do today? Are there any obstacles in your way? Strictly, no resolutions in the meetings – resolutions offline.

Terminologies used in Agile

Stories

Iterations

Complexity points

Iteration Velocity

Product Backlog / Iteration Backlog

Scrum / Daily Stand Up Meeting

Iteration Planning Meeting (IPM)

Iteration Review Meeting

Showcase and Retrospective Meeting

Burn Up and Burn-Down Chart

The Scrum Framework






SCRUM PROCESS:

Stpe1: In Agile methodology all requirements are divided into stories. Step 2: Agile methodology Works in Iterations. Iteration means time line fixed to deliver the

Stories without defects. In general Iteration durations are 1 week, 2 weeks or 1month Step 3: Business Analysts will send stories to the team in the starting day of iteration. Step 4: When Iteration starts Developers start working on coding at the same time Testers

work on designing of test cases. When the Stories are ready for testing Testers will execute all the test cases.

Step 5: Scrum Master Coordinates the Agile project and in Scrum meetings with all teams (BA’s, Modelers, Developers, Testing team) discuss about the status on the story

Step 5: By the end of iteration all the stories testing should be completed without any defects Step 6: Product Owners i.e. Customers will test the product. Success criteria for Iteration: 1.No critical defects by end of the Iteration, No high defects by

end of the iteration

What testers can expect:






New features are added to the software in each of the Iteration.

Test Teams should expect to run one or more complete test cycle in each iteration of the project, including regression testing previously delivered features as well as the current feature.

Testers, Business Analysts, and Developers will work together as an integrated team to define, build, and test software. Testing spans the iteration (time) and spans across the team (roles).

Requirements and code continue to change during test cycles.

Environments and test data must be ready earlier and more closely managed.

How testers will benefit from an agile approach

More features are fully completed earlier in the project, removing the need for a long, high-pressure testing cycle right before the product moves to production.

Business Analysts and Testers have more opportunity to provide and receive feedback on the software earlier in the project, leading to fewer major changes late in the effort.

More Developer testing reduces the number of "common" defects that the testers need to worry about and reduces the amount of time spent managing large amounts of defects.

The defect report/fix cycle is dramatically shortened.

An Agile approach can more easily accept changes in customer requests.

Challenges for testers:

Tests must be able to run quickly and repeatedly. Iterations last 2-6 weeks. Each iteration should include one to many full testing cycles. This is a huge challenge for efforts that rely on mostly manual testing.

Test case creation should begin concurrently with the elaboration of the feature.

Test execution must start as soon as features are ready, requiring environments and data to be set up during the first iteration.

Performance Testing may need to occur earlier than traditional waterfall efforts.

Requirements and code are changed during test cycles, requiring more flexible test schedules, and more regression testing.

Integrating with non-agile projects, can present a timing challenge, as other projects might not have their side of integration points built early enough to do extensive testing.

Managing test data and environments on shorter time frames.

Checkpoints

Agile Development is a part of which software Development model?






What is Velocity?

A user story is developed by a?

Burn Down Chart

The purpose of the burn down chart is to have a visual representation of the amount of work left to complete in the current iteration.

It gives a simple view of the sprint progress. Ideally should burn down to zero to the end of the Sprint The outstanding work (or backlog) is often on the vertical axis, with time along the

horizontal

Burn Down Chart

Burn up Chart

The problem is that burn down charts lack two essential pieces of information. First, how much work was actually accomplished during a given iteration (as opposed to how

much work remains to be completed) Second how much total work the project contains (or if you prefer how much scope has

increased each iteration).

Burn up Chart






Extreme Programming (XP)

One of the most well-known agile development life cycle models. The methodology claims to be more human friendly than traditional development methods. Some characteristics of XP are:

It promotes the generation of business stories to define the functionality.

It demands an on-site customer for continual feedback and to define and carry out functional acceptance testing.

It promotes pair programming and shared code ownership amongst the developers.

It states that component test scripts shall be written before the code is written and that those tests should be automated.

It states that integration and testing of the code shall happen several times a day.

It states that we always implement the simplest solution to meet today's problems.

Differences b/w XP & Scrum

Scrum teams typically work in iterations (called sprints) that are from two weeks to one month long while XP one or two weeks long.

Scrum teams do not allow changes into their sprints. XP teams are much more amenable to change within their iterations.

Extreme Programming teams work in a strict priority order. Features to be developed are prioritized by the customer and the team is required to work on them in that order. By contrast, the Scrum product owner prioritizes the product backlog but the team determines the sequence in which they will develop the backlog items.

Problems with agile methods

Agile says avoid documentation, and it is difficult to have a project which is document free.






It can be difficult to keep the interest of Customers who are involved in the process. Team members may be unsuited to the intense involvement that characterizes agile methods. Prioritizing changes can be difficult where there are multiple stakeholders. Maintaining simplicity requires extra work. Requirement will not be freeze, which causes more rework.

How to overcome the challenges

Agile allows documentation but one should try to avoid it, meas – one should not have lengthy documentation for any requirements.

Follow better documentation approaches such as-specification by example, which says there is no separate document for requirements and separate for testing / uat. Rather have one document which can be used by all.

Requirements should be priorotized always in a way that, one should get output always for every release as a live product.

Say, there is a coffee vending machine project, one should not prepare a draft plan and say that this is the output of my first sprint as iam in planning phase.

But, the expectation from agile is, one should come up with a coffee vending machine itself, may be out of 10, only 2 options are in working condition which gives some use to client.

Best Practices / Lesson Learnt

Iteration Tracker Stand Up meetings Defect Query Log Retrospective Defect Removal Efficiency Sheet(DRE) Withdrawn Defects Analysis Report Maintain proper backup plan for every resource in the team Automate what ever and where ever Continous integration – there are tools available in market Script less automation – for the use of business users Specification by example – best documentation approach

Differences you felt in V-model and Agile Model?

V-Model Agile Model






1.Verification and validation Quick moving process

2.Requirements are freezed Requirements change dynamically so they are not freezed.

3. It’s very rigid and least flexible any changes happen mid way, not only the requirements documents but also the test documentation needs to be updated.

Business requirements are designed in the form of iterations, which makes the requirements update process to be flexible.

4.The execution of operation ,maintenance repair and disposal of the system are not covered by the v-Model

Ex3ecution, Repair and Maintenance are covered in Agile model.

5. Involve more documentation. Document involves details of operations performed in before stage.

Less documentation because there is frequent communication between team members of different stage

When to go for Agile methodology?

When the requirements change dynamically. Continues monitoring of project by client.

When not to go for agile methodology?

When there are dependencies. When there is communication barrier between team members or client this makes no quick

response from them. For projects where requirements doesn’t change dynamically.

Highlights:

Several surveys say, agile methodology will be used in 90+% of the projects by all software industries.

The purest form of agile will yeild the better results, means:o Agile + best practices + Scrum -> Scragile






o Agile - best practices + Scrum -> Fragile

Interview Questions

Expected Questions:

1. What is SDLC? Can you explain me in detail? Why do we need SDLC?

2. Define various SDLC phases?

3. Describe below models with life cycle, Advantageous, disadvantageous?

Waterfall Model

V Model

Prototype Model

Iterative Model

Spiral Model

RAD Model

4. Can you explain waterfall model in Manual Testing?

5. Can you explain V Model in Manual Testing with your real Time experience?

6. Explain the difference between Waterfall and V Model?

7. Explain differences between V Model and Agile Methodology?

8. Explain the SCRUM Framework process in your Project?

9. Explain Verification Validation Model with each level of Testing?

10. What are the different agile methodologies Implementations? Explain the difference between agile methodology and Scrum Frame work?

11. For which type of projects SCRUM Framework is suitable?

12. What are the agile methodologies Principles?

13. How testers will benefit from an agile approach?

14. What are the challenges for testers in agile methodology?

15. For which type of Projects Agile Methodology is not suitable?






16. How you decide Iteration Backlog in your Project?

17. What is Iteration Planning Meeting, Retrospective Document in Agile Methodology?

18. List few differences between Agile, V model in terms of

a. Documents preparation

b. Testing Life Cycle

19. How you are able to complete all the activities in Testing in short life cycle?

20. What are the roles and responsibilities of SCRUM Master?

.




