Навіщо та чому потрібна тестова документація Лабораторія Якості
Давним давно…
Аргументом для припинення написання тестової документації та специфікацій стало те, що на виході збитків було більше, ніж прибутку. Специфікація та різна документація себе не виправдовували, тому що вимагати високих цін за невеликі мобільні програми компанія не могла. Та й які можуть бути чек-листи на нову функціональність, коли:
— Ми перестали робити in-app покупку тем! - Ad-hoc збірка вже зібралася! За годину треба викласти! - Ще ми критичні баги виправили і ось цю "штуковину" засунули в код. — Проженіть якийсь смок, раптом щось зламалося! - і т. д.
У результаті доводилося без документації думати про те, що саме і які частини могло вплинути. У терміновому порядку потрібно було проводити повноцінне дослідницьке тестування за півгодини! При цьому потрібно було знайти критичні для користувачів баги. Півгодини — це максимум часу, тому що виявлені проблеми ще потрібно виправляти і перевіряти ще раз. Згодом за такої організації роботи починали виникати проблеми:
—Слухайте, а хтось пам'ятає, що тут було? Хтось знає, як воно має працювати? — Не пам'ятаю вже. Потрібно запитати у розробників… — Хм… Гадаєш, я пам'ятаю, що я робив три місяці тому? У мене 5 додатків! Я вже не пам'ятаю, де і що я колись писав… (7 час…) — Та не знаю. Ну хай так буде. — У мене твій баг не повторюється. А-а-а… ти е-ету кнопку натискаєш при виході. А я завжди ту натискаю... — Слухай, а ти не пам'ятаєш, як ми перевіряли такі передплати? І ось це яким має бути? Здається, воно не повинно бути таким… Не пам'ятаю.
І запитати нема в кого. Фахівців, які займалися б документацією, немає. Тестувальниками часто проводилося повне тестування програми, що забирало багато часу - цілі тижні, а іноді й місяці. І на запитання: “Коли ви закінчите перевіряти?”, була відповідь: “Критичні баги лезуууут!” Не було чіткого розуміння, скільки часу потрібно для тестування програми. А час, як відомо, – гроші. У результаті виходило щось, що починало жити своїм життям.
Як, що й за якими законами там відбувалося, не було зрозуміло нікому. Особливо новим розробникам, яким передавали подальшу розробку:
Колеги я витратив три дні на вивчення коду, тому що розробників цієї програми вже немає, і нічого не зрозуміло. Коментарів у коді мало. Незрозуміло, навіщо який милиця. Якщо почну писати, то зламаю те, що працює. Мені легше це все переписати наново. Давайте напишемо нормально.
Так працює безліч компаній. І далеко не всі одержують хороші результати.
Хоча вище описано і неточне оповідання, оскільки минуло багато років і щось перефразовано, але сенс той самий. Є компанії, які таки пишуть тестову документацію і активно нею користуються. Зазвичай цевеликі компанії, що розробляють функціональні масштабні системи. А є компанії, від якості та наявності документації яких можуть залежати життя людей (наприклад компанія розробляє автопілот для літака). Автопілот можна розробляти роками, в результаті один раз випустивши його у світ. Це дуже дорогий процес. Якщо автопілот буде з багами, то втрати будуть величезними.
Як зробити так, щоб продукт вийшов якісним і добре продається? Необхідно розпочати з документації.
У якому вигляді і навіщо потрібна тестова документація?
Існують різні види документації, що використовується під час тестування. Кожна з них відіграє роль у досягненні спільної мети - створення успішного продукту. Нижче розглянемо найпоширеніші види документації та причини їх використання.
Робоча проектна документація, що використовується тестувальниками
ТЗ (технічне завдання) - дозволяє донести суть предмета розробки до співробітників компанії. Допомагає зрозуміти, якою саме функціональністю повинен мати продукт, що розробляється (іноді із зазначенням використовуваних технологій і методів).
Чому потрібно?
Якщо ТЗ буде у загальному доступі, то співробітники, які погано перетинаються з командою розробки, зможуть його подивитися. Можливо, що при тестуванні буде виявлено якусь проблему, про яку повідомить тестувальник (наприклад, програма не виконує те, для чого була створена).
Новим співробітникам не потрібно буде розповідати про зміст програми та методи її реалізації. Можна буде швидко ввести в курс справи будь-якої людини.
ТЗ допомагає співробітникам зрозуміти програму краще. Нерозуміння продукту, що розробляється, призводить до помилок.
При тестуванні не виникатиме спробперевіряти зайве. У першу чергу, перевірку буде піддано те, що обов'язково має працювати по ТЗ.
ТЗ дає можливість зрозуміти суть продукту, що розробляється співробітникам, які будуть представляти готовий варіант реалізації публічної аудиторії.
ЧТЗ (приватне технічне завдання) - створюється на основі ТЗ. Зазвичай містить повний опис конкретної частини продукту, що розробляється і ВІ (варіанти використання, сценарії використання предмета розробки користувачами, макети частини предмета розробки, що розробляється, його логіку і суть).
Чому потрібно?
Допомагає розробникам реалізувати продукт, що розробляється точно так, як замислювалося. Допомагає зрозуміти логіку та правила оформлення.
Допомагає новим співробітникам розібратися у великих і масштабних проектах, оскільки деякі системи потрібні тижня вивчення. Маючи під рукою ЧТЗ, співробітник легко зможе знайти в ньому необхідну інформацію, відразу приступивши до тестування. Не потрібно буде залучати інших співробітників, які знають продукт, тим самим відволікаючи їх від роботи. Очевидна економія часу!
Дає можливість приблизно оцінити трудовитрати на розробку та тестування ще до початку робіт.
Допомагає тестувальникам створити ЧЛ та тест-кейси до початку робіт та тестування.
ЧТЗ та ТЗ можна відобразити:
у текстовому вигляді з картинками
у вигляді графічного шаблону-таблиці
у вигляді інтелект-карт, UML або подібного алгоритму
Проектна документація, що готується тестувальниками
ЧЛ (чек-лист) - список того, що потрібно перевірити.
Чому потрібно?
Допомагає планувати терміни закінчення робіт у майбутньому та теперішньому, т.к. в СПД можна вказати,скільки часу необхідно для перевірки та скільки було витрачено.
Зберігає історію пройдених тестів. Можна буде легко згадати, які саме тести проходили з помилками, і перевіряти ще раз саме їх.
ЧЛ з результатами наочно показує будь-якому співробітнику компанії поточний стан продукту, що розробляється. Допомагає визначити його рівень готовності.
Допомагає пам'ятати, що вже було перевірено, а що ні.
Допомагає не забути, які тести необхідно виконати в першу чергу, які в другу, які в третю тощо. Це породжує впевненість, що за певний запланований час найважливіші тести будуть проведені, а результати з них отримані.
Чек-листи можна записати:
у вигляді таблиць (зручно в Google Sheets)
у вигляді інтелект-карт (зручно у XMind)
у вигляді списку перевірок у спеціально призначеній системі (зручно у Sitechco)
у вигляді списку у текстовому документі, який звичний.
ТК (тест-кейс) - створюється на основі ЧТЗ (якщо воно є) тест-аналітиками та тестувальниками.
Чому потрібно?
Спільно з ПЛ може зберігати історію тестування та відображати, що саме та як тестувалося. Можна переконатися, що та чи інша функціональність обов'язково була або буде перевірена та торкнутася при тестуванні.
Допомагає швидко включити у роботу нових співробітників. Співробітнику не обов'язково тижнями вивчати предмет розробки, йому буде достатньо відкрити збережений ТК і пройти його кроками так само, як проходив інший досвідчений фахівець, який раніше працював у компанії.
Допомагає побачити як предмет розробки (програма, сайт тощо) має виглядати. З наявними скріншотами екранів, якщо вони є, можна буде не забути про те,що “вона та” кнопка має бути сірою, а не червоною.
Тест-кейси можна відобразити:
у вигляді таблиці з текстовими даними
у спеціальному сервісі для ведення тест-кейсів (наприклад, TestLink).
Звіт про тестування – письмовий або медійний звіт про виконану роботу та її результат.
Чому потрібно?
Наочно відображає, який результат виконаних робіт отримано.
Історично фіксує інформацію. До неї завжди можна буде повернутися та побачити, що саме було виконано і що саме отримали у результаті.
Повідомляє про результати всіх, кому важливо знати про них. Наприклад, для співробітників відділу підтримки повідомляється про вихід нової версії програми, що розробляється, а також про найкритичніші проблеми. Можна буде заздалегідь підготуватися до скарг, що виникають.
Допомагає приймати рішення щодо подальших дій (наприклад, чи варто випускати версію програми у поточному стані).
Приклад звіту письмово:
Як визначити, яку саме документацію необхідно впровадити у проект?
Нижче наведемо приклади того, коли та яку документацію та кошти можна використовувати як необхідний мінімум.
На проекті до 15 осіб (проекти низької складності):
технічне завдання (запобігає неправильному розумінню завдання розробниками, тому що документації немає);
чек-листи (легко підтримувати, не забирають багато часу);
звіти у вигляді короткого листа або відписки у спеціальному сервісі ведення проектів із зазначенням критичних багів для випуску.
На проекті від 15 до 50 осіб (проекти середньої складності):
база знань (наприклад, у Wiki);
звіти у вигляді листа з доданим пройденим СПДвказівкою критичних багів.
Великий проект - від 50 чоловік і більше (проекти високої складності):
приватне технічне завдання;
база знань (наприклад, у Wiki);
звіти у прийнятому у компанії вигляді (зазвичай, у вигляді листа з докладними графіками та доданими файлами);
інше (залежить від типу, цілей та потреб компанії).
Що з цього вибрати - вирішувати самим співробітникам, тому що саме вони займатимуться розробкою та зможуть зрозуміти, що їм потрібніше. Все вищезгадане — лише зразкове уявлення та рекомендації.
Що робити, якщо написання документації займає багато часу?
