‘Just Enough’ documentation in an Agile Project

Agile poses many challenges to the development team, most of them pertaining to time. Teams are perpetually under pressure to deliver working software at a fast pace, leaving minimum time for anything else. When testing on an agile project, learning how to write lean documentation can save precious time. Furthermore writing lean documentation can help rework efforts by focusing only on what’s really necessary.

The Agile Manifesto emphasizes working software over comprehensive documentation, but most agile teams interpret this wrong and treat documentation as something to be avoided, owing to time constraints. The manifesto states a lesser focus on comprehensive documentation, but some documentation is still needed for the project and any related guidelines being followed. Attaining this balance is a challenge.

Documentation is a necessary evil. We may think of it as cumbersome and time-consuming, but the project cannot survive without it. For this reason, we need to find ways to do just enough documentation — no more, no less.

Read about how to focus on important areas like VALUE  , COMMUNICATION and  SUFFICIENCY when documenting in your agile project – in my article published at Gurock TestRail blog –> https://blog.gurock.com/lean-documentation-agile-project/

just enough

Click here to read the full article

For example, in a traditional test design document, we create columns for test case description, test steps, test data, expected results and actual results, along with preconditions and post-conditions for each test case. There may be a very detailed description of test steps, and varying test data may also be repeatedly documented. While this is needed in many contexts, agile testers may not have the time or the need to specify their tests in this much detail.

As an agile tester, I have worked on teams following a much leaner approach to sprint-level tests. We document the tests as high-level scenarios, with a one line description of the test and a column for details like any specific test data or the expected outcome. When executing these tests, the tester may add relevant information for future regression cycles, as well as document test results and any defects.

More examples and scenarios for learning leaner test document creation are included in the full article– Click here to read the full article

 

                 Are you interested in finding the right tool for your Agile processes? Here is a comprehensive assessment and comparison of the best agile tools available! 

https://thedigitalprojectmanager.com/agile-tools/

Prepared by Ben Aston, this list may be a useful guide for finding and selecting the best tool to support your agile journey. Check it out!

 

Happy Testing!

Nishi

Crafting User Stories That Agile Teams Will Love

A popular term you will come across when working in agile is the “user story.” For the uninitiated, a user story is a technique of expressing software requirements in a specific format, usually:

As a < role of user >, I want to < perform an action >, so that < goal of user >

This adds more detail and description, and it’s sure to include the real need of the user when expressing the requirements.

For agile teams, user stories are a typical way to begin a conversation about a feature. But issues arise when we stop adding more beyond the one-line user story format. Most agile teams are crippled by incomplete, ambiguous and vague user stories that lack depth and details.

In my experience, there are some ways we can ensure that the user stories we craft are usable and valuable in all aspects. In my latest article for Gurock TestRail Blog, I talk about strategies to craft meaningful, understandable and valuable user stories for your agile teams.

We discuss INVEST Principle of User Stories, 3Cs of a User Story and how to learn from Experience of past sprints to improve your user stories. Read the full article here-

https://blog.gurock.com/crafting-user-stories-agile-teams/ 

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

 

 

 

‘INVEST’ing in good User Stories

User stories are the requirement specifications in their simplest form. Methodologies like Scrum use User story format to express the functional requirements of the software to be developed as –

As a <user persona>, I want to <do the action> so that <need of function>

This creates a deeper understanding of the behavior from a user’s perspective along with the business need and reason for the function, thus making the development of software easier.

But writing effective user stories isn’t as easy as it sounds. There are a lot of questions to be answered, like which functionality is one user story and which is too big and needs splitting up; what is the true sense of the user story; how to best express the functionality in words; which user personas are to be considered etc.

Getting the user stories right is an essential step to success of the sprints in agile, and for the teams struggling with it we have the INVEST principal as a guideline to be followed. This principal gives the attributes of a user story to be considered when writing and defining them so that they can make a robust foundation to our product backlog. Let us look at the principle in depth –

I – Independent

Means that each user story must be Independent as a functionality and be deliverable

N – Negotiable

Means that the user story be negotiable in terms of implementation, which necessarily means that the implementation details or ‘how’ to do the functionality must not be specified in the user story. User story must be business need and customer experience story.

V – Valuable

Means that the user story must create value for the customer. We should be able to see the reason and way the function will be valuable to the customer and this can be gauged by direct communication with the stakeholders, and can also be quantified in terms of ‘business value’ that we can associate with each story.

E – Estimable

Means that the User story must be clear and concise enough so that we can estimate the amount of work required to achieve it with accuracy. Any unclear parts, missing information or discrepancies must be clarified before we can finalise a user story to be taken up for development.

S – Small

Means that each user story must be a small chunk or slice of work. The development of one user story must be doable within one sprint and hence anything bigger than that would need to be further split down.

T – Testable

Means that each user story must be testable as a feature and have a unique new function get added to the product.

Letter Meaning Description
I Independent The user story should be self-contained, in a way that there is no inherent dependency on another user story.
N Negotiable User stories, up until they are part of an iteration, can always be changed and rewritten.
V Valuable A user story must deliver value to the end user.
E Estimable You must always be able to estimate the size of a user story.
S Small User stories should not be so big as to become impossible to plan/task/prioritize with a certain level of certainty.
T Testable The user story or its related description must provide the necessary information to make test development possible.

Keeping these points in mind when designing and formalising our team’s user stories will ensure that the sprint runs smoothly without unforeseen scenarios, glitches in implementation due to unclear requirements and re-work due to frequent changes.

Have more questions? How to achieve this?

Stay tuned for the next article where we will look at the steps to achieve the best user stories.

Happy Testing!
Nishi