Bug Bash Fundamentals

What is a bug bash?

It’s a collaborative event where the whole team, no matter what their role is, comes together to try to “break” the application in creative ways ahead of a release. The goal is to find as many bugs as possible in a short period of time, and since every person in the team will have their own unique perspective and use the application in different ways, there are better chances of uncovering issues, defining how severe they are and if needed fixing them ahead of the release. It’s also a great opportunity for people to spend some time familiarizing themselves with the application and putting themselves in the shoes of one of our users. And last but not least, breaking things can actually be fun! By doing bug bashes often, we’re cultivating a blame-free culture where we take bugs as a chance to bond as a team, learn and improve.

How do I participate?

1. If you’re willing to collaborate with this bug bash, please write your name down in the Participants section. If possible add details about what language(s) you’re using when testing the app, as well as which user role(s) you’re logging in as. This will help us know if there are any languages or roles not currently being covered by anyone.

2. Read through the scope of what we’re testing in the Scope section. The scope will usually be defined based on what kind of changes we are pushing out on the upcoming release and it’s a guidance on which are the main things to keep an eye on. That being said, if you do find any bugs that are unrelated to the scope, feel free to report them anyway.

3. If the bug bash is done synchronously, there’ll be a meeting where we all come together and test at the same time with a time box. If it’s done asynchronously, we’ll aim to have the session open for enough time that people in different timezones are able to participate. In that case, feel free to participate whenever you can and have the time and to time box depending on what your schedule looks like. Everything helps, so even if you only have limited time to test, you might discover something that nobody else has found before. Information on the timing of the meeting or asynchronous session can be found in the Session details section

What do I do if I find a bug?

First off, congratulations on finding it! To report the bug, head over to the Bugs section and add a new row in the table. The row should include your name and a brief description of the bug, on the Details field please add as much information as possible. Please provide reproduction steps and expected/actual behavior, and if you have the time, screenshots or video recordings of what you encountered will be extremely helpful. You don’t need to fill out the Pre-existing, Priority or Blocker fields as those will be filled out once the session is over.

If you spot a bug and you see someone else has already reported it and it’s on the table, you can go ahead and just add your name to the “Also seen by” column to mark that the bug is encountered frequently, without having to write down all the details again.

What happens after the bug bash?

Once the bug bash session is over, the team will go over the list of bugs that were found and prioritize them. For each issue, we’ll try to answer these three questions:

• Was this bug caused by the change we’re aiming to push out on this release, or does it currently exist in production?

• How severe and how frequent is this bug, or in other words, what’s the priority for fixing it?

• Should this bug block the upcoming release?

No matter the result, if the issue found is something we’d like to fix eventually, we’ll create the corresponding ticket in Jira and add it to the Backlog. If we come to the conclusion that one or more bugs are actually blocking the upcoming release, we’ll add those tickets to the current sprint and give them the highest priority. If no bugs are found that are blocking, we’ll proceed with the release process as normal and work on the reported issues in future sprints depending on their priority.

Participants

Scope

https://lite-farm.atlassian.net/browse/LF-4759

This bug bash will focus on testing the new features introduced in the release, particularly the ability to add an irrigation prescription.

Purpose of the Release:

This update enables users to create irrigation prescriptions on their farms, review existing prescriptions, and receive daily notifications about new irrigation recommendations—enhancing decision-making and farm water management.

User Stories

As a LiteFarm user (Farm Manager, Farm Owner, Farm Worker, or Extension Officer), I want to:

1. Receive Notifications for New Irrigation Prescriptions

   • Ensure that users receive daily notifications when a new irrigation prescription is available.
     LF-4762

2. Approve an Existing Irrigation Prescription

   • Ensure that users can approve newly available irrigation prescriptions.
     LF-4761

3. View and Access Latest Approved Irrigation Prescriptions

   • Ensure that the most recent and approved irrigation prescriptions are clearly displayed and easily accessible.
     LF-4760

4. Create an Irrigation Task Based on an Irrigation Prescription

   • Ensure that users can create irrigation tasks associated with a selected irrigation prescription.
     LF-4763

5. Download Irrigation Prescription Files

   • Ensure that users can download the irrigation prescription file when viewing a created irrigation task.
     LF-4763

6. Farm Worker Access and Permissions

   • Ensure that Farm Workers can view irrigation prescription files and are also able to approve irrigation prescriptions.

Known Issues

Session Details

Usability Suggestions:

This section is where you can add your suggestions for improvements for the UX that are not faulty behavior or bugs, but that we’ll take into accout for future iterations

Regression testing

Regression testing ensures that recent code changes have not negatively impacted existing functionality. It involves testing key features to identify any unexpected issues and maintain software stability..

.

Bug Reports