Jak testować szkolenia e-learningowe?

Kiedy i kto testuje

Jak zapewnić wysoką jakość szkoleń e-learningowych? W jaki sposób na bieżąco upewniać się, że tworzone e-szkolenie jest zgodne z wymaganiami biznesowymi? W LLidero odpowiadamy na to pytanie następująco: często testować. Bliskie jest nam testowanie typowe dla zwinnego podejścia do zarządzania projektami (agile). Nie jest to etap do wykonania na końcu, ale integralna część poszczególnych etapów projektu. Zobacz, jak to u nas wygląda.

Na etapie koncepcji Strategiczną Kartę Szkolenia (SKS), którą opracowuje lider projektu, testują:

zespół deweloperski (copywriter, deweloperzy) pod kątem wykonalności technicznej,
klient pod kątem tego, na ile nasza propozycja przystaje do potrzeb, celów i kultury organizacyjnej.

Na etapie tekstów dokument, który przygotował copywriter, testują:

lider projektu pod kątem zgodności z koncepcją,
drugi copywriter pod kątem poprawności językowej,
klient pod kątem poprawności merytorycznej.

Najbardziej wymagające testowanie dotyczy etapu implementacji, czyli wykonania technicznego. W tym przypadku obszarów do sprawdzenia jest najwięcej. Przyjrzyjmy się im bliżej.

Co testuje w szkoleniu zespół deweloperski

Gdy powstaną ekrany e-szkolenia, pierwszej weryfikacji dokonuje sam deweloper, który je przygotował. Sprawdza, czy opracowane przez niego mechanizmy sprawnie działają, a proponowana stylistyka jest spójna i zgodna z brandingiem klienta. Taka autokorekta wydaje się oczywista, ale warto o niej przypominać, bo bywa pomijana.

Trudno zdystansować się do efektów własnej pracy, więc obowiązkowym punktem przed wysłaniem ekranów do klienta jest przegląd przez inne osoby z zespołu. Najczęściej jest to lider projektu, copywriter lub inny deweloper - ktoś, kto może spojrzeć nieco z boku na opracowane ekrany. Zwracamy uwagę na to, czy na ekranach szkolenia:

przeniesiona jest właściwa zawartość tekstowa,
zawarte są odpowiednie instrukcje dla użytkownika,
otwierają się wszystkie odsłony i czy zawierają odpowiednią treść (np. czy tekst o tym, czego nie wolno robić podczas pożaru nie wyświetlał się pod hasłem pożądanych zachowań),
pojawiają się odpowiednie informacje zwrotne w ćwiczeniach i teście (np. czy poprawna odpowiedź nie jest pokazywana i liczona jako nieprawidłowa i odwrotnie),
przyciski wykonują przypisane im akcje (np. czy przycisk „Powtórz test” resetuje wyniki, odpowiedzi i przerzuca użytkownika do początku testu),
zachowane są zasady użyteczności (np. wyróżnienie odwiedzonych elementów),
proponowana wizualizacja pasuje do treści i koncepcji,
dostępne są elementy sterujące multimediami (włącz/wyłącz, powtórz, pasek postępu) oraz napisy do nich z transkrypcją,
nie pojawiają się błędy techniczne (np. „Pytanie 11. z 10” albo „Wynik: 20 przy progu zaliczenia: 7/10”),
nie pojawiają się błędy w przypadku powrotu na ekran,
nie ma innych problemów,
nie ma błędów językowych, które mogły powstać w trakcie przenoszenia tekstu lub dopisywania instrukcji.

Jeśli ważnym wymogiem w projekcie jest dostępność cyfrowa szkoleń e-learningowych, bierzemy pod uwagę dodatkowe kryteria, np. przejście wszystkich ekranów klawiaturą, kolejność i kontrast fokusa czy obecność i sens opisów alternatywnych.

Sprawdzamy szkolenia zgodnie z powyższymi kryteriami co najmniej trzy razy, na następujących etapach produkcji:

próbka ekranów

wersja bez lektora

wersja z lektorem

Jeśli wersja e-szkolenia posiada już narrację lektorską, testujemy, czy włącza się w odpowiednim miejscu, a także czy jest odpowiednio zsynchronizowana z zawartością ekranu.

Testujemy w ten sposób zarówno szkolenia e-learningowe na zlecenie klientów (dedykowane), jak i nasze szkolenia z biblioteki szkoleń gotowych.

Ewentualne uwagi najczęściej przekazujemy sobie na zrzutach ekranu z komentarzami. Dzięki temu deweloper dokładnie widzi, o jakie miejsce w szkoleniu i jaki problem chodzi.

‍

Rysunek 1. Przykładowa uwaga przekazywana wewnątrz zespołu

Dopiero tak przejrzane szkolenie może trafić do klienta.

