Мотивація

Testlio використовує структурований процес тестування, пов'язаний з робочими областями. Тестувальникам призначаються конкретні робочі області для проведення різних видів тестування, таких як дослідницьке тестування, тестування оплати, функціональне регресійне тестування, тестування локалізації, тестування доступності, тестування зручності використання (юзабіліті), тестування потокового медіа в прямому ефірі (стрімінг тести) та тестування SDK-інструментів, де вони виконують тестові кейси з початку до кінця.

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

Переглядаючи звіти інших тестувальників або здійснюючи пошук у "Браузері проблем" (❝Issue browser❞), тестувальники можуть знайти повторювані помилки (дубльовані баги) при написанні звіту про помилку (баг-репорту). Тестувальники автоматично отримують пропозиції щодо схожих, вже повідомлених помилок (баг-репортів), якщо заголовок у звіті про помилку містить щонайменше 30 символів.

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

В залежності від робочого простору, тестувальники можуть або не можуть отримати запрошення до участі у проекті; все залежить від потреб робочого простору.

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

Після закінчення відведеного часу для тестування тестувальники повинні відповісти на опитування.

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

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

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

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

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

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

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

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

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

Форма звіту про помилку (баг форма) або проблеми в Testlio мають наступну структуру:

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

Кожна помилка (баг) повинна мати префікс розділу, де вона виникає, перед заголовком, якщо інше не передбачено.

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

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

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

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

Зазвичай Testlio класифікує помилки (баги) наступним чином:

Для документації функціональних багів необхідні два вкладення (attachments).

Локалізаційне тестування вимагає перевірки проблеми з інтерфейсом користувача і змістом самого продукту.

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

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

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

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

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

Ступінь серйозності функціональних помилок (багів) у Testlio наступний:

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

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

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

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

Файли журналів (лог-файли) є обов'язковими, тому для функціональних багів потрібно надавати два різні вкладення.

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

Хоча знімок екрану (скріншот) або відео (скрінкаст) можуть легко документувати візуальні баги, для функціональних багів потрібно надавати два вкладення для кожної поданої помилки.

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

Усі помилки повинні мати скріншот (навіть якщо тестувальник додав відео), також слід додати текстовий файл із вибіркою HTML-коду помилки. Іноді інформації в розділі "Вкладення в звіті про баги" ("Attachments in Bug Report") вистачає.

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

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

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

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

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

Тестувальники використовують електронну пошту для відправки запитів щодо покращень.

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

Testlio платить тестувальникам погодинно, а не за баг.

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

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

В Testlio тестувальники фрілансери отримують оплату відповідно до годин, які їм призначено для виконання конкретних завдань у рамках запуску (run) у конкретному проекті.

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

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