-
Notifications
You must be signed in to change notification settings - Fork 91
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Pull Request to merge my blog on UserStories (#53)
* Added snandal + test post * Updated example post * Renamed posts to _posts * Move example post to the right directory * Update1 2023-08-15-test-post.md * Update2 2023-08-15-test-post.md * Update3 2023-08-15-test-post.md * Update4 2023-08-15-test-post.md * Update5 2023-08-15-test-post.md * Update6 2023-08-15-test-post.md * Update7 2023-08-15-test-post.md * Add files via upload * Add files via upload * Delete Pic.png * Delete Pic1.jpg * Add files via upload * Update7 2023-08-15-test-post.md * Update8 2023-08-15-test-post.md * Update8 2023-08-15-test-post.md * Update9 2023-08-15-test-post.md * Update10 2023-08-15-test-post.md * renamed test post file * Update 2023-08-18-the-power-of-a-well-written-user-story.md * Removed double heading * update timestamp * Update related.yml to link more posts for the-power-of-a-well-written-user-story * Update11 2023-08-18-the-power-of-a-well-written-user-story.md * Update12 2023-08-18-the-power-of-a-well-written-user-story.md * Update13 2023-08-18-the-power-of-a-well-written-user-story.md * correct typo * Implemented review comment to replace test analyst with test engineer * update post dates * delete previous post * push the correct version of the post * update the date --------- Co-authored-by: tja103 <[email protected]> Co-authored-by: taddison-scottlogic <[email protected]>
- Loading branch information
1 parent
b5a6da9
commit 2f80d95
Showing
7 changed files
with
93 additions
and
0 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
69 changes: 69 additions & 0 deletions
69
_posts/2023-09-11-the-power-of-a-well-written-user-story.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,69 @@ | ||
--- | ||
title: The Power of a Well Written User Story - A Test Engineer's Perspective | ||
date: 2023-09-11 14:00:00 Z | ||
categories: | ||
- Testing | ||
tags: | ||
- testing | ||
summary: User stories are a pivotal component of Agile Software Development, serving as concise and user-centric descriptions of desired software functionality. Hence, here I am, discussing how crucial it is to put user stories right for setting the foundation for a well-structured, user-focused, and efficient development process. | ||
author: snandal | ||
--- | ||
|
||
At the heart of our modern software development process, lies the humble yet powerful concept of **"User Stories"** - the simplest way to capture what a user needs. *User Stories* serve as the bridge between the business stakeholders and the development team, providing a shared understanding of what the software should achieve. | ||
|
||
Over the last decade, as I worked on multiple projects, there has been one very common challenge that I faced almost everywhere. And that is - Despite having such a vital role in delivering high-quality software products, so little emphasis is given to putting the *User Stories* right. | ||
|
||
Thus, I would like to discuss the importance of logging adequate and accurate information in *User Stories* and its potential impact on the success of software projects. | ||
|
||
*User Stories* are the building blocks that transform user needs into Functional Software by : | ||
|
||
### Ensuring User-Centric Approach | ||
*User Stories* keep the focus on the end user, ensuring that features developed align with real user needs and goals. A well-written *User Story* provides a clear understanding of what needs to be built and why. It outlines the user's needs, the context of the functionality, and the expected outcome. Information logged in the *User Story* helps the team grasp the scope and objectives, reducing the chances of misinterpretations, ensuring that the development efforts align with customer requirements and expectations. | ||
|
||
### Promoting Collaboration and Communication | ||
Adequate information in *User Stories* fosters collaboration between the team and other stakeholders. It promotes discussions and clarifications, ensuring that everyone is aligned with the requirements and the expected outcome, and hence directly impacts the end product's quality and alignment with customer needs, which eventually leads to better understood and met user expectations. | ||
|
||
### Quality Assurance | ||
When it comes to testing, *User Stories* act as a foundation for test planning. Accurate information in the user story enables the test engineer to identify the necessary testing approaches and develop appropriate test strategies. It aids in determining the testing scope, risk areas, testing priorities, and helps the test engineer ensure comprehensive test coverage by understanding the user's expectations. | ||
|
||
## Why Does it Impact Test Engineers in Particular? | ||
While Agile methodologies offer opportunities for test engineer to continuously improve and collaborate closely with the team, these also bring their own set of challenges. | ||
|
||
With continuously evolving requirements, there always stands a need for quick adaptability. | ||
Also, in many places, the *User Stories* are collectively estimated; however, no matter how much we stress allocating sufficient time for testing activities or ensure earliest start for the same, majority time is consumed in building the functionality, and lots of things are pushed to test engineers last minute, adding an immense amount of pressure. | ||
|
||
Not having the latest information readily available in this continuously changing and stressful environment would unnecessarily slow down the delivery and could also have an impact on the overall quality of the product. Hence it is extremely important from a test engineer point of view that all necessary information is carefully recorded and available as part of the *User Story*. | ||
|
||
It is true that Agile values working software over comprehensive documentation, but it does not mean documentation is completely disregarded. Agile does promote "just enough" documentation, which means creating the necessary documentation to support the development process without excessive overhead. And that makes it even more important that adequate and accurate information is captured as part of the *User Stories* and also updated regularly (as required). | ||
|
||
## Essentials in any User Story | ||
Below are the essential components that make up a robust *User Story*, ensuring a shared understanding and smooth development process. | ||
|
||
**Description:** The purpose of the *User Story* clearly stated in simple and concise language, including - the user role or persona it pertains to, the actions while interacting with the system, the benefit or value added - why the user wants to perform this action and how it contributes to their overall experience. | ||
|
||
A *User Story* typically follows a straightforward template: | ||
|
||
"As a [type of user], I want [an action] so that [benefit or value]." | ||
|
||
For instance: "As a *registered user*, I want to *reset my password* so that *I can regain access to my account*." | ||
|
||
**Dependencies:** Any assumptions or dependencies that could impact the development and testing of the *User Story*, such as other *User Stories*, any external factors. Noting these down helps ensure that everyone is aware of potential hurdles and can plan accordingly. | ||
|
||
**Business Rules:** Any specific business rules or constraints that must be adhered to. | ||
|
||
**Acceptance Criteria:** The conditions that must be met for the functionality to be considered working as expected. | ||
|
||
These criterias must be specific and measurable, including both functional and non-functional requirements along with usability or accessibility requirements (as applicable). Include attachments and examples (where applicable), mockups or reference links to provide visual context for the *User Story*. Visual aids help align everyone's understanding of the feature's appearance and behavior. | ||
|
||
**Size or Estimation:** Rough, collectively agreed-upon estimation of the effort required to implement the *User Story*. | ||
|
||
**Definition of Done:** The conditions that must be met for the *User Story* to be considered complete, including aspects of design, testing, and documentation. | ||
|
||
**Acceptance Sign-Off:** People/Team who will approve the acceptance criteria and sign off on the completion of the *User Story*. | ||
|
||
|
||
Additionally, it is important to keep the *User Story* updated with any significant changes in any of the above components. | ||
|
||
An efficient way of making sure that the *User Stories* do not miss any important information is to use an internally agreed upon *User Story* template. Not Every *User Story* would need each one of the above components; however, having added these in the template would act as a checklist and ensure that the information will not me missed. | ||
|
||
**As a test engineer, it is important to understand the critical role that *User Stories* play in guiding the testing process and ensuring the delivery of high-quality software. And hence we need to ensure that each *User Story* is capable of not only meeting its acceptance criteria but also contributing to the overall excellence of the product.** |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
author: snandal | ||
layout: atom_feed | ||
--- | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,5 @@ | ||
--- | ||
author: snandal | ||
layout: rss_feed | ||
--- | ||
|
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,6 @@ | ||
--- | ||
title: Shikha Nandal | ||
author: snandal | ||
layout: default_author | ||
--- | ||
|
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.