BTCS711-18 Abhishek,2202498

Task 1: Understand the background and driving forces for taking an Agile
Approach to Software Development.
Theory: The Agile software development approach has become the standard for modern software
development, providing organizations with the flexibility and responsiveness they need to meet the
changing demands of the software development landscape . Agile is a time-bound , iterative approach
to software delivery that builds software incrementally from the start of the project, instead of trying to
deliver all at once
Principles:
1. Highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2. It welcomes changing requirements, even late in development.
3. Deliver working software frequently, from a couple of weeks to a couple of months ,with a
preference to the shortest timescale.
4. Build projects around motivated individuals. Give them the environment and the support they need,
and trust them to get the job done.
5. Working software is the primary measure of progress.
6. Simplicity the art of maximizing the amount of work not done is essential.
7. The most efficient and effective method of conveying information to and within a development team
is face-to-face conversation
AGILE SDLC PROCESS FLOW:
1. Concept: Projects are imagined and prioritized.
2. Inception: Team members are created, funding is put in place, and basic environments and
requirements are discussed.
3. Iteration/Constriction: The software development team works to deliver working software. It is
based on requirement and feedback.
4. Release: Perform quality assurance (QA) testing, provides internal and external training ,
documentation development, and final version of iteration into the product.
5. Production: It is ongoing support of the software

The following provides a practical understanding of the background and driving forces behind the
adoption of the Agile approach:

Page|1
BTCS711-18 Abhishek,2202498

1. Customer satisfaction: Agile development places a strong emphasis on continuous feedback from
customers and stakeholders, enabling teams to quickly respond to changing requirements and deliver
value. This approach leads to higher customer satisfaction because the customer is involved in the
development process and can see the product evolving and responding to their needs.
2. Flexibility: Agile development allows teams to adapt to change and respond quickly to shifting
priorities and new information, making it ideal for complex and rapidly changing environments. The
Agile approach is designed to be flexible, with a focus on delivering value incrementally and
iteratively, making it easier for teams to adapt to changing requirements.
3. Collaboration: Agile development encourages collaboration between cross-functional teams,
including developers, product owners, and stakeholders, leading to better decision-making and faster
delivery. Teams work together to define and prioritize requirements, and regular meetings, such as
daily stand-ups, help keep everyone on the same page.
4. Quality: Agile development prioritizes regular testing and inspection, enabling teams to catch and
fix defects early in the development process, leading to higher-quality software. By regularly testing
and inspecting code, teams can catch and fix defects early, reducing the risk of more serious and
expensive problems down the line.
5. Predictable delivery: Agile development uses iterative development cycles and frequenter leases,
allowing teams to make steady progress and deliver value to customers faster. The Agile approach
provides a more predictable delivery schedule, with regular releases and a focus on delivering value
incrementally, enabling teams to meet customer needs and expectations.
6. Increased productivity: The Agile approach focuses on delivering value incrementally and
iteratively, enabling teams to work more efficiently and effectively. Teams are empowered to make
decisions and take ownership of their work, leading to increased motivation and productivity.
Advantages:
● Deployment of software is quicker and thus helps in increasing the trust of the customer.

● Can better adapt to rapidly changing requirements and respond faster.

● Helps in getting immediate feedback which can be used to improve the software in the next increment.

● People – Not Process. People and interactions are given a higher priority rather than process and tools.

● Continuous attention to technical excellence and good design.

Disadvantages:
● In case of large software projects, it is difficult to assess the effort required at the initial stages of the
software development life cycle.
● Agile Development is more code focused and produces less documentation.

● Agile development is heavily dependent on the inputs of the customer. If the customer has ambiguity
in his vision of the final outcome, it is highly likely for the project to get off track.
● Face to Face communication is harder in large-scale organizations.

● Only senior programmers are capable of taking the kind of decisions required during the development
process. Hence it’s a difficult situation for new programmers to adapt to the environment.

Page|2
BTCS711-18 Abhishek,2202498

Task 2: Build out a backlog and user stories.

Product Backlog

The product backlog is the list of all the work that needs to get done. It usually contains user
stories, bugs, technical tasks, and knowledge acquisition. The backlog is periodically refined by
the product owner and scrum team to ensure 2–3 sprints worth of work is always defined and
prioritized.
A solid backlog should be DEEP:

