Запровадження
Багато проектів, з якими я працював, люди не налаштовували під себе TestRail і обходилися стандартними налаштуваннями. Тому я спробую описати приклад індивідуальних налаштувань, які можуть допомогти Вам підвищити ефективність своєї роботи. Наприклад візьмемо проект розробки мобільного додатка.
Невеликий дисклеймер. У даній статті немає опису базового функціоналу TestRail (на це є багато гайдів) і барвистих, що продають виразів, що описують чому потрібно вибрати саме цього вендора для створення репозиторію з тестами.
План-обґрунтування (що буде реалізовано)
Загальні вимоги
Кейс має змогти пройти абсолютно будь-яка людина
Кейси повинні зберігати актуальність якнайдовше
Кейси повинні максимально ретельно покривати функціонал мобільного додатку тією мірою, якою це не суперечить першим двом пунктам.
Поділ на TestCase та TestScenario
Швидке формування TestRun різних типів
Дим
Регрес
Impact тестування та ін.
Оптимізація підтримки кейсів
Відмова від «мертвих» захардшкірених скріншотів та перехід на «movable data»
Вимога
Для редагування полів Вам знадобиться адміністраторський доступ
Вибір типу проекту
Можна вибрати три типи проекту:
Ми виберемо тип за замовчуванням. У ньому будуть доступні одночасно всі кейси. Ми будемо користуватися розумною фільтрацією та динамічно керувати всіма кейсами відразу.
Додавання полів для перегляду списку тест кейсів
Додамо поле для відображення priority тест кейсів:
Також можна додати інші поля.
Налаштування полів та тегів тест кейсу
Відкриваємо меню налаштування:
Нам будуть потрібні такі поля:
Поле "Summary" (шапка тест кейсу)
Це поле вже існує, ми тільки систематизуємо його використання. Будемо розділяти кейси на TestCase та TestScenario. Для кращого читання великого списку кейсів краще заздалегідь домовиться за регламентом написання summary.
TestScenario:
Приклад: TestScenario — Основний сценарій використання мобільної програми
TestCase:
Приклад: MainScreen - Розділ авторизації - Введення логіну
Разом ми бачимо в сумному кейсі класичне розуміння: “що, де, коли”. Також візуально ми розділяємо верхньорівневі тестові сценарії та низькорівневі тест кейси у найбільш підходящому для автоматизації вигляді.
Тег "StartScreen" (екран з якого починається TestScenario, також багато тест кейси можуть зачіпати сусідні екрани)
Для чого може знадобитися: ми видалятимемо з тексту текст кейсів типові кроки, що приводять користувача на екран поточного тесту кейсу. (Типові кроки для створення певної тестової ситуації) Всі типові кроки для всіх тест кейсів будуть прописані в одному файлі. Про нього докладніше напишу окремо.
Створюємо нове поле:
Заповнюємо компоненти нового поля:
У цьому випадку ми створюємо поле вибору зі списку значень. Вводимо значення цього поля:
Зверніть увагу, що id значень починаються не з одиниці і не підряд. Чому так зроблено? Справа в тому, що якщо у нас будуть записані тесткейси із введеним id,
і після цього нам потрібно створити третій екран між двома існуючими,
то нам доведеться переписати id, і оскільки до нього вже прив'язані теги існуючих текстів кейсів, то вони просто віддалятимуться. Це буде дуже неприємно.
Тег «Screen» (найменування екрана, що стосується TestCase)
Для чого може знадобитися: один із якорів для імпакту тестування. Наприклад, розробники зробили нову круту фічу. Нам потрібно її протестувати, але для цього потрібно зрозуміти, що саме ця фіча могла торкнутися. За умовчанням ми можемо відштовхуватися від парадигми, що різні екрани (Activity) програми мають різні класи і отже складають різні компоненти програми. Звісно ж у разі потрібен індивідуальний підхід.
Приклад: home_screen, MapScreen, PayScreen і т.д.
Поле «MovableData» (посилання на проксі БД із змінними тестовими даними)
Далі ми намагатимемося вирішити проблему підтримки актуальності даних у тесткейсах:
Посилання на актуальні макети (це набагато краще, ніж робити мертві скріншоти)
Типові кроки до екрану із тестовою ситуацією
SQL запити
Посилання на зовнішні дані та інші дані
Замість прописування тестових даних усередині кожного тест-кейс ми створимо один зовнішній файл, і на всіх тест-кейсах зробимо посилання на нього. При оновленні цих даних нам не доведеться перебирати всі тести кейси і змінювати їх, а можна буде змінити ці дані тільки в одному місці. Якщо хтось непідготовлений відкриє тест кейс, він побачить у тілі тест кейсу посилання на файл і підказку, що потрібно в нього йти за тестовими даними.
Всі ці дані ми запакуємо в один зовнішній файл, який буде доступний всім бажаючим на проекті. Наприклад, можна використовувати Google Sheet або Excel і настроїти всередині файлу пошук. Чому саме ці вендори? Справа в тому, що ми відштовхуємося від парадигми, що відкрити та пройти тест кейс має змогти будь-яка людина в команді без необхідності попередньо встановлювати будь-які тулзи.
Для Google Sheet можна використовувати запити SQL. Приклад:
=query(DATA!A1:M1146;"
SELECT C,D
WHERE
C contains '"&SEARCH!A2&"'")Для перевершувати можна налаштувати зручні макроси миттєвого пошуку. (фільтрації) Приклад .
Власне, ідея не нова і описана в першій книжці тестувальника “Тестування dot com”. (Автор Савін Роман) Ми тільки-но інтегруємо в TestRail запропоновані Романом Савіним методики. Для цього створимо поле з посиланням на створений файл:
заповнюємо дефолтне значення посилання, щоб у кожному новому тест-кесі вже посилання було:
Якщо розташування зовнішнього файлу зміниться (ми передбачаємо будь-який форс мажор) то можна зручно у всіх тест кейсах відразу змінити одне або кілька полів:
Поле “Descriptions” (опис чи ідея тест кейсу, типові інструкції)
Для чого може знадобитися: У текстове поле ми помістимо короткий опис тест кейсу і типові інструкції.
Приклад: Всі тестові дані (актуальні макети, використання тулів та інші дані) з даного тесту кейсу позначені посиланнями {…} і знаходяться у файлі MovableData. Посилання на MovableData у відповідному полі зверху.
Тег «Component» (компонент мобільного додатку)
Навіщо може знадобитися: для імпакт тестування. Якщо мобільний додаток можна розділити на компоненти (які якнайменше один одного афектят) то зміни в одному компоненті буде достатньо (з якимись ризиками) перевірити в рамках цього ж компонента, і буде менше підстав для проведення загальних регресів всього і вся. Якщо є інформація, що один компонент може афектити інший, складається матриця імпакт тестування.
Приклад компонентів: GooglePay, Order, Users, Map, Authorization і т.д.
Тег «TAG» (Інші теги для фільтрації)
Тегування тест кейсу мітки для довільної фільтрації.
Дуже корисно для:
Швидке складання TestRun для різних типових завдань: smoke, регрес і т.д.
чи будуть тести автоматизовані чи вже автоматизовані
будь-які інші теги
Приклад: Smoke, Automated, WhiteLabel, ForDelete і т.д.
Налаштовуємо порядок відображення полів у тест кейсі
Ми створили багато нових полів, настав час розташувати їх у зручному порядку:
Створення TestRun
Тепер ми створимо новий test run з актуальними кейсами для проведення smoke тестування у три кліки:
Інші корисні поради
Якщо в TestRail кілька проектів, то не забувайте створювати нові поля тільки під Ваш проект або колеги з сусідніх команд дуже здивуються появі нових незвичайних полів. Можливі локальні непритомності.
2. Кейси з великою кількістю полів простіше копіювати з аналогічної групи типу, ніж створювати нові:
3. Можна використовувати облікові записи разом. Наприклад: одна адміністраторська, кілька користувацьких.
Висновок
Наведені вище приклади були впроваджені на кілька проектів і показали свою ефективність. Сподіваюся вони допоможуть покращити Ваше розуміння даної туловища та допоможуть створювати ефективні та зручні “тестосховища”. Буду дуже вдячний, якщо Ви у коментарях опишите Ваш досвід використання TestRail та корисні поради.
Посилання:
книга:
Щиро дякую за увагу!
Джерело: habr.com
