A single-page web application that calculates how long a video or podcast will take to watch or listen to at different playback speeds.
This project began as a small real-world utility and evolved into a focused exercise in testable design, manual QA practices, and accessibility-aware development. It was iteratively improved through refactoring, defect discovery, accessibility enhancements, UX improvements, and structured manual testing aligned with ISTQB Foundation Level principles.
- Enter a duration using hours, minutes, and/or seconds
- Select a playback speed multiplier
- View:
- Adjusted playback time
- Time difference
- Percentage change
- Shows both human-readable and digital (HH:MM:SS) time
- Copy results to the clipboard
- Accessible error handling and screen-reader feedback
- HTML5
- CSS3
- Bootstrap 3
- JavaScript (ES6)
System Behaviour
The application accepts any non-negative integer values for hours, minutes, and seconds. Input values are not constrained to conventional clock limits; instead, all time input is internally normalised by converting it into total seconds. Calculations are performed exclusively using total seconds and the selected playback speed, after which results are converted back into a canonical hours–minutes–seconds format (as well as a digital format) for display. Negative values, missing required input, and zero-duration input are rejected with accessible inline error messages.
- The application accepts any non-negative integer values for hours, minutes, and seconds
- All input is converted into total seconds for calculation
- Original input is displayed as entered; resulting values are normalised.
Example:
- Input:
0h 93m 0s - Normalised as:
1h 33m 0s
This approach:
- Simplifies calculation logic
- Eliminates overflow bugs
- Enables meaningful boundary value testing (e.g. 59 → 60 → 61)
Core logic is implemented using small, reusable helper functions:
totalSeconds(h, m, s)formatFromSeconds(totalSeconds)formatTime(h, m, s)
This improves readability, maintainability, and testability.
Accessibility was treated as a first-class concern.
Implemented features include:
- Semantic HTML (
main,fieldset,legend) - Skip-to-content link for keyboard users
- Inline error messages using
role="alert"andaria-live - Focus management for error feedback
- Results announced via live region (
role="status") - Disabled states for unavailable actions (e.g. copy button)
The application is fully usable with keyboard navigation and screen readers.
- Results can be copied to the clipboard using a dedicated button
- Button is disabled until results are available
- Copy confirmation (or failure) is announced via an accessible live region
- State resets correctly when the form is reset
Note: Clipboard feature requires a modern browser.
- Prevents negative values
- Requires at least one non-zero time field
- Playback speed must be selected
- Inline validation replaces disruptive browser alerts
Manual testing was conducted in line with ISTQB Foundation Level principles, including:
- Equivalence Partitioning
- Boundary Value Analysis
- Negative Testing
- Exploratory Testing
Testing focused on:
- Time normalisation and rollover points
- Fractional playback speeds
- Error handling and accessibility behaviour
- Copy-to-clipboard functionality
Clipboard Testing Note:
For manual testing purposes, the application supports a URL parameter to simulate clipboard failures. Appending ?failClipboard to the application URL forces the copy-to-clipboard action to fail, allowing verification of error handling and accessible feedback without relying on browser or OS-level permission changes. This parameter is intended solely for testing and has no effect during normal usage.
This project was used deliberately to practise thinking like a tester: identifying risk areas, designing meaningful boundary tests, and validating observable behaviour rather than implementation details.
📄 Full testing details are documented in TESTING.md
- README.md – Project overview and design decisions
- TESTING.md – Manual test cases, boundary testing, and defect tracking
- NOTES.md – Development notes and refactoring rationale
- Clone the repository
- Open the project using a local development server
- (e.g. Live Server extension in VS Code)
- Open the app in your browser
- Enter a duration, select a playback speed, and click Convert
- Add automated unit tests for core helper functions
- Add warnings for extremely large durations
- Extract logic into a separate module
- Improve visual contrast for accessibility
- Add localisation support for different languages
✅ Feature complete
✅ Accessibility-aware
✅ Refactored and maintainable
✅ Manually tested
✅ Documented (README / NOTES / TESTING)