QA Tips by Dhanalaxmi Otari
1. Another benefit of acceptance criteria: When a feature cannot be completed in a sprint and
needs to be spread out across sprints. Then the team can use the acceptance criteria as a tool to see
where the user story could be broken into smaller pieces that still provide value to the customer, but can be completed in a sprint.
Credit:
Book-Pro Agile .NET Development with SCRUM
2. Acceptance criteria are essentially a clarification of the user story. It gives the team a set of steps that must be completed before the story can be considered done. The acceptance criteria are created by the product owner with the help of the customer. It sets the expectation of the user story. With this in place, a Test team has a great starting point to write the tests.
Credit:
Book-Pro Agile .NET Development with SCRUM
3. The most commonly used standard format for a User Story creation is stated below:
As a <user role/customer, I want to < goal to be accomplished> so that I can <reason of the goal>.
GWT format is as follows:
“Given some precondition when I do some action then I expect the result”.
we have started using the concept of GWT or Given, When Then
We find that GWT has a number of advantages :
GWT can deal with a more diverse set of functionalities.
GWT lends itself better to considerations of acceptance tests.
Credit:
https://lnkd.in/gt2dK8D
https://lnkd.in/gYutNMq
4. Characteristics of a user story:
The INVEST acronym provides a checklist that assists the tester in checking the quality
of a user story. INVEST stands for:
- Independent: The user story should be self-contained so that there is no inherent
dependency on another story.
- Negotiable: User stories, up until they are a part of a sprint, can always be changed
and rewritten.
- Valuable: user story must deliver value to the end-user
- Estimable: The user story must be capable of allowing the team to estimate
the effort for its implementation. If the user story is too vague, tasks like
development or testing cannot be accurately estimated.
- Small: A user story must be sufficiently small so it can be developed in an
iteration. Team size and the size/complexity of user stories will help to
determine how many stories can be delivered in an iteration.
- Testable: The user story must be testable. If there is insufficient information
available about the story to enable tests to be written, then the story should be
deferred until such time as that information becomes available.
Credit:
Books — Pro Agile .NET Development with SCRUM and Agile Testing Foundations: An ISTQB Foundation Level Agile Tester
5. The whole team can get together, to flesh out the user stories with acceptance criteria, as part of iteration planning but this can take a while. Larger or distributed teams may prefer to do this activity before the planning meeting — a trio of PO/BA/customer, developer, and tester is usually all you need. If you work this way, remember to review the acceptance criteria with the whole team before committing to delivering a story in the next iteration.
Credit:
https://lnkd.in/ep-nZPA
6. Acceptance criteria can be thought of as “what needs to be done”. Dev team uses acceptance criteria to clarify the scope of each story so that they are clear on what is expected to be done to deliver the story.
Credit:
https://lnkd.in/gkcrGqZ
7. Acceptance Criteria: In Agile, acceptance criteria refer to a set of predefined requirements that must be met in order to mark a user story complete. It is a formal list that fully narrates user requirements.
Requirements that must be developed and executed by the Dev team to consider the user story finished.
Well-defined acceptance criteria are the ground of any software project that has become a commercial success.
Credit:
https://lnkd.in/eFAQHsa
https://lnkd.in/eWZZPMN
8. Backlog Grooming: Quality Starts with the User Story: The tester approach
It is the process of reviewing and refining user stories to prepare them for commitment in a sprint. Backlog grooming is where entire team interact and discuss on the requirements aka user stories. We rarely have input into requirements definition and we often have limited interaction with developers during implementation. During these discussions, we get the opportunity to ask key questions to understand the requirements definition. We can ask technical questions to developers to understand the implementation. This results in more thoroughly defined user stories. Tester’s questions often prompt developers to consider issues they hadn’t previously thought about. They can resolve these with the first check-in rather than waiting for the question to be asked in the form of a defect report. This is prevention vs. detection in the later stage.
Credit:
QA Role in Scrum Leveraging Agile for Defect Prevention by Karen Ascheim Wysopal
9. During Sprint planning in Testing in Agile:
On the first day of a sprint, sprint planning takes place. This is the time when user stories are brought into the sprint and analyzed and estimated.
Credit:
https://lnkd.in/eDnpSMb
10. Testing in Agile :
- Testing is NOT a phase
- Everyone participates in the testing process
- It shortens the response time of feedback
- Reduces test documentation
- Flexibility to adapt different test strategies depends upon feature/user story(s)
11. In agile testing, testers follow the entire lifecycle but due to constant feedback and regular interaction between developers and customers, the application can be delivered in a short time without compromising on the quality. The tester and developers respond to quick changes in the application rather than following a fixed plan.
Credit:
https://lnkd.in/ewqhcpp #devops #testing
12. As a tester, I actively try to be involved in this process as it is my first opportunity to assess the requirements and the information provided. It also allows me a chance to gather information required for testing, which allows me to provide more reliable estimates.
Credit:
https://lnkd.in/eH9KY7H
13. Agile testing is iterative, interactive, a self-organized process that going beyond validation and verification to stretch, shrink, stress, evaluate, and reveal aspects of software under test.
Credit:
Agile testing by Ash Coleman
https://lnkd.in/e7vFwrB
https://lnkd.in/ewqhcpp
14. Clear grasp of business logic:
We, the testers are exposed to in-depth knowledge of how domain applications work. We have to work closely with the development team and PO or BA. It enables us to create innovative and effective business case scenarios.
Credit:
https://lnkd.in/epyjKNy
#softwatetesting #tipsandtricks #scrum #teams #businesslogic #testscenarios
