Основи тестування ПЗ. Лекція 4 - фундаментальний процес тестування
ฝัง
- เผยแพร่เมื่อ 18 ก.ย. 2017
- Привіт відвідувачам та підписникам каналу "Світ тестування". Вашій увазі пропонується чергова лекція з безкоштовного онлайн-курсу "Основи тестування програмного забезпечення".
В лекції розкрито поняття фундаментального процесу тестування:
1:46 планування (planning)
5:00 контроль (control)
6:16 аналіз (analysis)
8:07 впровадження (implementation)
11:09 виконання (execution)
12:47 оцінка вихідних критеріїв та звітування (evaluation exit criteria and reporting)
18:25 активності по закриттю тестування (test closure activities)
++++++++++++++++++
Підписка на канал: / @testing-world
++++++++++++++++++
#тестуванняПЗ
#онлайнкурстестування
#фундаментальнийпроцестестування
#безкоштовнийкурстестування
#якстатитестувальником
#IT
#QA
![[Full Episode] MasterChef Junior Thailand มาสเตอร์เชฟ จูเนียร์ ประเทศไทย Season 3 Episode 3](http://i.ytimg.com/vi/A1XXYbV048k/mqdefault.jpg)
Тема не складна, але ... місцями важко орієнтуватись по таблиці і зрозуміти про яке завдання етапу йдеться мова
Привіт. Розкажи будь-ласка як саме може допомогти архівоване testware команді підтримки (що вони зазвичай там шукають)? Дякую.
Привіт! Testware складається з артефактів, отриманих в процесі планування, дизайну (розробки) та виконання тест-кейсів. А саме це документація (вимоги, тест-кейси), скрипти для автомейшн тестування, вхідні дані (test data), очікувані результати, різноманітні конфігураційні файли, тестове середовище, бази даних та інші айтеми, які використані/розроблені при тестуванні.
Maintenance - тестування після релізу/деплою. Уявімо, що команда maintenance не займалася розробкою і отримала просто софт від іншого вендора без testware. Тобто немає ніякої документації, вимог і т.д., лише програма. В такому випадку буде важко і довго розібратися в програмі.
Якщо влетить якийсь баг чи імпрувмент від клієнта, робота над ним займе тривалий час.
Якщо є документація, вимоги, тест-кейси і т.д., це зробити значно легше.
Наприклад, якщо юзер хоче якийсь імпрувмент, і команда підтримки має матрицю відслідковуваності (див. тут: th-cam.com/video/7DQiX8gDge8/w-d-xo.html ), апдейтяться юзер-вимоги і зразу відно, які тест-кейси треба оновити. Чи наприклад юзер хоче змінити якісь вимоги на валідацію якогось поля. Не маючи вихідних вимог команда підтримки не буде знати, як працює це поле зараз, що саме треба міняти і чи це взагалі можливо.
Якщо влітає якийсь баг, і в команди підтримки є тест-кейси на перевірку цієї функціональності, можна їх проранити на регрешн.
Дякую за повну відповідь. Доречі, підправ будь-ласка бите посилання (зайва дужка його зломила).
Дякую, пофіксив