View Source

Date

01 Aug 2018

Refresher of contract tests: what they are, what our expectations are, make sure we are on the same page (Chongsun, after reviewing requisition contract tests found some issues to discuss)
Going forward, we want to know that contract tests are reliable
Do we know what we have vs what we need?

Discussion

reset the database after each contract test
- Could we use something like stellar to do this?
After someone changes demo data we have to reset the database
contract tests don't make sense right now
- descriptions for scenarios don't make sense
- test steps don't match scenarios
- running extra steps unrelated to the scenario
- have we audited tests to make sure they are correct?
Lukasz has been working on contract tests since this review by Chongsun
- We don't recreate db we use existing demo data in reference data
- An example is one contract test removed a period (as part of the test) but because ISAs require processing periods to exist, you have to also remove ISAs
- Also consolidated contract tests: for example field calculations, approve and then approve and reject
We should review contract tests systematically, to determine what needs to be updated and read clearly
- Create task to review existing contract tests, and document proposed changes/next steps
- Label existing manual test cases that could be converted to contract tests. These are ones that can be picked up by the teams.
As contract tests and functional tests are created, we need to continue to manage the manual test cases to dead ones that are no longer needed (such as create, authorize, approve test cases).
- Test leads should be responsible for writing a script for functional tests, while dev team implements
- When a functional test is created, then we can dead the manual QA test case