● Detailed: Sufficiently detailed such that any member of the scrum team can work on the
user stories independently
● Emergent: Flexible, work will fluctuate based on the needs of the team, business, or
customer
● Estimated: Size and complexity is estimated using story points — If a story comes with a high
estimate, it is likely large enough to break apart into more than one user story
● Prioritized: User stories are ordered in the backlog based on product priority — If all
stories in the sprint are completed early the team should pull in the next user story on
the backlog

Backlog refinement sessions are led by product managers. You will always want your user
stories to meet the INVEST criteria. Some simple tips to make that refinement meeting run
smoothly:

● Invite the whole team! That includes UX, testers, etc

● Have your user stories written and distributed to the team so they can review before the
refinement session
● Prioritize the user stories
● Limit conversation per user story using a timer — if it takes longer than the allotted
o time you probably need to go back and define the user story better
● Estimate a reference story so that you can estimate the rest of your stories relative tothe
reference
● Spend enough time on refinement — if you’re just starting out you may need to spenda
couple of full days to refine the backlog

User Stories

User stories are simple, powerful constructs that describe functionality from the point of
viewof your user. Simple enough! They usually look something like this:
● As a <role or personal>, I can <goal or need>, so that <why>
● As a <user class>, I want to <perform or do something>, so that <I get some value
orbenefit>

User stories need to meet specific criteria to be considered “ready” by the scrum team. The
most popular is INVEST:

● Independent: The lowest level of functional decomposition — they should stand on their own
and allow for the business to change direction with minimal cost and impact to emerging
requirements

Page|3
BTCS711-18 Abhishek,2202498
● Negotiable: High level enough that implementation is flexible — there should be
enough room to inspect and adapt the implementation based on constraints and business

Page|4
BTCS711-18 Abhishek,2202498

requirements

● Valuable: Demonstrated value to the business and the user — each user story represents
an increment of product that can be demonstrated to a potential customer of thesystem

● Estimable: Sufficient knowledge about how the user story will be developed (and
tested) that the scrum team can provide a high-level estimate for how long the user story
will take to implement

● Sized to Fit: Such that the work to deliver the user story can be completed in a sprint to
facilitate faster time to market and feedback from customers

● Testable: Using well-defined acceptance criteria prior to any implementation work —

what will it take to satisfy our customer’s need and how will we verify that those needs
have been met

Let’s expand on testable criteria. Every great user story has even better acceptance criteria!
Acceptance criteria is focused on the intended outcome as a result of the action specified in
theuser story. It should always focus on “what” instead of “how”. Here is a simple format
to follow when writing your acceptance criteria:

● Given <some pre-condition(s)>, when <some action(s)>, then <expectedresult/behavior>

● Pre-conditions are optional — they don’t always exist

Sample User Stories

Online Banking Application:

User Role User or Customer

Goal To be Refunded
Reason Money deducted but not received on the other end
Acceptance 1. The sender has valid transaction ID
Criterion 2. Users should be notified and be able to track refunds.

User Role User or Customer

Goal To register with application
Reason To be registered with an app and be able to access and use it.

Page|5
BTCS711-18 Abhishek,2202498

Acceptance 1. Users can only submit the forms once by filling

Criterion it completely.
2. Users will receive a notification email after
successful registration of the user.

User Role User or Customer

Goal To transfer funds/money
Reason One user is able to send money to another user.
Acceptance 1. Users should be registered with the application.
Criterion 2. His/her bank account should be linked with
the application.
3. The bank account should have enough money to
transfer the funds.

Page|6
BTCS711-18 Abhishek,2202498

Task 3: To study and use automated build tool.

Automated Build Tool is a software that compiles the source code to machine code.
Automation tools are used to automate the whole process of software build creation and
the other related processes like packaging binary code and running the automated tests.
HERE are some automated build tools:-

Jenkins

Price: Free

Fig.1 Jenkins

Jenkins is an open-source tool. It can perform the task of building, testing, and deploying
software. The platform is easy to install. For any project, Jenkins will work as a CI server
andas a continuous delivery hub. It has features of extensibility and easy configuration.

Features:
o Testing of isolated changes in a larger codebase.
o Automation of testing of builds.
o Work Distribution.
o Automation of software deployment.
Verdict: You will get good community support for Jenkins. It supports all major platforms. It
can test and deploy on multiple platforms at a fast rate. It can distribute the work across multiple
machines.
Best for small to large businesses.

Website: Jenkins

Maven

Price: Free

Page|7
BTCS711-18 Abhishek,2202498

Fig 2 Maven

Maven is an application that provides functionalities for project management. It has

functionalities for project building, reporting, and documentation. You will be able to access
the new features instantly. It is extensible through plugins. There will be no limitation on
building the number of projects into a JAR, WAR, etc.
Features:
o It supports working on multiple projects simultaneously.
o There will be consistent usage for all projects.
o It has features for dependency management.
o It provides a large and growing repository of libraries and metadata.
o It provides functionality for release management: It can distribute individual outputs.
o For managing the releases and distributing the publications, Maven will get integrated
with your system. No additional configuration will be required for this.
Verdict: As per the customer reviews, the tool is good for build automation and dependency
management. For dependency management, it provides support to the central repository of
JARs.
Best for small to large businesses

Website: Maven

Gradle
Price: Gradle offers a free trial of 30 days for Gradle Enterprise. You can contact
thecompany for the pricing of Enterprise subscriptions.

Fig 3 Gradle
Page|8
BTCS711-18 Abhishek,2202498

Gradle can be used for multiple project types i.e. mobile apps to microservices. It
hasfunctionalities for building, automating, and delivering software. It is an open-source platform.
For dependency management, it provides the functionalities like transitive dependencies, custom
dependency scopes, file-based dependencies, etc.

Features:
For software development, it will allow you to use any programming language.
It can deploy on any platform.
It supports monorepos as well as multi-repo strategy.
It will help you to deliver continuously.
It has various execution options like Continuous build, Composite Builds, TaskExclusion, Dry
Run, etc.
Verdict: As per the customer reviews it has good integration capabilities. Gradle has featuresof
web-based build visualization, collaborative debugging, parallel execution, incremental builds,
task time outs, etc.
Best for small to large businesses

Website: Gradle

Travis CI

Price: It is free to test open-source projects. It provides the first 100 builds for
free. There arefour pricing plans i.e. Bootstrap ($69 per month), Startup ($129 per month), Small
Business ($249 per month), and Premium ($489 per month).

Fig 4 Travis CI

GitHub projects can be synced with Travis CI. It can perform auto deployments on passing
the builds. It will be able to deploy on multiple cloud services. The tool can be used by
signing up and linking the repository. It will allow you to build the apps and test them.

Features:
● GitHub integration.
● It has pre-installed database services.
● It supports pull requests.
● It will provide a clean VM for every build.
Verdict: Travis CI is easy to install and configure. It has a clean interface. This tool will be
Page|9
BTCS711-18 Abhishek,2202498

the best option if you are creating an open-source project as it provides free services for open-source
projects.
Best for small to large businesses

Website: Travis CI

Bamboo

Price: The price of Bamboo will be based on the number of agents. An increase in the number of
agents will increase the number of processes that can run concurrently. It provides a free trial of
30 days. Bamboo offers two pricing plan
i.e. for small teams and growing teams.
The plan for small teams will cost you $10 (No remote agent) for a maximum of 10 jobs. Theplan
for growing teams will cost you $1100 (One remote agent) with unlimited jobs.

Fig 5 Bamboo

Bamboo is a continuous delivery tool that can be used from coding to deployment. It has
functionalities to build, test, and deploy projects. It can be integrated with Jira, Bitbucket, and
Fisheye. It has a clean user interface and is intuitive.

Features:
It will allow you to create multi-stage build plans.
You can assign agents to critical builds and deployments.
The tool can run parallel automated tests.
It can release in each environment.
While releasing, the flow can be controlled through pre-environment settings.
Verdict: With this tool, all tasks like automated builds, tests, and releases can be done in one
workflow. It has various built-in capabilities and doesn’t require plugins.
Best for small to large businesses.

Page|10
BTCS711-18 Abhishek,2202498

Task 4: To study version control tool.

Introduction

Version control — also known as source control or revision control — is an important software
development practice for tracking and managing changes made to code and otherfiles. It is closely
related to source code management.
With version control, every change made to the code is tracked. This allows developers tosee the
entire history of who changed what at any given time — and roll back to an earlierversion if they
need to. It also creates a single source of truth.
Version control (or source control or revision control) serves as a safety net to protect the source
code from irreparable harm, giving the development team the freedom to experiment without fear
of causing damage or creating code conflicts.
Version control enables teams to collaborate and streamline development to resolveconflicts and
create a centralized location for code

Use of version control tools

As organizations accelerate delivery of their software solutions through DevOps, controlling and
managing different versions of application artifacts — from code to configuration and from design
to deployment — becomes increasingly difficult.

Version control software facilitates coordination, sharing, and collaboration across the entire
software development team. It enables teams to work in distributed and asynchronous
environments, manage changes and versions of code and artifacts, and resolve merge conflicts and
related anomalies.

Version Control system

A version control system (VCS) tracks changes to a file or set of files over time. The most
common type is a centralized VCS, which uses a server to store all the versions of a file.
Developers can check out a file from the server, make changes, and check the file back in. The
server then stores the new version of the file.

Types of version control systems

The two most popular types are centralized and distributed. Centralized version controlsystems
store all the files in a central repository, while distributed version control systems store files across
multiple repositories. Other less common types include lock-based and optimistic.
Lock-Based: A lock-based version control system uses file locking to manage concurrent access
to files and resources. File locking prevents two or more users from making conflicting changes to
the same file or resource.

Optimistic: In an optimistic version control system, every user has their own private workspace.
When they want to share their changes with the rest of the team, they submit a request to the
server. The server then looks at all the changes and determines which ones can be safely merged
together.

Centralised: A centralized version control system (CVCS) is a type of VCS where all users are
working with the same central repository. This central repository can be located on a server or on
a developer's local machine. Centralized version control systems are typically used in software
development projects where a team of developers needs to share code and track changes.
Page|11
BTCS711-18 Abhishek,2202498

Distributed: A distributed version control system (DVCS) allows users to access a repositoryfrom
multiple locations. DVCSs are often used by developers who need to work on projects from
multiple computers or who need to collaborate with other developers remotely.

Benefits of version control

Quality: Teams can review, comment, and improve each other’s code and assets.
Acceleration: Branch code, make changes, and merge commits faster.
Visibility: Understand and spark team collaboration to foster greater release build and
release patterns.

Some main version control systems

The three most well-known version control tools are Git, Subversion, and Mercurial.
Git
Git is the most popular option and has become synonymous with "source code management."Git is an
open source distributed system that is used for software projects of any size, makingit a popular option for
startups, enterprise, and everything in between.

Subversion
SVN is a widely adopted centralized VCS. This system keeps all of a project's files on a single codeline
making it impossible to branch, so it's easy to scale for large projects. It's simple to learn and features
folder security measures, so access to subfolders can be restricted.

Mercurial
Mercurial is a distributed VCS that offers simple branching and merging capabilities. The system enables
rapid scaling and collaborative development, with an intuitive interface. Theflexible command line
interface enables users to begin using the system immediately.

Page|12
BTCS711-18 Abhishek,2202498

Task 5: To study Continuous Integration tool.

Introduction

Continuous integration (CI) is an agile and DevOps best practice that enables multiple developers
to contribute and collaborate in a shared code base at a rapid pace. Without continuous integration,
developer collaboration is a tedious manual process of coordinating code updates and merges.

Four pillars of Continuous Integration

Source Control Version Management: Probably the most important foundational pillar of
continuous integration is source control version management. It is used to communicate and
resolve editing conflicts between multiple developers working in the same codebase. Source
control version management comes in a variety of tools, the most popular being Git and
Subversion. CI-as-a-service products center around the version control system.

Automated testing: Most serious software projects include an additional code base that is not
explicitly responsible for the business product and features. This secondary code base is atest suite
and acts as a set of assertions that assures the primary code base is workingcorrectly without bugs.
During development, these tests are run by developers to validatethat new code has not caused any
regression on existing features. These test cases can also be run by extraneous tools to automate
this validation process. CI service products will automatically run the test cases for a project on
user-specified events. Generally, when a developer pushes code using the version control system
an event will trigger the full test suiteto run automatically.

Build Automation: “Builds” are the artifacts created to snapshot the current release version of a
software project. Builds are distributed to end users through various networks. There is generally a
set of scripted steps a project will take to create a build artifact. CI tools help streamline this build
process with the use of automatic triggers from the version control system. One example trigger
would be when new code is merged to the production branch of the codebase upload the build to a
remote server for users to download.

Automated Deployments: When builds are ready to be distributed they go through a deployment
process. Depending on the project deployment can have a variety of outcomes. For example, web
projects are deployed to publicly accessible web servers. During this deployment, the artifact that
was generated in the build phase is copied onto the web servers. The deployment process for
mobile and desktop vary and may involve uploading to a ‘store’ so users may download the app.
Continuous Integration Tools
Bitbucket Pipelines
Bitbucket Pipelines is a CI tool directly integrated into Bitbucket, a cloud version control system

Page|13
BTCS711-18 Abhishek,2202498

offered by Atlassian. Bitbucket Pipelines is an easy next step to enable CI if your project is
already on Bitbucket. Bitbucket Pipelines are managed as code so you can easily commit pipeline
definitions and kick off builds. Bitbucket Pipelines, additionally offers CD. This means projects
built with Bitbucket Pipelines can be deployed to production infrastructure as well
Website: https://bitbucket.org/product/features/pipelines
Jenkins
Jenkins is a veteran CI Tool with a long proven track record. It is open source and driven by
community updates. Jenkins is primarily intended to an on-premise installation. Jenkins is a great
option when your organization needs on-prem support for handling sensitive customer like
HIPAA compliance data.

Website: https://jenkins.io/

Circle CI
Circle CI is CI Tool that gracefully pairs with Github, one of the most popular version control
system cloud hosting tools. Circle Ci is one of the most flexible CI Tools in that it supports a
matrix of version control systems, container systems, and delivery mechanisms. Circle Ci can be
hosted on-premise or used through a cloud offering.

Website: https://circleci.com/

GitLab
Gitlab is a new CI Tool which offers a full DevOps experience. Gitlab was created with intentions
to improve Github’s overall experience. Gitlab offers a modern UX with container support.

Website: https://about.gitlab.com

Atlassian Bamboo
Another CI offering from Atlassian. Whereas Bitbucket Pipelines is purely a cloud hostedoption,
Bamboo offers a self hosted alternative

Page|14
BTCS711-18 Abhishek,2202498

Task 6: Apply Design principle and Refactoring to achieve agility.

DesignPrinciple

1. Single-Responsibility Principle
“There should be never more than one reason for a class to change.”

As you can see, this principle states that an object/class should only have one responsibility and
that it should be completely encapsulated by the class. Here, when we talk about a
responsibility, we mean a reason to change. This principle will lead to a stronger cohesion inthe
class and looser coupling between dependency classes, better readability, and code with lower
complexity.

It is much more difficult to understand and edit a class when it has various responsibilities. So if
we have more than one reason to change, the functionality will be split into two classesand each
will handle its own responsibility.

We care about separating the functionalities because each responsibility is an access of change.
When a class has more than a single responsibility, those responsibilities become coupled and
this coupling can lead to a fragile code base that is difficult to refactor when yourrequirements
emerge.

2. Open-Closed Principle
“Software entities (classes, modules, functions, etc.) should be open for extension, but closedfor
modification.”

Here, the idea is that an entity allows its behavior to be extended but never by modifying its
source code. Any class (or whatever you write) should be written in such a way that it can
beused as is. It can be extended if need be, but it can never be modified. You can consider this
when you are writing your classes. Use the class in any way you need, but modifying its
behavior comes by adding new code, never by modifying the old. The same principle can
beapplied to modules, packages, and libraries.

By applying the open-closed principle you will get a loose coupling, you will improve readability
and, finally, you will be reducing the risk of breaking existing functionality.

3. Liskov Substitution Principle

“Subtypes must be substitutable for their base types.”

As its name says, Liskov's Substitution Principle was defined by Barbara Liskov. The idea here is
that objects should be replaceable by instances of their subtypes without affecting the functioning
of your system from a client’s point of view. Basically, instead of using the
actualimplementation, you should always be able to use a base class and get the result you were
waiting for. Often when we want to represent an object, we model our classes based on their
properties, but, instead of that, we should actually be putting more of our focus on the behaviors.

This principle basically confirms that our abstractions are correct and helps us to get codethat is
easily reusable and class hierarchies that are very easily understood.
What many say is that Liskov’s Substitution Principle has a very strong relation with the previous
principle, the Open-Closed Principle. Robert C. Martin even says that “a violation ofLSP is a
latent violation of OCP.”

Page|15
BTCS711-18 Abhishek,2202498

4. Interface Segregation Principle

“Classes that implement interfaces, should not be forced to implement methods they do notuse.”

Here, it’s about how to write interfaces. So what is stated? Basically, once an interface is
becoming too large/fat, we absolutely need to split it into small interfaces that are more specific.
And the interface will be defined by the client that will use it, which means that theclient of the
interface will only know about the methods that are related to them.

Actually, if you add methods that shouldn’t be there, the classes implementing the interface will
have to implement those methods as well. That is why the client shouldn’t be forced to depend
on interfaces that they don’t use. ISP is intended to keep a system decoupled and thuseasier to
refactor, change, and deploy.

5. Dependency Inversion Principle

“High-level modules should not depend on low level modules, rather both should depend on
abstraction. Abstraction should not depend on details; rather detail should depend on
abstraction.”

The last of the SOLID principles, but not the least, this principle is primarily concerned with
reducing dependencies amongst the code modules. Basically, the Dependency Inversion
Principle will be of a great help when it comes to understanding how to correctly tie your
system together.

If your implementation detail will depend on the higher-level abstractions, it will help you toget
a system that is coupled correctly. Also, it will influence the encapsulation and cohesion of that
system.
Refactoring

Refactoring code is changing code with two crucial constraints:

1. The changes make the code easier to understand and thus cheaper to modify.
2. The changes never change the functionality, the observable behavior, of the code.

That second constraint bears repeating: a refactoring should never change the behavior of a
program. This means that if the program is called before and after a refactoring with the same set
of inputs, the resulting set of output values will be the same.

Code refactoring aims to keep software from degrading, or, when it’s already degraded, toimprove its
design so it becomes easier to understand and change.
Code refactoring is important to eliminate design flaws, achieve maintainability, andextensibility
of a software system.
Crucially, code refactoring changes the design of the code, but never the behavior of the software. Never
the twain shall mix.
The Process of Refactoring

To minimize the likelihood that you’ll accidentally introduce bugs as part of your refactoring,you
want to follow a strict process.

Page|16
BTCS711-18 Abhishek,2202498

1. Ensure you can back out — restore to a version that was proven to work correctly. Make
sure you’ve committed all your changes and all tests against the committed code succeed. This
way you can restore back to this point if your refactoring doesn’t go as you envisioned.
2. Identify what you want to refactor and how — which refactorings to use.
3. If you have multiple refactorings to execute to accomplish a bigger restructure, you can
optionally, select a subset of automated tests to verify unchanged behavior after each individual
refactoring.
4. Iteratively: apply a refactoring and verify behavior is unchanged. If the tests show youdid
change the behavior, change the code, never the tests.
5. If you used a subset of automated tests during the refactoring process, run all tests to verify
unchanged behavior for the whole application.

Here again, if something broke, change the code to make the tests pass — don’t change the tests.
If you realize that you’re just not going to be able to get the tests passing again in a reasonable
amount of time, restore back to the working code you had before the refactoring process.

6. Assess the effect of the refactorings on quality characteristics of the software (e.g.,
complexity, understandability, maintainability) or the process (e.g., productivity, cost,effort).

If they’re not satisfactory and can’t easily be improved, restore back to the working code you had
before the refactoring process.

Benefits

More readable code! Be sure to give the new method a name that describes the method’s
purpose: createOrder(), renderCustomerInfo(), etc.

Same level of abstraction in both methods, which helps understanding of the code.
Less code duplication. Often the code that is found in a method can be reused in
otherplaces in your program. So you can replace duplicates with calls to your new method.

Isolates independent parts of code, meaning that errors are less likely (such as if thewrong
variable is modified)

Page|17
BTCS711-18 Abhishek,2202498

Task 7: Perform Testing activities within an agile project.

Agile is an iterative development methodology, where the entire project team participates
in all the activities. The requirements evolve as the iterations progress, through
collaboration between the customer and the self-organizing teams. As Coding and Testing
are done interactively and incrementally, during the course of development, the end-
product would be of quality and ensures customer requirements.
Every iteration results in an integrated working product increment and is delivered for User
Acceptance Testing. The customer feedback thus obtained would be an input to the next /
subsequent Iterations.

Continuous Integration, Continuous Quality

Continuous Integration is the key for Agile Development success. Integrate frequently, at
least daily such that you are ready for a release as and when required. Testing in Agile
becomes an essential component of all the phases of the development, ensuring continuous
quality of the product. Constant feedback from everyone involved in the project adds to the
quality of the product.
In Agile, communication is given utmost importance and the customer requests are
received as and when necessary. This gives the satisfaction to the customer that all the
inputs are considered and working quality product is available throughout the development.
Agile Methodologies
There are several Agile Methodologies that support Agile Development. The Agile Methodologies
include −
Scrum
Scrum is an Agile development method that emphasizes on team-centric approach. Itadvocates
participation of the entire team in all the project development activities.

