Prevention is the Best Cure- for Defects in Agile

The agile methodology focuses on building in quality from the very beginning of the software lifecycle. That is why we aim to find and fix defects early on: A defect found and fixed in an earlier lifecycle phase is a multitude cheaper than the same defect at a later stage.

But how can we more easily make it possible to prevent defects from percolating deeper in the software development lifecycle by fixing them in their nascent stages?

This is the main theme of my latest article for @Gurock TestRail blog – where I explore and explain ways to foresee, analyze and thwart defects in an agile context.

The main points discussed are-

Communication

Conduct Reviews

Demonstrate Often

Static Analysis and CI

Click Here to read the complete article –>

Please support by liking / commenting and sharing the article!

Cheers

Nishi

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

Optimize Your Hardening Sprint for a Quality Advantage

A hardening sprint is an additional sprint that some teams run to stabilize the code and ensure that everything is ready just before release. Agile teams vary in their opinions on using hardening sprints in Scrum, but if your team does agree on having one before your release, there may be a lot to be done and varied expectations from the product owner, testers and developers. It may also lead to other work being delayed, leading to accumulation of technical debt.

In my article for Gurock TestRail Blog, I have discussed some tips on optimising the hardening sprint and achieving the maximum quality before release.

I talk in detail about some main points to focus on–

  • Plan Ahead
  • Perform End-to-End Testing
  • Perform Non-Functional Testing
  • Perform Tests on Other Platforms and Languages
  • Reduce Lower Priority Defect Counts
  • Use your sprint Wisely

Read the full article here — > https://blog.gurock.com/optimize-hardening-sprint/

Please share your thoughts!

Happy Testing!

Nishi

Pesticide Paradox in Software Testing

Pests and Bugs sound alike?? They act alike too!! 

Boris Beizer, in his book Software Testing Techniques (1990) coined the term pesticide paradox to describe the phenomenon that the more you test software, the more immune it becomes to your tests.

Just like, if you keep applying the same pesticide, the insects eventually build up resistance and the pesticide no longer works. Software undergoing the same repetitive tests build resistance to them, and they fail to catch more defects after that.

  • Software undergoing the same repetitive tests eventually builds up resistance to them.
  • As you run your tests multiple times, they stop being effective in catching bugs.
  • Moreover, part of the new defects introduced into the system will not be caught by your existing tests and will be released onto the field.

Solution: Refurnish and Revise Test Materials regularly

In order to overcome the pesticide paradox, testers must regularly develop newer tests exercising the various parts of the system and their inter-connections to find additional defects.

Also, testers cannot forever rely on existing test techniques or methods and must be on the look out to continually improve upon existing methods to make testing more effective.

It is suggested to keep revisiting the test cases regularly and revising them. Though agile teams provide little spare time for such activities, but the testing team is bound to keep planning these exercises within the team in order to keep the best performance coming. A few ideas to achieve this:

  • Brainstorming sessions – to think of more ideas around the same component testing
  • Buddy Reviews – New joinees to the team are encouraged to give their fresh perspective to the existing test scenarios for the product, which might get some new cases added.
  • Strike out older tests on functionalities that are changed / removed
  • Build new tests from scratch if a major change is made in a component – to open a fresh perspective

 

UPDATE–

This article has been recommended and used as a reference by HANNES LINDBLOM in his blog at https://konsultbolag1.se/bloggen/veckans-testartips-15-tur-genom-variation