Functional and Negative Testing of the E-Learning Platform

Functional and Negative Testing of the E-Learning Platform

Industry

E-learning

Country

United States

Type of Service

Manual testing

Cooperation Type

By estimate

Project Type

Web app testing

Overview

The product* is an open-source educational platform designed to provide offline access to a wide range of open-licensed educational resources for low-resource contexts (rural schools, refugee camps, orphanages, etc.) and non-formal school programs.

* We recognize the importance of protecting our clients’ privacy and follow the policies to maintain their confidentiality and security. That is why the company name will not be disclosed.

Challenge

Users can access the product’s high-quality educational content via several publicly available channels, collections of educational resources (exercises, videos, audio, and text files), and associated metadata, all organized for use in the system. The product integrates with its curriculum tool used for managing educational resources and building custom channels that can be aligned to the local curricula or according to specific learning needs.

The client requested to test the entire platform to find any defects or inconsistencies in the functionality.

Solution

To prepare an effective testing strategy, our team starts with studying the product. In this case, we also needed to learn more about the new device – RPi that was provided by the client.

  • We copied all testing scenarios from GitHub to Google Sheets to make sure that all the relevant test cases will be covered.
  • The software under test was installed on the Raspberry Pi. The device was connected to the MacBook via a WiFi network to access the e-learning platform.
  • The QA specialist tested Gherkin scenarios for the RPi platform in Chrome. Thus, we checked the core features in Super Admin, Coach, Learner, Guest, and server package scenarios.
  • The scenarios that passed were pointed with checkmarks. In case the test failed, the issues were commented on and filed to the development team via GitHub.
  • Throughout the process, the QA engineer kept in touch with the client’s development team and contacted them via Slack to clarify certain product-related aspects.

Results

We found nearly 30 defects. Most of the detected bugs were of a minor or medium level of severity. However, the list of defects features critical issues and blockers – serious bugs that can block the release due to affecting the core functionality and making a product impossible or almost impossible to use.

Let’s Start a New Project Together

QA Madness helps tech companies strengthen their in-house teams by staffing dedicated manual and automated testing experts.

Anastasiia Letychivska

Head of Growth

Ready to speed up the testing process?