Co testuje klient w zamawianym szkoleniu

Celem dokładnego testowania po naszej stronie jest takie przygotowanie szkolenia e-learningowego, aby klient mógł skupić się na zawartości merytorycznej. Przy czym przez pojęcie klienta rozumiemy często cały zespół projektowy po stronie zlecającego. Jesteśmy więc przygotowani na różnorodność, a niekiedy nawet sprzeczność oczekiwań.

Na co najczęściej zwracają uwagę klienci? Oto mój subiektywny ranking.

Największa liczba uwag dotyczy sformułowań językowych. Co prawda teksty konsultujemy wcześniej, ale zdajemy sobie sprawę, że ten sam fragment inaczej wygląda jako zapis w Wordzie, a inaczej np. gdy wymawia go postać w animacji. Niektóre zmiany teksty są również wynikiem przeglądu przez osoby, które do tej pory nie były zaangażowane w projekt. Okazuje się, że niektóre teksty wymagają sprecyzowania lub poszerzenia. Zdarza się również, że u danego klienta użyte w e-szkoleniu słowa budzą negatywne konotacje, jak np. „organizacja”, które w pewnej instytucji kojarzyło się z organizacją przestępczą.

Duża część uwag dotyczy restrykcji względem użytkowników końcowych – ich luzowania (np. nieograniczona liczba podejść do testu) albo zaostrzania (np. możliwość przejścia dalej dopiero po kliknięciu wszystkich przycisków na ekranie).

Na miejscu trzecim pojawiają się uwagi dotyczące wizualizacji i multimediów, szczególnie wyglądu postaci czy ekspresji (lub jej braku) w narracji lektorskiej. Najważniejszymi uwagami tej kategorii są te dotyczące położonych akcentów. Często naszym klientom zależy, aby niektóre elementy były wyraźniej wyeksponowane. Niekiedy proponują konkretne rozwiązania (np. „Proszę zapisać to dużymi czerwonymi literami”), a niekiedy po prostu potrzebują inspiracji z naszej strony (np. „Ta postać za bardzo kojarzy nam się z…”).

Najważniejszą rzeczą, na którą chcemy, aby klienci zwracali uwagę, jest dopasowanie całej zawartości szkolenia (pomysł, wizualizacja, tekst, działanie) do tego, kim są odbiorcy i czego potrzebują, by dobrze wykonywali swoją pracę.

Czy zgłoszona uwaga zawsze oznacza poprawkę

Po przeglądach klienta weryfikujemy, czy zgłoszone przez niego uwagi zostały uwzględnione. Niekoniecznie oznacza to, że wprowadzamy wszystkie poprawki. Staramy się dotrzeć do intencji zmian, które zgłasza klient, i proponować najbardziej optymalne rozwiązania.

Stosujemy przy tym zasady selekcji poprawek na trzy kategorie:

uwagi bezdyskusyjne, istotne lub kosmetyczne - do wprowadzenia
uwagi niejasne co do miejsca lub sposobu wprowadzenia – do wyjaśnienia
uwagi, które mogą istotnie wpłynąć na zakres, czas, budżet i jakość projektu – do ustalenia

Rysunek 2. Przykład dokumentu z selekcją uwag od klienta

W końcowej fazie projektu dochodzi do tego jeszcze testowanie, czy pakiet SCORM poprawnie importuje się oraz raportuje wynik i status na platformę e-learningową. Jeśli klient posiada własny LMS, wówczas przed przekazaniem pliku ze szkoleniem sprawdzamy go na SCORM Cloud, niezależnej platformie udostępnionej przez twórców standardu SCORM.

Testowanie e-szkoleń - podsumowanie

Wspomniałem na początku, że testowanie zajmuje nam 1/3 lub więcej czasu w projekcie. Wynika to przede wszystkim z tego, że projekt opracowania szkolenia e-learningowego wymaga – mówiąc żargonem kierowników projektów informatycznych - iteracji z kolejnymi przyrostami. Co to oznacza? Zaczynamy od kilku ekranów, często bez narracji, które w skrócie obrazują pomysł na szkolenie. Testujemy go w zespole i powstaje ulepszona wersja. To pierwsza iteracja. Po niej druga, gdy przykładowe ekrany trafiają do klienta (lub trenera – w przypadku szkoleń gotowych), który zgłasza swoje sugestie. Wprowadzamy je lub omawiamy, a następnie dalej rozbudowujemy i ulepszamy szkolenie. Dzięki temu małymi krokami, z których w razie czego można się szybko cofnąć, przybliżamy się do ideału – skutecznego e-szkolenia, które nie tylko dobrze wygląda i sprawnie działa, lecz także jest wartościowe merytorycznie i odpowiada na konkretne potrzeby naszych klientów.

‍