| Table of Contents | ||||
|---|---|---|---|---|
|
...
Question | Decision | Status |
|---|---|---|
Who will decide whether or not a bug or UI change suggestion will be added to the backlog | ||
Create a feature to hold items we will never fix, so the team can use it as a reference in the future | ||
In which environment should we test backlog items and Playwright tests - Test or ACC, or both? | ||
If we have a single sprint branch, can we separate stories that are not ready to ship from stories that are ready to ship? | ||
Do we need an SMGS ticket for every time we ship an item (e.g. one every two weeks?) |
Testing - Dave
Test cases:
Submit form with no info added - purpose: to get error / warning message
Test happy case / path - fill out with proper info and make sure it is saved correctly on the frontend, retrievable in whatever form (e.g. in table, on same page - if looked up later). Need to know what type of data you are testing for. One happy test case.
Test each field for the limits (e.g. numbers/special characters - in letter only field; enter a huge number in a field, if entering names; making sure app does not crash) - SQL injection- coded this - can add extra info or delete info (drop table command). Write user stories that have failures - e.g. enter special characters and get an error message.
If multi-page form, make sure it appears as needed (in another form or in a report or db)
Test for usability - language presented is understandable in FR and ENG; check for consistency, fields line up
Every field / function needs to be tested
Test what it interacts with - e.g. if needs to be populated in a report, then add to the test
To start:
Tester would probably start with ad-hoc testing first to get familiar
Then write test cases
Test access to a URL - cannot access pages they are not supposed to - eg. enter admin page URL, and test with role-based access.
Developers wrote automated tests based on what was written by the QA
Changes - automated software generates a test code, and then can update the test code. Then save and rerun the test code.
Release process with shippable feature
...
Testing - brainstorming only
Discussion with Grace - April 4
Bugs addressed during the sprint. Leave some space for bug testing during the sprint
...
How to track modifications to backlog items. E.g. when testing, if something needs to be added, what should we do?
Discussion with Ashiq
PO and users:
test in ACC
They can test on the first day of the next sprint - will will give them a list of what we completed and they can test if they can, if not, that is ok - maybe 1 hr of testing for them
Dev - send a screenshot of new UI before the functionality is built to get feedback from PO via email. Do not need to send screenshots for things such as bugs, and FR translations. Only things we need feeback on.
PO walkover - two days before the end of sprint - 15-30 min to take a quick look if screenshots are not enough - flexible. PO may not need it every week.
Can show him work still in progress
Users can test in test environment if they wish after sprint review. We can give them a few bullet points of what we worked on. Either at end of review or first day of sprint.
...
How would we work with dev’s only to write test cases?
Discussion with Ashiq
QA free from manual testing
...