A Process for Testing
The current process
Where do project requirements exist?
- Trello cards
- Google docs
- Design mockups
- People's brains
How do we make sure it works?
- Code reviews
- Demo days
- Matt
Business Requirements
Business requirements can be difficult to track down
( GO TO TRELLO )
Business Requirements
What is complete?
( GO TO TRELLO / GITHUB)
Details can get lost
Business Requirements
Manual testing
Manual testing is very tedious and time consuming
- Not easily reproducible
- Human error (e.g. – typos)
- Regression testing
- "Is this bug new?"
Manual testing
Okay when used sparingly...
It's easier to debug code at a lower level than at a higher level of the testing pyramid.
Usually, because it affects less code overall.
Manual testing
What it usually turns out to be
Writing unit tests is difficult if you don't know how to.
It can take you longer to write a test than to actually write the code.
Acceptance Testing
"Demo Days" are ran at the end of the sprint
- Ran at the end of a sprint
- Not always on a staging environment
So, how can we improve the process?
Acceptance tests
Integration tests
Unit tests
Define tests
(work inwards)
Pass the tests
(work outwards)
A model for having requirements drive development
Example flow
The user should be a view to log in
There should be a log in endpoint that takes user credentials
Given the correct credentials, the user should log in
Acceptance tests
(Cucumber tests)
- Described in behavior driven steps
- Usually, in the form of user stories
Feature: Refund item
Scenario: Jeff returns a faulty microwave
Given Jeff has bought a microwave for $100
And he has a receipt
When he returns the microwave
Then Jeff should be refunded $100Create seed data
With requirements and user stories defined, it's important for data to exist.
Seed data and test data should be clearly separated from each other.
JSON
Database seeds
Frontend mock data
Craft / Sketch / InVision
deck
By Tony Gaskell
