“A Beginner’s Guide to Software Testing!” [Part — 2]

In our previous blog, we looked at a few common testing terminologies, techniques, and benefits. In this blog, we will be looking more into the agile process and the terms associated with it which is an important part of a software development project.

Agile terminologies

Agile

It is an iterative approach to software development where value is delivered incrementally rather than at once. In agile iterative development, we go through a cycle of PDCA ( Plan, design, check/test, adjust ).

A few advantages of agile methodologies are:
1. Better flexibility for making changes.
2. Better customer satisfaction.
3. Early risk identification.
4. Higher productivity and quality.
5. More control over the process.
6. Better return on investment.

What is a sprint?

Sprint is a fixed period of time within which the team targets to finish a particular number of tasks.
This is important in Agile as sprints help the team to have unified goals and stay well updated about the project status.
Sprints help in adding value to the product functionality incrementally.

Sprint Planning

Sprint planning is done before we start off with our sprint. The teams will discuss and decide the tasks that need to be taken up as a part of the sprint and also the product backlog to be worked on. The backlog is picked up based on priority which is usually described by the product owners.

Scrum

Scrum is a framework that describes teamwork, set of meetings, and roles ​to help teams structure and manage their work to achieve well-defined goals.
In a scrum, the Product Owner, Scrum Master, and Development Team are the three important roles.

Agile project management tools

Agile projects are fast-moving. Good coordination, management, and execution of the agile project can be achieved by using agile project management tools.
Every project management tool has different features and the team needs to choose tools depending on their requirements. A few popular tools are Jira, Kaban, Trello, Asana.

Story

Stories articulate the work that must be completed to deliver a feature for a product.
Each story is given Story Points which is a measure of the overall effort it would take to finish complete the user story.

A good user story will demonstrate the INVEST principle.

INVEST principle

INVEST is a simple set of criteria used for creating meaningful user stories.

The acronym stands for :
● Independent​ — Stories should be independent of one another.

● Negotiable — Stories should contain only the requirement and not how it can be solved.

● Valuable — Stories should illustrate value to the customer.

● Estimable — Stories should provide just enough information so they can be estimated. It is not important to know the exact way that a particular problem will be solved in your story.

● Small — Stories should be as granular as possible with respect to the scope so they can be completed within the estimated time.

● Testable — Stories should be clear enough to write tests for them.

Acceptance Criteria

Acceptance criteria are a set of predefined requisites that need to be met in order to consider a user story as done.
They should be independently testable, clear and understandable to everyone.

Velocity

Velocity is the measure of how much ​a team can deliver within a sprint.
It is calculated by totaling story points for each complete user story at the end of the sprint.

Estimation

In agile we estimate a user story using story points. Estimating helps us determine the priority of user stories and the approximate time the team would take to complete them.
While estimating we need to keep in mind time, resources, human skills, and cost. Estimations are done in Agile projects via different techniques like Planning Poker, Bucket System, Affinity Mapping, etc.

Burn Down Chart

The burndown chart is a graph that shows the team the amount of work remaining versus the time left to do it.

It helps the team get a better understanding of their day-to-day progress on user stories planned for the sprint.

Test Coverage

Test coverage is the measure of how much source code of your program has been tested. It helps us evaluate the quality of our test suite.
It is measured in percentage.

Test Coverage = (Executed Test cases/Total Test cases) * 100

Defect life cycle

A defect/bug is an unexpected behaviour that is not a part of the system requirement. This defect goes through a cycle from when it is found to when it can’t be produced anymore.
This cycle is known as the defect lifecycle.

Retrospection

A retrospection meeting should be held at the end of every sprint where the team discusses what went well and what could be done better during the sprint.
This helps the team analyze areas of improvement that should be worked on for future sprints.

That brings us to the end of this blog.

Coming up next …
We will be looking into more software testing terms, best practices and principles in our part 3 blog.
Stay tuned.

Happy reading! 😄