Мотивація

uTest дотримується структурованого процесу тестування, який зазвичай включає в себе вступ до проекту, виконання тестових кейсів, повідомлення про помилки та закриття тестового циклу. Тестувальникам призначаються конкретні тестові кейси, які вони виконують у визначеному тестовому середовищі. Після виконання тесту тестувальники надсилають детальні звіти про помилки на платформу.

Якщо звіт про помилку буде відхилено, це негативно вплине на оцінку тестувальника залежно від типу відхилення.

Тестувальники можуть оскаржувати помилки (баги), що були відхилені замовником.

Заповнювачі (placeholders) заборонені

Тестувальники можуть використовувати будь-який зареєстрований пристрій, якщо він відповідає вимогам тестового циклу.

Інженер-тестувальник відбирає тестувальників для участі в тестуванні.

Test IO використовує гнучкий процес тестування, який включає планування, виконання тестів та постійний зворотній зв'язок. Тестувальники беруть участь у тестових циклах, які відповідають їхній мові, пристроям та місцезнаходженню. Ми робимо акцент на тестуванні в режимі реального часу та ручному дослідницькому тестуванні, що дозволяє тестувальникам виявляти та повідомляти про помилки "на льоту".

Щоб почати брати участь у циклі тестування, тестувальники повинні заздалегідь розпочати тестову сесію та підтвердити, що вони прочитали і зрозуміли інструкції щодо функцій, які підлягають тестуванню.

Для виявлення дублікатів, коли ви надсилаєте (створюєте) звіт про помилку, з правої сторони на панелі відобразиться список "Схожі помилки" зі списком вже надісланих (створених) помилок у поточному тесті, також ви маєте можливість скористатись пошуком і фільтрувати помилки та список відомих помилок у тесті.

Якщо звіт про помилку відхилено, це негативно впливає на бали тестувальника в залежності від типу помилки, що була відхилена.

Тестувальники можуть оскаржити помилки, що були відхилені лідером команди. Після того, як звіт буде оскаржено, він буде заблокований для розгляду командою оскарження помилок.

Звіти-заповнювачі (placeholders) категорично заборонені.

Залежно від пристроїв, які зареєстровані в профілі тестувальника та іншої інформації, система обирає один з пристроїв і запрошує вас взяти участь в тестуванні. Ви не зможете змінити і тестувати на іншому пристрої після того як прийняли запрошення для участі у тесті. Тому пристрій який вказується у звіті та на якому здійснюється пошук помилок, це пристрій, який був обраний під час запрошення до тестового циклу.

Форма звіту про помилку uTest має наступну структуру:

З іншого боку, форма звіту про помилку в Test IO спрощує документацію тестувальника завдяки наступній структурі:

Вам не обов'язково дотримуватися певного формату для створення заголовку у звіті про помилку. Проте структура заголовку повинна відповідати наступним запитанням: що (що саме сталося)? де (де виникла помилка, наприклад: на якій сторінці сайту)? коли (після яких дій)? . Тобто при написанні заголовку у звіті про помилку потрібно дотримуватися принципу: Що? Де? Коли?

У нашій звіт-формі про помилку вам не потрібно додавати номер кожного кроку; форма вже містить його, нумерація кроків відбувається автоматично. Також слід зазначити, що ви маєте можливість перетягувати кроки та змінювати їх місцями за власним бажанням.

Пристрій який був обраний під час прийняття запрошення до проекту додається автоматично до звіту під час написання звіту про помилку, виняток стосується тільки браузера під час тестування веб-сайтів (потрібно самостійно обрати браузер в якому було знайдено помилку). Обраний пристрій не може бути змінений під час тестування.

uTest класифікує такі помилки як:

Тестувальники повинні точно виявляти і повідомляти про ці помилки.

Test IO класифікує помилки наступним чином:

Ми не проводимо тестування безпеки.

Нижче наведемо деякі пояснення стосовно специфікацій помилок. Помилки контенту - помилки, що пов'язані з будь-яким типом інформації, а не лише з текстом (наприклад, переклади; слід зауважити, що друкарські помилки не розглядаються як помилки контенту), тому відсутність зображень і кнопок - це помилки контенту, а не візуальні помилки.

Функціональні помилки, що стосуються продуктивності, такі як нескінченне завантаження, можна вважати функціональними помилками, якщо вони безпосередньо впливають на кінцевих користувачів, наприклад, на доступ до контенту або прогрес у виконанні завдання.

З іншого боку, під час виконання циклів тестування продуктивності, які виконуються на вимогу, нескінченне завантаження є проблемою продуктивності, і про це повідомляється у звіті про помилку; тому демонстрація вимірювання швидкості інтернету на відео та надання файлів в форматі .har є частиною додатків (вкладень), які необхідно прикріпити до звіту.

uTest класифікує функціональні помилки за наступними критеріями (виділяє такі ступені серйозності):

В Test IO ми пропонуємо наступні види ступенів серйозності помилки; їх всього три:

Сценарії, які ми пропонуємо, допоможуть проаналізувати проблему з різних боків, наприклад, з огляду на порушену функціональність та потенційний вплив помилки на кінцевих користувачів. Наприклад, баги, що зупиняють роботу сайту, є критичними, але якщо існує просте та інтуїтивно зрозуміле обхідне рішення, наприклад, перезавантаження сторінки, то ступінь серйозності помилки буде низьким.

uTest дозволяє тестувальникам додавати до своїх звітів про помилки відповідні файли, такі як знімки екрану (скріншоти), записи екрану (відео) та лог-файли.

Знімок екрана (скріншот):

Відео (скрінкасти):

Тестувальники Test IO можуть додавати до звітів про помилку наступні вкладення: знімки екрану (скріншоти), відео (скрінкасти) та журнали збоїв (crash logs).

Знімок екрана (скріншот):

Відео (скрінкаст):

Для тестування продуктивності файли .har обов’язкові.

uTest сприяє комунікації між тестувальниками, менеджерами проектів та розробниками за допомогою спеціальної системи обміну повідомленнями. Тестувальники можуть звертатися за роз'ясненнями щодо вимог та взаємодіяти зі стейкхолдерами протягом усього циклу тестування.

Test IO робить акцент на спілкуванні в режимі реального часу, дозволяючи тестувальникам співпрацювати та обговорювати проблеми через тестовий чат, коментарі до звітів про помилки, сервер Discord та електронну пошту між тестувальниками, керівниками команд (TL), менеджерами по роботі з клієнтами (CSMs) та клієнтами. Тестувальники можуть ставити запитання, звертатися за роз'ясненнями та отримувати миттєвий зворотній зв'язок від вищезгаданих стейкхолдерів, оскільки вони можуть запитувати інформацію із завдань тестувальників.

uTest, виплата залежить від того, наскільки цінною є помилка:

Виплати в Test IO залежать від типу виконаного завдання. Є завдання, безпосередньо пов'язані з тестовими циклами. На відміну від них, інші, такі як репродукції, підтвердження виправлення помилки та підтвердження звіту про помилку, можуть бути виконані без приєднання до тестового циклу, до якого належить звіт.

Проте в тестовому циклі виплата залежить від типу та серйозності багу, а також від характеристик пристрою.

На платформі uTest тестувальники можуть виконувати:

На платформі Test IO тестувальники фрілансери можуть виконувати оплачувані завдання та отримувати такі бонуси:

Замість того, щоб чекати, поки клієнт прийме або відхилить вашу роботу, на платформі Test IO оплата за знайдену помилку або виконане завдання, моментально зараховується на ваш рахунок, як тільки лідер команди розгляне та прийме відповідну помилку (або завдання)