Page Comparison

Versions Compared

Key

This line was added.
This line was removed.
Formatting was changed.

Jira Legacy

server	System JIRA
serverId	815f41e5-e5fb-3402-8587-82eccc3ffab0
key	LF-3057

Currently if the user creates a new irrigation task with the location that has a default irrigation type already established , it is observed that irrigation_type_id is not included in the Payload. The existing irrigation type is regarded as a new type, and a new record is added to the irrigation_type table. (A new type should be added only when the user selects “Other”)

Area / scope to test	Front end	Back end	Model	Notes
Requirement specific constraints

Exported doc shows “Depth_cm”, not “Depth”

N/A

N/A

FW shouldn’t be able to download template

FW shouldn’t be able to upload template

	Test as per Jira Ticket	`irrigation_type_id` should be included in the Payload ,of the `POST` `/task/irrigation_task` API, and a new irrigation type should not be created.	Check if in the database assigned `irrigation_type_id` is the same , when the user interacts with the field “Type of Irrigation” and when this field is filled with the default irrigation type that was already established.
Role based constraints

FW can’t see upload modal or even “+” symbol on farm map (not strictly in scope of this ticket, but easily verifiable)

Validation and logic should be updated to ensure uploads with different languages create sensors as expected

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

Exported document should include the language of the user “Depth_cm” vs. “Profundidad_cm”

Validation must verify via in-line error that 0 <= Depth_cm <= 1000

Either decimal or integer

N/A	N/A		Is this impacted by user or farm preferences such as language, system of measure, certification status?
Numerical input constraints

Validation must verify via in-line error that 0 <= Depth_cm <= 1000
Either decimal or integer

Validation must verify via in-line error that 0 <= Depth_cm <= 1000

Either decimal or integer

Validation must verify via in-line error that 0 <= Depth_cm <= 1000

Either decimal or integer

N/A	N/A		Do we appropriately handle negative, very small, very large, or 0 as inputs?
Text input constraints

Validation must verify via in-line error that 0 <= Depth_cm <= 1000
Either decimal or integer

Validation must verify via in-line error that 0 <= Depth_cm <= 1000

Either decimal or integer

Validation must verify via in-line error that 0 <= Depth_cm <= 1000

Either decimal or integer

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

Validation must verify via in-line error that 0 <= Depth_cm <= 1000
Either decimal or integer

Validation must verify via in-line error that 0 <= Depth_cm <= 1000
Either decimal or integer

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

Presentation of in-line error for invalid “Dept_cm” values displaying “There were some issues with your upload. Click here to view them.” “Upload” should stay disabled

For csv that passes validation, “Upload” button should become active

Post-upload of 1+ sensors, map should resize to show all sensors and all other visible location

N/A	N/A		Is the UI transitioning appropriately? Is the API providing da
Flow based constraints

When clicking “<“ from modal, expand drawer

No expectation of upload being persisted when going back

After uploading an invalid csv, user can upload a valid one directly and flush the previous oneShould see success banner

	N/A	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

If upload takes more than 3 seconds, transition to asynchronous flow and prompt user with modal

Should receive follow-up notification

If upload takes less than 3 seconds, sensor(s) should appear on map after being successful persistance

N/A

N/A

When notification is received, data should be available in the database

		Is the interaction synchronous, asynchronous, or does it support both? Can you simulate both if so?
Time-out / low bandwidth constraints

Should follow asynch route in low bandwidth

For lost connection, …Should be uploaded in cm and stored in m (e.g. divided by 100)

	N/A	N/A		Does the feature fail gracefully under no bandwidth / low bandwidth environments?
Data transformation correctness

After a successful upload, viewing any of the uploaded sensors should show the depth_cm on the sensor detail page appropriately transformed from cm to meters

After successful upload, verify performing a GET on the uploaded sensor(s) returns depth appropriately transformed

Verify sensor created on sensor table

N/A	N/A		Are values appropriately updated when units change? Is it WYSIWYG?
Outcome correctness

For success: success banner displays
- Correctly for a single sensor
- Correctly for 2+ sensors
Validation error displays in-line for bad inputs
For poor connectivity, appropriately goes to async

Success: returns 400
Errors:
- Code varies by reason

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

Verify uploaded sensors only exist at farm where they were uploaded

	N/A	N/A		Does this feature respond well to switching farms (and returning)?
Notification constraints

For async route, should see:

Success or failure based on validation (including a valid Depth_cm value)

	N/A	N/A		Should a notification be marshalled based on this action?
Cascading effects

Upon successful upload, reframe the map to appropriately show all uploaded sensors
Upon successful upload, clicking on an uploaded sensor displays the correct details

Upon successful upload, check to see what sensors are now:
- Registered
- Unregistered
- Receiving data
If a sensor already exists and is registered at another farm, it should fail to be added to this farm
If a sensor has previously been unregistered, it should be registered to this farm
If there’s a data feed associated with a sensor it should start receiving data

N/A	N/A		Are there logical places
Integration constrains	N/A

Upon successful upload, check to see what sensors are now:
- Registered via the Ensemble API
- Unregistered via the Ensemble API
- Receiving data from the Ensemble API
If a sensor already exists and is registered at another farm, it should fail to be added to this farm
If a sensor has previously been unregistered, it should be registered to this farm
If there’s a data feed associated with a sensor it should start receiving data

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?