Page Comparison

Requirement specific constraints

Two versions of the modal:

1. Volume based

2. Depth based

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

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

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

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 “Calculate water usage” on LF-2800 opens the correct modal

• Water usage is calculated correctly

Volume based:

• 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

Clicking “<“ or “Save” returns the user to the Irrigation tasks details view

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.

• Changing location changes the location size displayed appropriately

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 constraintsIs the user appropriately informed of transitions from synch to asynch and vice versa?

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

Volume Modal:

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?