Мотивація
Test IO означає підтримку розвитку тестувальників. Щоб переконатися, що ваша кар’єра тестувальника розвивається, ми вирішили поділитися з вами найпоширенішими помилками, які допускають наші тестувальники на початку своєї кар’єри тестувальника. Навіть досвідчені тестувальники іноді роблять помилки, і вони вчаться на цьому.
Дуже спокусливо спробувати все під час тестування, навіть деякі незвичайні кроки, які звичайний користувач ніколи не зробив би. Коли виникає таке бажання, зупиніться перед тим, як надіслати звіт про помилку. Подумайте, чи є ваші кроки нормальною поведінкою користувача, чи виявлена вами помилка зацікавить наших клієнтів. Завжди думайте, чи не вплине ваша помилка на звичайний потік користувачів.
Давайте розглянемо приклади найпоширеніших помилок, які ми зібрали для вас.
Тестування електронної підписки за допомогою електронної пошти, до якої у вас немає доступу
Часто наші тестери хочуть довести, що потік підписки електронною поштою або реєстрації приймає недійсні електронні листи. Перевірити, чи приймає сервер недійсні електронні листи, цілком нормально і це одна з корисних дій для наших клієнтів, але перш ніж продовжити таку практику, переконайтеся, що ви розумієте різницю між недійсними та неіснуючими електронними листами. Можна сказати, що це одне й те саме, але це не так. Будь ласка, прочитайте цю статтю, щоб зрозуміти, що таке недійсні електронні листи.
З іншого боку, неіснуючі електронні листи представляють електронні листи, створені не вами (чи кимось іншим), і, отже, не існують у системі. Спроба перевірити неіснуючу електронну пошту, швидше за все, не спричинить жодної реакції з боку сервера, оскільки вона вважатиметься дійсною, якщо вона відповідає шаблону структури електронної пошти. Така поведінка очікувана, і це не вважається помилкою.
Рішення:
Якщо ви тестуєте комерційні електронні листи, ви ОБОВ’ЯЗКОВО використовуєте наявну скриньку вхідних повідомлень. Таким чином ми не перевірятимемо запити Gmail, Outlook або будь-якого іншого постачальника електронної пошти з недійсними запитами.
Якщо ви хочете перевірити валідацію, ви повинні використовувати електронні листи qa.team. Оскільки існують усі дійсні імена користувачів qa.team, тестувальники ніколи не надсилатимуть запит до папки вхідних повідомлень, що не підлягає видачі, тому вони лише тестуватимуть саму перевірку.
Для проміжних середовищ електронні адреси qa.team завжди слід використовувати для регулярної реєстрації (якщо інше не зазначено клієнтом).
Для перевірки недійсної електронної пошти скористайтеся прикладами, наведеними в статті, або створіть власну комбінацію, яка має той самий
Повідомлення про помилки, пов’язані з перевіркою браузера
Перевірка браузера представляє перевірку вхідних даних HTML, яку виконує браузер на основі атрибутів у елементі введення.
Ось приклад перевірки браузером HTML 5 введення електронної пошти:
<input type="email" id="email"
pattern=".+@test\.io" size="30" required>
Якщо ви бачите щось подібне, це означає, що реалізована перевірка браузера, а перевірка не виконується JavaScript.
Одним із найпоширеніших прикладів перевірки браузера є відображення червоної зигзагоподібної лінії під неправильно написаним словом у полі форми.
Повідомлення про такі помилки не входить до циклу тестування, який виконує Test IO, і такі помилки будуть відхилені.
Рішення:
Якщо вам цікаво, який тип перевірки вхідних даних реалізує клієнт для певного середовища (веб-сайту), клацніть правою кнопкою миші на сторінці, а потім виберіть Переглянути вихідний код сторінки. Якщо ви помітили код <input type="email"...>, це означає, що поле електронної пошти перевірено браузером і вам не слід повідомляти про помилку в тесті.
Тестування без увімкненого проксі-сервера, коли це вимагається в інструкціях тестування
Іноді наші тестувальники не уважно читають інструкції з тестування, через що їхні помилки відхиляються або навіть у найгіршому випадку отримують попередження від нашої команди відповідності. Однією з найпоширеніших помилок є те, що тестувальники не використовують проксі, коли це потрібно. Ми провели невелике дослідження, і ось що стало проблемою для тестувальників:
Під час повторюваних тестів тестувальники читають інструкції з тестування один раз, а коли приходить наступний тест від того самого клієнта для того самого продукту, тестувальники вважають, що стратегія тестування має бути однаковою, і що читання інструкцій було б марною тратою їх дорогоцінного часу. . Ось де вони роблять помилку. Однаковий заголовок тесту не означає, що доступ до тестового середовища відбувається тим самим шляхом.
Часто наші клієнти хочуть відокремити трафік, який створюють наші тестери, від трафіку реальних користувачів. У таких випадках ми використовуємо проксі. Інший випадок полягає в тому, щоб отримати доступ до проміжного середовища, яке заблоковано для будь-кого без належного доступу: увімкнено проксі. Якщо тестер не ввімкне проксі-сервер, проміжне середовище видасть помилку 403 або 1020. Повідомлення про такі помилки призведе до відхилення через недотримання інструкцій тестування.
Рішення:
Якщо ви приймаєте цикл тестування, у якому для доступу до середовища тестування потрібне використання проксі-сервера, ви повинні точно дотримуватись інструкцій тестування, інакше виявлені помилки не вважатимуться законними.
Оновлення вмісту та візуальних помилок до функціональних, щоб зробити їх у межах тесту
Іноді наші тестери без будь-якого наміру оновлюють усі помилки контенту та візуального стану до функціональних, оскільки вони не мають досвіду, щоб визначити, які помилки слід оновити до функціональних. В результаті отримують відмови. У багатьох випадках такі відхилення відбуваються через причини, пов’язані з межами сфери дії, що означає, що якість і рейтинг тестувальника сильно постраждають.
Рішення:
Зосередьтеся на вивченні різниці між контентними, візуальними та функціональними помилками. Зрозумійте, що якщо контент та візуальні помилки не перешкоджають функціонуванню продукту або існує інтуїтивно зрозумілий обхідний шлях, ви не повинні надсилати повідомлення про функціональну помилку.
Не оновлювати ОС пристрою до прийняття циклу бета-тестування
Ця практика добре підтверджена не лише нашими новачками, а й нашими досвідченими тестувальниками. Здебільшого, це не навмисно. Наші тестувальники беруть участь у багатьох тестах протягом тижня, тому іноді вони забувають зареєструватися для тестування бета-версій ОС.
Рішення:
Людині властиво помилятися, але переконайтеся, що ви завжди читаєте інструкції з тестування, оскільки вони містять важливу інформацію про запитаний пристрій і бета-версію ОС.
У випадках, коли потрібна бета-версія ОС, тестувати продукт слід не з офіційною збіркою, а з бета-версією.
Вибір неправильного пристрою у звіті про помилку
Іноді тестувальники хочуть бути найшвидшими у звітах про помилки. Роблячи це, вони іноді помилково обирають не той пристрій. Якщо вони не перейдуть у правильне середовище до того, як керівник групи перевірить їхній звіт про помилку, хороші помилки можуть бути відхилені.
Рішення:
Перш ніж натиснути «Надіслати помилку», переконайтеся, що ви вибрали правильні деталі помилки, як-от тип помилки, серйозність, пристрій і браузер. Якщо ви випадково вибрали неправильний пристрій або браузер, ви можете виправити це, якщо ніхто інший не повідомив про це правильно, і до того, як керівник групи перевірить ваш звіт про помилку.
Надсилання повідомлення в чаті циклу тестування для сповіщення керівників команд про те, що ви внесли зміни, запитані керівником команди у звіті про помилку
На ранній стадії тестування наші тестери отримують численні запити на інформацію, щоб покращити свої звіти про помилки. Протягом цього часу тестувальники можуть відчувати нетерпіння, щоб побачити, яким буде результат подання. Саме тоді тестувальники, здебільшого, потрапляють у пастку, надсилаючи кілька коментарів у звіті про помилку або навіть повідомлення в чат тестового циклу, щоб повідомити TL про внесені зміни. Здається знайомим, правда? Ми всі були там і вчилися на своїх помилках. Але ми хочемо, щоб ви були розумнішими й навчалися у нас.
Рішення:
Коли ви відповідаєте на інформаційний запит, надаючи всю необхідну інформацію, яку запитував керівник вашої групи, утримайтеся від надсилання кількох коментарів у звіті про помилку та повідомлень у чаті циклу тестування. Керівники команд отримують сповіщення про виконані інформаційні запити, і їм не потрібно нервувати чи хвилюватися. Усі помилки будуть розглянуті вчасно, оскільки наша система не дозволяє закривати будь-які тести зі звітами про помилки в стані «Непереглянуто».
Використання Google Translate для перекладу середовища тестування під час запису помилки
Однією з переваг сучасних технологій є те, що вам не потрібно знати всі мови світу, щоб перевірити продукт іноземною мовою. Під час тестування дозволено використовувати сторонній інструмент перекладу, як-от Google Translate, але переконайтеся, що виявлена вами помилка не спричинена використанням Google Translate. Іноді Перекладач Google порушує середовище, і наші тестувальники надсилають неіснуючі помилки. В інших випадках наші тестери повідомляють про помилку, яка існує, і вона не спричинена Google Translate, але вони забувають вимкнути Google Translate, коли записують помилку. Коли це станеться, помилка буде відхилена TL, оскільки вона не відповідає нашим стандартам.
Рішення:
Кожного разу, коли ви тестуєте середовище мовою, якою ви не володієте, використовуйте інструмент перекладу третьої сторони для легшого розуміння продукту, але вимкніть його безпосередньо перед тим, як почати запис екранної трансляції.
Відтворення помилки PASS у тесті
Така поведінка засвідчена в тестах, де нашим тестувальникам пропонується надіслати одну функціональну помилку під назвою "PASS", щоб довести, що робочий процес, описаний в інструкціях тестування, є успішним. Подання відтворень таких помилок заборонено, і такі подання будуть відхилені.
Рішення:
Якщо ви бачите "PASS" у заголовку звіту про помилку, будь ласка, не надсилайте відтворення.
Помилково припустіть, що фільтрування та сортування є схожими функціями
Зазвичай фільтрування та сортування представлені разом, оскільки вони допомагають користувачам працювати з великими наборами елементів (продукти, фільми, квитки…); однак їх реалізація сильно відрізняється. Функція фільтра зменшує колекцію елементів на основі певних критеріїв, таких як розмір, колір, бренд тощо. Функція сортування впорядковує набір даних за різними критеріями, як-от від низького до високого або від найновішого до найстарішого.
Фільтрування та сортування на мобільних і настільних пристроях
Розуміння цих відмінностей має вирішальне значення, оскільки помилки, виявлені в цих функціях, належать до різних типів. Наприклад, хоча проблеми з функціями сортування є функціональними помилками, більшість проблем із фільтрацією є помилками вмісту.
Рішення:
Найпростіший спосіб відрізнити ці дві функціональні можливості, дивлячись на тип і кількість опцій для функціональних можливостей. Функціональність буде відфільтрована, коли вона пропонує численні параметри, які описують фізичні характеристики предметів. Функціональність буде відсортовані, якщо наведених параметрів лише кілька і вони призначені для перегляду елементів, які відображаються певним чином.
Перелік найпоширеніших помилок не закінчується згаданими випадками. Щоб дізнатися більше про поширені помилки та кілька чудових порад, ми пропонуємо вам прослухати епізод нашого подкасту: