| Jira Legacy | ||||||
|---|---|---|---|---|---|---|
|
Add a linter for translations files.
Area / scope to test | Front end | Back end | Model | Notes |
|---|---|---|---|---|
Requirement specific constraints |
Two versions of the modal:
Volume based
Depth based
Ensure usage of utf8 character e2809c double quote is detected and replaced with utf8 character 22 in translation files on commit |
|
|
| |
Role based constraints | N/A | N/A | N/A | Does role determine what a user can see or do? Is this enforced uniformly across the front end and back end? |
Locale based constraints |
|
|
| Things like date format, and number format for phone numbers and currency inputs |
User preferences constraints |
For both versions:
All titles, subtitles, labels, units, inputs, etc. should be in the language of the user
Clicking “Save” on the modal, appropriately saves “Total water usage” to LF-2800
Volume based modal:
“Estimated flow rate” should be shown in system of measure (l / hr for metric, g / hr for imperial)
“Total water usage” should be shown in system of measure (l for metric, g for imperial)
Depth based modal:
“Estimated application depth” should be shown in system of measure (mm for metric, in for imperial)
“Location size” should be shown in system of measure (ha for metric, ac for imperial)
“Irrigated area” should be shown in system of measure (ha for metric, ac for imperial)
“Total water usage” should be shown in system of measure (l for metric, g for imperial)
N/A; confirmed via database
Display units are appropriately persisted:
“estimated_flow_rate” converted correctly to liters / min*
“estimated_flow_rate_unit” matches what user selected via UI
“estimated_duration” saved in minutes
“estimated_duration_unit” matches what user selected via UI
“Total water usage” should be shown in system of measure (l for metric, g for imperial)
“application_depth” should be transformed to meters and appropriately saved
“application_depth_unit” matches what user selected via UI
“Estimated_water_usage” should be transformed to liters and appropriately saved
“Estimated_water_usage_unit” matches what user selected via UI
N/A | N/A | Is this impacted by user or farm preferences such as language, system of measure, certification status? | |
Farm-level defaults / preferences |
Volume based modal:
“Default flow rate” is pre-populated if there is a default for the selected location
If a new location is selected by going backwards in the flow, this should update
Depth based modal:
“Default application depth” is pre-populated if there is a default for the selected location
If a new location is selected by going backwards in the flow, this should update
N/A
Volume based modal:
When “Default flow rate” is selected, we should…
Create a new location_default record with the “estimated_flow_rate” and “estimated_flow_rate_unit” populated if no location_default existed for that location
Update the location_default record with the new “estimated_flow_rate” and “estimated_flow_rate_unit” values if a location_default existed for that location
Depth based modal:
When “Default application depth” is checked, we should…
Create a new location_default record with the “application_depth” and “application_depth_unit” populated if no location_default existed for that location
Update the location_default record with the new “application_depth” and “application_depth_unit” values if a location_default existed for that location
N/A | N/A | N/A |
|
Numerical input constraints |
Via UI
Volume based modal:
“Estimated flow rate”
Decimal
0 <= value <= 999,999.99
“Estimated Duration”:
Decimal
0 <= value <= 999,999.99
Depth based modal:
“Estimated application depth”
Decimal
0 <= value <= 999.99
“% of location to be irrigated”
Decimal
0 <= value <= 100.00
“Total water usage”
Decimal
0 <= value <= 999,999,999,999.99
Need to verify that the “Location size” is correct for the selected location.
Via POST on endpoint:
Volume based modal:
“Estimated flow rate”
Decimal
0 <= value <= 999,999.99
“Estimated Duration”:
Decimal
0 <= value <= 999,999.99
Depth based modal:
“Estimated application depth”
Decimal
0 <= value <= 999.99
“% of location to be irrigated”
Decimal
0 <= value <= 100.00
“Total water usage”
Decimal
0 <= value <= 999,999,999,999.99
Need to verify that the “Location size” is correct for the selected location.
Via direct database insert:
Volume based modal:
“Estimated flow rate”
Decimal
0 <= value <= 999,999.99
“Estimated Duration”:
Decimal
0 <= value <= 999,999.99
Depth based modal:
“Estimated application depth”
Decimal
0 <= value <= 999.99
“% of location to be irrigated”
Decimal
0 <= value <= 100.00
“Total water usage”
Decimal
0 <= value <= 999,999,999,999.99
N/A | N/A | N/A | Do we appropriately handle negative, very small, very large, or 0 as inputs? | |
Text input constraints | N/A | N/A | N/A | Do we appropriately handle blank, very small, and very large inputs? Is there a strict format (such as email) that must be followed? |
Date based constraints | N/A | N/A | N/A | Are there logical restrictions on what dates can be input? Should a use be able to complete something in the future for example. |
Date based assumptions | N/A | N/A | N/A | Are we making valid assumptions about what dates should be allowed? |
Timezone driven interactions | N/A | N/A | N/A | If timezones play a role in the data, are they being displayed or converted appropriately? |
Interaction / transitioning UI based constraints |
For both versions:
Clicking “Calculate water usage” on LF-2800 opens the correct modal based on whether “Volume” or “Depth” is selected on LF-2800
If neither is selected, should see in-line error below “Calculate water usage” link
Clicking outside the modal or clicking “Cancel” returns the user to LF-2800 without persisting the entered information or transferring the value in “Estimated water usage” to LF-2800
Clicking “Save” closes the modal and transfers the value in “Estimated water usage” to LF-2800
Volume based modal:
Clicking on the help text icon displays correct help text for the modal "This calculator helps you calculate water usage based on Volume. If you would prefer to calculate based on Depth please go back and select Depth."
Depth based modal:
Clicking on the help text icon displays correct help text for the modal "This calculator helps you calculate water usage based on Depth. If you would prefer to calculate based on Volume please go back and select Volume."
Irrigated area is calculated correctly
N/A | N/A | N/A | Is the UI transitioning appropriately? Is the API providing da |
Flow based constraints |
Clicking outside the modal or clicking “Cancel” returns the user to LF-2800 without persisting the entered information or transferring the value in “Estimated water usage” to LF-2800, reopening the modal displays previous inputs.
Clicking “Save” returns the user to LF-2800 transferring the value in “Estimated water usage” to LF-2800 and reopening displays previous inputs.
N/A |
|
| Is state being preserved appropriately in a flow? If I go back and then forth, is it maintained? Is state invalidated when it should be? | |
Synchronous / asynchronous constraints | N/A | N/A | N/A | Is the interaction synchronous, asynchronous, or does it support both? Can you simulate both if so? |
Time-out / low bandwidth constrains | N/A | N/A | N/A | Does the feature fail gracefully under no bandwidth / low bandwidth environments? |
Data transformation correctness |
Total water usage is calculated correctly when all required values for the calculation are input
Depth Modal:
Need to verify that the “Location size” is correct for the location
“Irrigated Area” is calculated correctly. When a valid “% of location to be irrigated” is input
N/A |
| Is the data persisted as expected post-transformation? | Are values appropriately updated when units change? Is it WYSIWYG? | |
Outcome correctness | Is it clear whether the outcome was a success of failure? Does it have the “right” visual treatment? |
|
| When inputting known inputs with expected outputs - do you get the results you expect? Have you tested several “cases” of this? |
Switching farms |
|
|
| Does this feature respond well to switching farms (and returning)? |
Notification constraints |
|
|
| Should a notification be marshalled based on this action? |
Cascading effects |
|
|
| Are there logical places |
Integration constrains |
|
|
| Do we need to ensure state is consistent between LiteFarm and the external service? What failure cases do we need to handle? How do we report back the outcome to the user or external service? |
Concurrency |
|
|
| How do changes made to records affect other users on the farm? e.g. What happens when a record is soft deleted while another user is viewing said record? |