Raising the Bar chapter updates#38
Conversation
There was a problem hiding this comment.
Nice work! Can we take a look through the Test Strategy and cover other items in there. For example, the ability for them to flag a minor bug and it has high priority (forget what we call that), or how we define the severity, etc.
Also consider that the text for this should literally give details to an agent (in the future).
| === The importance of acceptance criteria | ||
|
|
||
| In order to ensure that each and every Story can be validated, a User Story should have an acceptance criteria to make it super clear to the developer what the business are accepting, and how the Test Pilot will be testing your solution. Let’s get the “story” straight before we start with delivering value as to what everybody’s expectations are. An example acceptance criteria for bug resolution could be: | ||
| In any successful software project, a well-planned testing strategy is key. We define testing not only by deadlines and requirements but by *acceptance criteria* agreed upon with stakeholders. It’s critical to create clear, *SMART acceptance criteria*—Specific, Measurable, Achievable, Relevant, and Time-bound—to ensure shared expectations across teams. This allows us to have precise testing and reduces ambiguity in what is deemed 'done.' |
There was a problem hiding this comment.
Can we create a section for this "Test Strategy" section? I think this could also be extended upon.
There was a problem hiding this comment.
What does SMART acceptance criteria—Specific mean?
There was a problem hiding this comment.
- Done
- SMART means Specific, Measurable, Achievable, Relevant, and Time-bound acceptance criteria. When focusing on Specific in SMART acceptance criteria, it means that the requirement or objective should be clear, detailed, and unambiguous.
There was a problem hiding this comment.
Let's say what that is then.
|
|
||
| To speed up the repeatable nature of testing to help improve the cadence of release, where possible we should leverage the use of automated test tools such as Playwright or Selenium Web Driver. | ||
|
|
||
| === CI/CD Pipelines |
There was a problem hiding this comment.
Amend the title of this?
There was a problem hiding this comment.
Changed to "Automated testing tools using" and moved out from paragraphs regarding types of testing
| @@ -50,16 +86,8 @@ Typically you would carry out performance testing in the Test (QA) environment. | |||
|
|
|||
| === User acceptance testing | |||
|
|
|||
There was a problem hiding this comment.
Can we add to this section about how we have a number of UAT sessions per Sprint. We don't expect to be able to test all the Features in week 1 of the Sprint, but get the Features through week by week. By having 3 sessions in a Sprint, we have 3 opportunities to get to production rather than only 1.
…been added. Some paragraphs has been restructured.
|
Pull Request's Approval is required |
|
Has a merge conflict that also needs resolving. |
|
@BenGWeeks |
|
Review this please @claude |
|
Claude encountered an error —— View job I'll analyze this and get back to you. |
2 participants
I've updated Raising the Bar chapter.
Some new paragraphs has been added and minor changes has been applied to some of the existing ones. Also structure has been updated.