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

Робота тестувальника - це не лише пошук багів які допустили розробники коли створювали програмне забезпечення.. Одними з дещо бюрократичних обов’язків тестувальника: ведення документації.
Тестування програмного забезпечення - один із найголовніших етапів SDLC (SOFTWARE DEVELOPMENT LIFECYCLE - життєвий цикл програмного забезпечення).

— В чому полягає робота тестувальника?
— Які види документації має вести тестувальник?
— Як правильно оформлювати документи та загалом їх призначення.

Сьогодні про це та навіть більше ;)

Робота тестувальника - це не лише пошук багів які допустили розробники коли створювали програмне забезпечення.. Одними з дещо бюрократичних обов’язків тестувальника: ведення документації.

Насправді, документи - це не проста “формальність”. Це дуже важлива частина розробки проектів та правильного функціонування поважаючої себе ІТ-компанії. Від грамотного ведення документації тестувальників залежать: терміни розробки, відстеження готовності продукту до запуску, аналіз помилок та того, що необхідно зробити, пріоритетність функціоналу, відповідальність членів команди за свої блоки завдань, звітність перед продакт-овнером, покращення роботи тощо.

Хочеш стати Тестувальником?

Види документів та для чого вони призначені

Формальні (тобто ті, що є частиною проекту. Вони передаються замовнику і всі члени команди мають доступ до перегляду, коментування, або редагування):

  • ТЗ (технічне завдання) - це документ, що встановлює призначення, показники якості, візуалізацію, технічні, економічні та інші спеціальні вимоги до продукту. Найчастіше з ТЗ приходить в компанію замовник, або продакт-овнер. Але саме тестувальник може його верифікувати та адаптувати документ. Йдеться про те, що ТЗ дає чітке розуміння що потрібно розробити, для чого та який функціонал і дизайн має мати.

  • Вимоги - документ, що описує весь функціонал продукту, деталі, економічні показники. Тобто це взірець, відповідно до якого має бути розроблений продукт. Щоб тестувальники могли перевірити продукт/функціонал згідно вимог, хтось має ці вимоги написати. QA - саме ці спеціалісти, що створюють ці вимоги. Тобто вимоги - превентивні методи запобігання багів в тому чи іншому середовищі.

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

  • Баг-репорти - це, в сутності, тест-кейс, тобто вже пройдений сценарій на практиці, але з фактичним результатом, що не збігається з очікуваним. Цим документом тестувальник повідомляє розробнику, що в створюваній системі є помилка і ПЗ працює неправильно.
Неформальні (ті, що призначені для внутрішнього користування команди, або окремого члену команди. Можуть бути необов’язковими):

  • Чек-листи - перелік завдань на визначений термін, що потребує відмітки про виконання.

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

  • Матриці тресабіліті - це таблиця, що показує покриття тестами вимог. Тобто який функціонал вже перевірили, а який ще потребує перевірки. Також цей документ візуалізує відсоткове співвідношення протестованості між частинами ПЗ.
Триває набір на комплексний курс тестування ПЗ →

Вагаєтесь? Спробуйте
безкоштовний курс основи тестування.

Залишайте заявку на курси тестування та прокачайте свої скіли!

Забронюй місце в групі та отримай вступні уроки безкоштовно!

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