LF-2503 Test plan

Soil water potential reading component https://lite-farm.atlassian.net/browse/LF-2503

Area / scope to test

Front end

Back end

Model

Notes

Area / scope to test

Front end

Back end

Model

Notes

Requirement specific constraints

All UI elements visible as per Jira ticket

N/A

N/A

 

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?

User preferences constraints

Component is displayed in users preferred language

N/A

 

Is this impacted by user or farm preferences such as language, system of measure, certification status?

Farm-level defaults / preferences

units are displayed in preferred unit of measurement

N/A

N/A

 

Numerical input constraints

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

Relative to users present time and timezone at the time of viewing (not log-in), with 3 days prior and 1 day forward

N/A

N/A

Are we making valid assumptions about what dates should be allowed?

Timezone driven interactions

  • Must show previous 3-days in 6-hour steps (12 points minimum - 16 points maximum by 20h00 on 4th day) Steps should be 02h00, 08h00, 14h00, 20h00 in user’s local time

  • If upon reloading the page, a closer sensor_reading value now exists, the visualization should now contain that updated value

N/A

  • Ensure timezones between read_time at sensor location and view time on the UI are appropriately transformed and the reading on the visualization for each step corresponds to closest reading in the database post-transformation

If timezones play a role in the data, are they being displayed or converted appropriately?

Interaction / transitioning UI based constraints

  • Click on different nodes in the graph to see updates to soil water potential at that intersection

  • Upon checking or unchecking a legend item…Resize the y-axis as needed, if all items have been removed, no need to resize from the previous state

  • Only sensor reading components for selected reading types for the sensor are displayed

  • x-axis is static and does NOT resize

N/A

N/A

Is the UI transitioning appropriately? Is the API providing da

Flow based constraints

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 constraints

Display loader while loading the component

N/A

N/A

Does the feature fail gracefully under no bandwidth / low bandwidth environments?

Data transformation correctness

Soil water potential is always less than or equal to 0. It represents the suction needed to pull water from the soil. The highest value it can be is 0, in which case the soil is completely saturated.

 

 

Are values appropriately updated when units change? Is it WYSIWYG?

Outcome correctness

Data points are correctly grouped into steps based on the nearest reading_time in the database

Gaps in reading_time around steps are shown without a point

 

Deleting “nearest” points to a step in the database appropriately updates the UI after logging out and back in (or switching farms and returning)

When inputting known inputs with expected outputs - do you get the results you expect? Have you tested several “cases” of this?

Switching farms

Switching farms and going to the raw URL for the sensor displays an error (or at least no data)

Switching back to a farm with sensor readings that have been posted since last switch appropriately updates the store

 

 

 

Does this feature respond well to switching farms (and returning)?

Notification constraints

N/A

N/A

N/A

Should a notification be marshalled based on this action?

Cascading effects

 

 

 

Are there logical places

Integration constraints

 

 

 

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?