Також, рекомендуємо наших випускників партнерам на відкриті вакансії та під їхній запит. Весь курс побудований на великій кількості практики, де ви зможете відпрацювати всі необхідні навички та з легкістю знайдете “свою” вакансію. Обсяг, цілі, формат документації, тестові процеси, репортинг тощо. Баг-репорти — https://deveducation.com/ це, в сутності, тест-кейс, тобто вже пройдений сценарій на практиці, але з фактичним результатом, що не збігається з очікуваним. Вам буде корисно ознайомитись з інформацією нижче, якщо у вас на проєкті виникали або виникають дилеми на кшталт «Писати чи не писати», а якщо писати, то що і скільки.
Заголовок баг-репорту повинен бути інформативним або ж, хочеться використати англіцизм, — self-descriptive. Перераховані кроки повинні дозволяти точно відтворити проблему, а фактичний результат вичерпно описувати поточну поведінку функціонала. Також бажано, щоб на скриншоті був не лише UI, а й фрагмент консолі/ нетворку — це відчутно спростить життя дев-команді.
Спочатку QA створює чек-лист в TestRail чи Google-таблицях, а потім розширює його до детальних тест-кейсів. Викреслюючи пункти списку, команда (або й один тестувальник) може краще розуміти поточний стан виконаної роботи та якість продукту. Коли працюєте над проєктом за чек-листом, можете значно зменшити потребу повторної перевірки за тими ж кейсам. Перш ніж братися за створення тест-дизайну, визначте цілі та умови на проєкті. Це дійсно найважливіше, що ви маєте знати для роботи над тестовою документацією.
Баг-репорт
Але це не через те, що всі лапочки і котики, а просто є державний регулятор. Який дасть по шапці, якщо не було багатьох процесів… Розуміння того, що таке тестування ПЗ та яке місце воно займає у життєвому циклі розробки програмного забезпечення.
А от для фічі треба прописати флоу перевірки достатньої глибини. Тоді після проходження такого сценарію ви зможете гарантувати справність фічі. На фазі стабілізації знадобляться регресійне та смоук-тестування. Залежно від цього змінюються і типи документації. Наприклад, на стабілізації достатньо тестувати за вимогами.
Хоч це і внутрішня документація, її користувачі — теж люди, які прагнуть працювати зі зрозумілою інформацією. Єдиний підхід до оформлення, поєднаний із турботою про потенційного читача, спрощує роботу всієї команди. Технічна документація – зазвичай містить повний опис логіки конкретної частини продукту, що розробляється і варіанти, сценарії використання предмета розробки користувачами.
Сама по собі матриця стає об’ємною, якщо потрібно перевірити безліч варіацій. Окремо слід згадати тест-дизайн — опис видів документації на проєкті. Сюди відносяться тест-кейси, чек-листи, типи тестів на кожному етапі тощо. Цей матеріал допоможе вам правильно підійти до створення тестової документації та написати її справді грамотно й швидко.
Якщо баг критичний — не забудьте одразу поділитись ним в чаті з припискою «АЛЯЯЯЯРМ! Отримайте практичний досвід у тестуванні різних програм. Ознайомтеся з класифікацією всіх видів та рівнів тестування. Дізнаєтеся як працюють клієнт-серверні програми та в чому специфіка тестування таких програм.
Тож розгляньмо, як варто оформлювати кожен із цих документів так, що вони були надійними, структурованими та, що не менш важливо, user-friendly. Матриця відповідності вимог дозволяє візуалізувати покриття продукту тестами та відшукати «дірки» в нашому check coverage. Напрочуд корисно додавати до документа скриншоти, тестові файли або інші документи, що допоможуть програмістам розв’язати проблему. Ми допомагаємо у складанні вашого резюме, не знецінюючи ваш минулий досвід.
Але загальний «маршрут» задає все ж таки той, хто має найбільше досвіду і надивленності. Лише так фахівець зрозуміє, що треба писати в документації та навіщо. У проєктах можуть відрізнятися команди, бюджети, пріоритети. В одному випадку треба гарантувати самим собі, що в продукті немає помилок. В іншому — перестрахуватися перед клієнтом, що все перевірено згідно плану. Вона може використовуватися для прямого відстеження (тобто від вимог до дизайну або кодування) або навпаки (тобто від кодування до вимог).
Той же тест-лід звик працювати за однією схемою, а хтось із досвідчених колег може запропонувати альтернативний підхід. Якщо позиція останнього аргументована і має сенс у конкретному випадку, тест-ліду слід прислухатись до його ідеї. Для виявлення цих аспектів необхідно мати різний бекграунд.
Матриця коректно виконує свою роль лише за умови її постійної актуалізації. Інакше вона не тільки стає марною, а й може заплутувати тестувальників. Traceability matrix — подвійна таблиця, що перевіряє відповідність функціональних вимог продукту (functional requirements) і підготовленим тест-кейсам. На перетині відповідних рядка та стовпця ставиться відмітка, яка позначає, що ця вимога покривається тест-кейсом. Бували ситуації, коли некоректне розуміння тест-кейсів призводило до пропущених багів і, як наслідок, невдоволення клієнтів.
Найбільш Обговорювані Статті
Регресійні ж тести на фазі стабілізації працюють одразу за двома напрямками. З одного боку, структуровані тести типу E2E user move та інших допомагають швидко підібрати набір тестів для конкретного етапу розробки чи релізу. З іншого, регресійні тести мають показувати, що саме перевірялось. Привіт, вибираєте медичний проєкт і будете мати того добра стільки, що «сраки горітимуть».
Також я визначаю, який рівень якості ми гарантуємо. Це насамперед вимагає Product Owner, і цей вид документації може створюватися разом із проєктним менеджером. Головна мета — пояснити, що відбуватиметься у QA-команді під час спринтів і релізів та затвердити перелік тасків. Тестовий Сценарій — повідомляє про те, яку ділянку і у якому порядку в програмі буде перевірено.
У довгостроковій перспективі це заощадить купу часу та підвищить якість вашої роботи. Зазвичай підготовкою тест-плану займався найдосвідченіший на проєкті QA, який відсилав його на погодження QA-менеджеру. В нас був уже готовий шаблон, який корегували та доповнювали відповідно до нового проєкту. Та з переходом на Scrum потреба в схожому документі — через скорочення паперової роботи — значно знизилася. Не можна спочатку описати, коли з’являється дефект, і тільки наприкінці вказати сам дефект.
Вимоги (Software necessities specification) – це документ основа основ, того що буде реалізовано. У загальному вимоги описують перелік побажань замовника, і те що повинен робити продукт. Для розуміння проблеми вашим колегам вистачить текстового опису. Пропишіть виконані вами кроки, інвайромент, Expected та Actual.
Чек-лісти варіан записати у Google Sheets, але як по мені значно наглядніше і зручніше у вигляді інтелектуальної карти. Припустимо, ви маєте сет тест-кейсів, які використовуються для регресії перед релізом. І проходити не всі кейси, а з тисячі вибираєте умовно чотири-п’ять. Також у вас з’являється новий функціонал, який може не згадуватись у тестах. І хоча ключова особливість фічі не змінилася, але з моменту появи тестової документації вона виросла у a hundred разів.
Важливим є не просто досвід в ІТ, а досвід участі у різних по своїй суті й масштабу проєктах. Я провів багато часу на своєму першому проєкті з певним підходом до написання тестової документації. Все нове, незнайоме видавалося мені позбавленим логіки.
В інших ситуаціях досвідченим QA достатньо тест-кейсів і шаблону баг-репорту, який заповнюється в залежності від ситуації. Аналогічний підхід діє і під час створення баг-репортів. Це дозволить уникнути розбіжностей і систематизує роботу команди. Баг-репорт має містити правильну єдину термінологію, що описує елементи призначеного для користувача інтерфейсу і події, що спричиняють баг. У будь-якому разі треба врахувати роль команди (аутстаф чи аутсорс) і хто є контактною особою. Якщо Product Owner має лише загальне уявлення про тестування, детальна розповідь про стратегію та документацію недоречна.
- Це дозволить уникнути розбіжностей і систематизує роботу команди.
- Таке відчуття, що хтось готувався до співбесіди))…з приводу чеклістів додам, що це необов’язково мають бути прям сценарії.
- Що стосується написання документації — розпочинає лід.
- Можна обійтися короткими сценаріями, які вартуватимуть багато менше часу та сил.
- Якщо у вас є базовий список перевірок для функціонального тестування, на їх основі можна створити регресійний тест-кейс на фічу з чотирма сторі.
Також раджу додати скріншот або зробити на екрані відеозахоплення івенту. Зазвичай, його складають під конкретний великий реліз, до якого треба залучити спеціальні процедури, що не завжди використовуються в повсякденній рутині. Визначити загальні принципи, яких слід дотримуватися під час процесу тестування. Я ось знаю проекти в яких не було жодного із перелічених пунктів.
Якщо це комнада досвідчених розробників, достатньо підготувати матрицю покриття і позначити таски в Jira. Що таке тестова документація, які бувають види документів та інша базова теорія — це все ви легко знайдете в мануалах для QA в інтернеті чи дізнаєтесь на курсах. У цій статті я зосереджуся на дещо вищому рівні. Хорошою практикою вважається створювати тест-кейси паралельно з розробкою, щоб як тільки задача мігрує в ‘Ready For Test’, QA зміг братися до роботи.