Prepared and completed by Joyce Cervantes.
When testing the Cost Calculation feature, the first thing I would validate is whether the calculation formula itself is accurate and based on the correct logic, combining daily distance, fuel efficiency, and fuel prices. I would also test how the system handles decimal values and rounding, especially in borderline cases that could slightly shift the final results.
Another key point is ensuring the calculation updates instantly when a user changes input values, this is essential for a smooth and transparent experience. I’d also verify if unit conversions (km-miles or BRL-USD) are consistent and clearly communicated, especially if the platform is used in different regions. Finally, I’d test how the system behaves under poor connectivity or heavy usage, since users may access the platform on mobile or slower networks.
One potential issue is unrealistic savings due to invalid input. For example, if someone enters 5,000 km/day, the estimated savings would spike to an absurd value, which could mislead the user or damage the platform’s credibility. To prevent this, I’d recommend setting logical input boundaries and showing helpful messages when values exceed real-world scenarios.
Another issue is how the results are presented. A statement like “You save $1,800” means little without context. Users might wonder: “per year? Compared to what?” I’d suggest adding breakdowns (monthly/annually), side-by-side comparisons, and even visual elements like graphs or badges to improve clarity and engagement.
Here is my proposed two-phase development and testing approach, designed to prioritize stability and early validation.
Phase 1 – Inputs & Selection
What to implement:
Why: These features form the foundation of the platform and enable early testing of user interactions and data validation before deeper logic is introduced.
QA focus:
Phase 2 – Processing & Output