Tag: blogger

A Typical Day of a Tester in an Agile Pod : Guest Blog

Nishi Grover Garg1 Comment

I am glad to share that a guest post I wrote for The Test Tribe website has now been published.

I was approached by the team to contribute to their valuable and rich content library where they publish articles, how to’s, insights on testing topics, case studies and upskilling posts for their vast testing community.

I wrote about the life of a tester in an Agile Pod and how it might be different from a traditional tester. We follow a typical day of Ted, our protagonist who is a tester in an agile pod team. We see how he spends his day working with his developers, product owner and other stakeholders along with balancing his duties as a pod leader. Read the article here to follow along on his exciting journey–>

I am happy to be associated with The Test Tribe community and the great work they are doing!

Grateful for this opportunity and always looking ahead for more! 🙂

Cheers

Nishi

4 Exit Criteria your User Stories must have

Nishi Grover GargLeave a comment

Planning and developing new features at the fast pace of agile is a hard game. Knowing when you are really done and ready to deliver is even harder.

Having predetermined exit criteria helps you be able to make the decision that a feature is truly ready to ship. In my article published at TestRail Blog, I compiled a list of exit criteria you must add to your user story to make it easy to bring conformity and quality to all your features.

All Tasks Are Completed

This first one sounds obvious, but it may not be. I still see many teams struggling with getting their testing done within the sprint. Developers work on a user story and deem it done, while testers are left to play catch-up in the next sprint.

Put that practice to an end once and for all by making sure that no user story can be proclaimed done without having all tasks under it completed, including development tasks, testing tasks, design and review tasks, and any other tasks that were added to the user story at the beginning.

Ensuring all tasks are completed in a sprint also mandates that you begin thinking in depth about each user story and the tasks necessary for each activity to be completed, so that you do not miss out on anything at the end.

Tests Are Automated Whenever Possible

As our agile teams move toward continuous delivery and adopting DevOps, our testing also needs to be automated and made a part of our pipelines. Ensuring that test automation gets done within the sprint and is always up to pace with new features is essential.

By having test automation tasks be a part of a user story delivery, you can keep an eye out for opportunities to automate tests you are creating, allocate time to do that within the sprint, and have visibility of your automation percentages.

I have used the following exit criteria:

  • At a minimum, regression tests for the user story must be added to the automation suite
  • At least 50% of tests created for the user story must be automated
  • Automated regression must be run at least once within the sprint

Depending on what your automation goals are, decide on a meaningful standard to apply to all your user stories.

Read More »