Good day everyone and thank you for reading this blog post!
Today, I’m excited to share our experience with the final testing of the new increments developed during Sprint 16. These increments stem from the user stories we tackled in this sprint. We began by selecting items from the product backlog, then broke them down into user stories, further decomposed them into technical tasks, and developed them within our two-week sprint timeframe.
Cleaning up last tasks in our Proj4.me
Before we dive straight to the final testing, me and my Dev team decided to go through a final checking of all our respective tasks being listed in our Proj4.me. This is to ensure that all them are addressed and completed.
Waiting for the Final Push to the Development Branch
Before we conduct our final testing prior to the sprint review, the development team will reassess each other’s work and complete the final push of their tasks to their respective branches. This ensures that all required technical tasks are validated and completed. Once this validation is done, they push these items to our development branch for a final code review. This process helps us cross-check the developers’ code to ensure adherence to best coding practices.
Checking the Increments of the User Story
The team successfully pushed their respective codes to the development branch and consequently, then deployed it to our Staging. We then checked the first user story of this sprint in our staging site and reviewed its functionality whether it meets its acceptance criteria or not.
First User Story: Enabling the Buyer to Proceed to Payment and Upload deposit slip
This user story enables buyers on our platform to upload their deposit slips to their accounts. In Cebu City, one preferred mode of payment for bulk commodity orders is bank transfer. To ensure transparency and verify payments, buyers upload a soft copy of their deposit slip, which includes the total order amount, to their supplier. This requirement was a key focus, leading us to develop the “upload deposit slip” feature.
To test this user story, I conducted an order simulation in our staging environment. I logged into a demo buyer account and submitted a mock order for Automotive Diesel Oil. Buyers can purchase petroleum commodities by clicking the “Get Quote” button and filling out the quotation form. The submitted information is processed by our system, which matches the requested quotation in real-time with the suppliers’ published offers for those commodities.
The buyer can view the suppliers’ prices on the quotation page and has the option to secure the order by booking the selected commodity. Once the buyer books the order, our system sends a booking confirmation to the chosen supplier. When the supplier confirms the order request, the system progresses the buyer’s order to the payment stage, where the buyer is required to submit the deposit slip to verify payment made via bank transfer.
Additionally, we reviewed the acceptance criteria for this user story to ensure it meets the definition of done. The user acceptance criteria are as follows:
- buyer can have a preview of the order details before proceeding to payment
- buyer can submit payment while reviewing the order
- another verification before submitting payment
- buyer can see details of the order(page)
- buyer can upload payment(deposit slip)
- buyer can review the uploaded deposit slip
- buyer can upload deposit slip while using mobile phone
- buyer can upload payment by accessing file manager
Next user story: Enabling the Admin to access admin terminal, view active quotation and view uploaded deposit slip
This user story marks a significant milestone for the development team with the introduction of a new user type on the platform: the Admin User. The Admin User has the privilege to view the status of orders and offers, view uploaded deposit slips, and disburse payments to vendors. Additionally, the Admin User can override and approve various actions, including user sign-ups.
For this user story, we enabled the admin to access their dashboard and admin tools. In this sprint, we focused on enabling the admin to view active quotations and the buyers’ uploaded deposit slips. The development team validated the scope of the user story by checking its acceptance criteria and testing it on our staging site to ensure it met the definition of done. The acceptance criteria are as follows:
Enabling the admin to view uploaded deposit slip
- admin can see the paid order details
- admin can click a verify button
- paid orders should have an uploaded deposit slip
- paid orders should have the details of the buyer
- admin can login in the login page using given account
- admin should be notified of wrong credential
- admin can see dashboard terminal
- admin can see lists of orders and order status
- admin can navigate the order status tab
- admin should be notified for successful login
After thoroughly reviewing the acceptance criteria for the admin’s user story, our team successfully verified that it met the definition of done. This confirms the sprint’s success in delivering the required features on schedule. A key highlight was the admin’s ability to view the buyer’s uploaded deposit slip, showcasing the seamless integration of the buyer and admin systems, including their APIs.
We are now confident that these newly developed platform increments are ready to be delivered, presented, inspected, and verified by our stakeholders during the Sprint Review.
Thank you for reading. Stay tuned for the Sprint 16 review presentation coming soon.
Cheers!