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 $100

Create 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