L QA
@TID
SOME BACKGROUND
Internal QA?
AIN'T NOBODY GOT TIME
FOR THAT!
the approach
-
Map out the app (all possible interaction flows)
- Make a list of User Stories
- Make a list of all inputs permutations that fulfill each story
-
Go through the app and log bugs
QA based on
USER STORIES
vs
QA based on
ALL POSSIBLE INTERACTIONS
(app smashing)
APP SMASHING
(systematic) APP SMASHING
SYSTEMATIC APP SMASHING
-
Go through all pathways in flowchart
-
Erase nodes as I go through them
-
Log issues in spreadsheet, some in Sobeys Web lighthouse
-
Review, reproduce and prioritize issues with tech leads
-
When ready for re-test, they make a note
-
Re-test
-
Regression tests against future builds
RESULTS
Flowchart was useful for app smashing
(but is clumsy to use and ugly to look at)
App smashing discovered many bugs, some quite obscure
(but is time consuming)
ANDROID TESTING
- Compare Android with iOS
- Find styling issues and bugs
- Didn't use the flowchart much
Reflections
- Confirm workflow of app with devs and project managers
- What are known issues that have stories and are in the queue
-
Write acceptance criteria when we make user stories
-
When finished a story, test it against its acceptance criteria
-
Then, try to find the edge cases
REFLECTIONS
"On a high level,
internal QA is a good thing."
REFLECTIONS
- Up-to-date sitemaps and test scripts ready with every sprint.
3 levels of test scripts:
- Primary set: core functionality
- Secondary set: more edge-case
- App smashing: trying to break the app, obscure edge cases
REFLECTIONS
We need some kind of integration between
Internal QA Spreadsheet -> Lighthouse -> Almost-Scrum
Over every sprint, pair Dev and QA planning
Process suggestions
Dedicated QA person
During story writing:
Develop Acceptance Criteria with Devs
Every sprint:
Maintain updated documentation
(test scripts, site map/flowchart)
(test scripts, site map/flowchart)
When a story is completed:
QA test against acceptance criteria
After merges, new builds:
QA test with primary, or secondary scripts
Before deploying:
App smash
"The surest way to kill a project is to view testing as a "phase" that belongs at the end of a project as opposed to an integrated part of the ongoing development process. Waiting until the very end to start testing will create problems for even the simplest of projects. An iterative and collaborative QA testing/user acceptance testing process can be a powerful tool for discovering issues early and providing forecasting data that helps to guide the project to a successful deployment."
- first google search result
Shout outs
Steph
Brian
Tom
Jono
Amanda
Chris M
Rob
Chris E
Neil
Copy of Internal QA @TWG
By xavierval