XP
Extreme programming is customer-centric and focuses on constantly changing
requirements. With frequent releases and customer feedback, the end-product will be of
quality meeting customer requirements that are made clearer during the process.

Page|18
BTCS711-18 Abhishek,2202498

FDD
Feature Driven Development (FDD) involves designing and building features. The
difference between FDD and other Agile Development Methodologies is that the features
are developed in specific and short phases separately.
DSDM
Dynamic Software Development Method (DSDM) is based on Rapid Application
Development (RAD) and is aligned to the Agile Framework. DSDMfocuses on frequent
delivery of the product, involving users actively and empowering the teams to make quick
decisions.
Lean Software Development
In Lean Software Development, focus is on eliminating waste and giving value to the customer.
This results in rapid development and product of value.
Waste includes partially done work, irrelevant work, features that are not used by the customer,
defects, etc. that add to delays in delivery.
Kanban
Kanban focuses on managing work with an emphasis on just-in-time (JIT) delivery, while
not overloading the team members. The tasks are displayed forall the participants to see and
for the Team Members to pull work from a queue.
Kanban is based on −
Kanban Board (Visual and Persistent across the Development)
Work-in-progress (WIP) Limit
Lead Time Agile
Testing Methodologies

The testing practices are well defined for every project, whether Agile or not, to deliver
quality products. Traditional Testing principles are quite often used in Agile Testing. One
of them is Early Testing that focuses on −
o Writing Test Cases to express the behavior of the system.
o Early Defect Prevention, detection and removal.
o Ensuring that the right test types are run at the right time and as part of
the right test level.
In all the Agile Methodologies we discussed, Agile Testing in itself is aMethodology. In all the
approaches, Test Cases are written before Coding
The other commonly used Agile Testing Methodologies are −
Test-Driven Development (TDD) − Test-Driven Development (TDD)is based on
coding guided by tests.
Acceptance Test-Driven Development (ATDD) − Acceptance Test-Driven Development (ATDD)
is based on communication between the customers, developers and testers and driven by pre-
defined Acceptance Criteria and Acceptance Test Cases.
Behavior-Driven Development (BDD) − In Behavior-Driven Development (BDD)
testing is based on the expected behavior of the software being developed.

Page|19
BTCS711-18 Abhishek,2202498

Agile Testing Lifecycle

In Scrum, the Testing activities include −

o Contributing to User Stories based on the expected behavior ofthe
System depicted as Test Cases
o Release Planning based on Test Effort and Defects
o Sprint Planning based on User Stories and Defects
o Sprint Execution with Continuous Testing
o Regression Testing after the completion of Sprint
o Reporting Test Results
o Automation Testing

Testing is iterative and sprints based as depicted in the diagram given below −

Page|20
BTCS711-18 Abhishek,2202498

Task 8: Mini Project: based on tools

STEP 1: Search gitlab on google

STEP 2: Click on login option on top right corner

STEP 3: Fill your email and password to login or you can directly login using existing googleaccount

Page|21
BTCS711-18 Abhishek,2202498

STEP 4: Next , create new project and choose create blank projec

STEP 5: Fill your project name

STEP 6: Click on create project button given at the bottom

Page|22
BTCS711-18 Abhishek,2202498

STEP 7: Since you have created a project successfully, so now you can send invitation for teammembers
to join the group by clicking first on project information and then on activity

STEP 8 : Now , you can see all the team members and can work on the project collectively

Page|23
BTCS711-18 Abhishek,2202498

Creating a milestone

STEP 1: Click on ‘Issues’ and then on ‘Milestones’ present on the left side of the screen

STEP 2: For creating a new milestone, click on the ‘new milestone’

STEP 3: Following tab will be opened.

Page|24
BTCS711-18 Abhishek,2202498

STEP 4: After filling the required details about your project, you can click on ‘create milestone’

STEP 5: Your milestone is created successfully.

STEP 6:Creating a requirement and raising an issue

Page|25
BTCS711-18 Abhishek,2202498

Creating documentation using wiki

Step 1:Click on Wiki section to create a documentation

Step 2:Write the documentation and click on save changes to publish it.

Version Control
Step 1:There are many ways to check version control

Page|26
BTCS 711-18 Suryansh
Kumar(2103061)

Step 2: For checking the logs in Wikis, click on wiki section

Page | 26