Minbar's learning platform serves two very different users — students and admins — on one shared system. We documented every screen, action, and flow for both, giving the team a single reference to build test coverage on with confidence.
- Client / Product
- Minbar — a Learning Management System (LMS) for course delivery, progress tracking, and assessments
- User roles
- Student and Admin / Super Admin
- Our role
- Manual QA — end-to-end user flow mapping, functional and exploratory testing
- What we delivered
- Complete navigation maps for both user roles, covering 8 student screens and 12 admin modules
The Challenge
Minbar isn't one product — it's two. Students need a simple, motivating path from browsing a subject to finishing a course. Admins need full control over categories, users, grading, and access, without ever getting in each other's way, even though both sides share the same underlying data.
Before new features and test coverage could move forward with confidence, the team needed a single source of truth: exactly what does every screen contain, what can a user actually do on it, and where does each action lead?
Our Approach
We treated this as a documentation-first QA engagement, built in five steps:
- Screen capture & inventory — every screen in scope was captured and catalogued: fields, buttons, filters, status indicators, and navigation entry points.
- Flow mapping — screens were sequenced into real end-to-end journeys, with explicit links showing where each action leads, creating a navigation map that mirrors how people actually use the product.
- Action & outcome cataloguing — every action (search, filter, create, toggle, bulk upload) was paired with its expected result, giving the team a clear baseline for what "working correctly" means.
- Test case design & exploratory charters — the flow maps became the direct input for structured test cases and for exploratory testing sessions targeting specific modules and transitions.
- Cross-module bug pattern tracking — because both roles were documented against the same consistent structure, the team can now spot patterns that repeat across modules, not just isolated bugs.
What We Mapped
On the student side, the journey runs from Login through a personalised Home dashboard into Explore, My Learnings, My Assessments, Notifications, and Profile — each screen documented down to its buttons, filters, and where they lead.
On the admin side, we mapped the full management console: Dashboard, Category, Course, Grade Book, Question Bank, Tutor Evaluation, User, Admin, Role, Feedback & Review, Notification, and Settings — twelve modules, each following a consistent search → review → act pattern.
The Outcome
- A single, agreed reference for what every screen does — removing guesswork between QA, development, and stakeholders
- Test cases and exploratory charters grounded in real captured screens, not assumptions
- A framework for spotting recurring issues across modules, instead of chasing one-off bugs
- Clearly flagged gaps (course players, subject listings, submission detail views) mapped out as the defined starting point for the next testing pass
Why It Matters
Good QA isn't just catching bugs — it's building a shared map that everyone on the team can trust. By documenting Minbar's student and admin experiences end to end, we gave the team a durable foundation for regression testing, faster onboarding, and confident releases as the platform keeps growing.