The 12 Agile Principles: What We Hear vs. What They Actually Mean

The Agile Manifesto gives us 12 principles to abide by in order to implement agility in our processes. These principles are the golden rules to refer to when we’re looking for the right agile mindset. But are we getting the right meaning out of them?

In my latest article for Gurock TestRail blog, I examine what we mistakenly hear when we’re told the 12 principles, what pain points the agile team face due to these misunderstandings, and what each principle truly means.

 

Principle 1: Our Highest Priority is to Satisfy the Customer Through Early and Continuous Delivery of Valuable Software

What we hear: Let’s have frequent releases to show the customer our agility, and if they don’t like the product, we can redo it.

The team’s pain points: Planning frequent releases that aren’t thought out well increases repetitive testing, reduces quality and gives more chances for defect leakage.

What it really means: Agile requires us to focus on quick and continuous delivery of useful software to customers in order to accelerate their time to market.

Principle 2:

Check out the complete post here —- Click Here to Read more–>

 

Do share your stories and understanding of the 12 Agile Principles!

Cheers

Nishi

The Value of Risk-Based Testing from an Agile ViewPoint

When I first heard about risk-based testing, I interpreted it as an approach that could help devise a targeted test strategy. Back then I was working with a product-based research and development team. We were following Scrum and were perpetually working with tight deadlines. These short sprints had lots to test and deliver, in addition to the cross-environment and non-functional testing aspects.

Learning about risk-based testing gave me a new approach to our testing challenges. I believed that analyzing the product as well as each sprint for the impending risk areas and then following them through during test design and development, execution and reporting would help us in time crunches.

But before I could think about adopting this new found approach into our test planning, I had a challenge at hand: to convince my team.

In my recent article published at Gurock’s blog site , I have written about my experience on exploring risk based testing and convincing my agile team about its importance and relevance using their own sprints’ case study.

Using the analysis of a sprint’s user stories, calculating Risk Priority Number (RPN) and the Extent of Testing defined, I was able to showcase in my own team’s case study, ways our testing could benefit and better itself by following risk based approach in a simplified manner.

Risk Priority Number

To read the complete article, Click Here–> 

In the article I talk about–

  • Tackling the Agile Challenges
  • Benchmarking Risks and a Focused Approach
  • Improving Test Process and Results

Do share your thoughts on Risk Based Testing!

Cheers

Nishi