Зошит тестування — головний інструмент тестувальника

💡 Усі статті, обговорення, новини про тестування — в одному місці. Приєднуйтесь до QA спільноти!

Гадаю, що багато хто, або навіть швидше за все всі, хто читає цю статтю, навчалися в інституті. І знають, що перш ніж писати наукову статтю чи дипломну роботу на якусь тему, спочатку потрібно вивчити доступну літературу, щоб отримати відповідь на два запитання.

Перше, можливо, хтось вже провів таку роботу і повторно винаходити велосипед не потрібно. І друге питання, а чи взагалі вивчення цього питання має якийсь сенс? Спробуємо відповісти на обидва питання. Чи існують статті на таку тему і відповідь ні. Ніхто ще не писав про це і це виглядає дивно. Якщо ви спробуєте знайти в інтернеті зошит тестувальника, то знайдете збірки шкільних зошитів для тестування. Або брошури з текстами тестів з якогось предмета. Найбільш наполегливі можуть знайти Зошит Смерті, в який тестувальники записують своїх улюблених розробників, але не більше. Відповідь на друге запитання я приведу наприкінці статті.

У заголовок я виніс твердження, що зошит тестування — це головний інструмент тестувальника. Заява із претензією. Як зараз кажуть, клікбейтне. Відразу хочеться дізнатися, що цей автор собі дозволяє) Тому давайте розглянемо для початку, а які інструменти тестування ми можемо виділити? Щоб порівнювати кругле з круглим, а не з квадратним або тим більше із зеленим.

Перш ніж розпочати домовимося, що під інструментами тестування зазвичай розуміють конкретні програми. Їх існує безліч і я їх трохи укрупнив до спільностей за завданнями, які вони виконують, щоб не розбирати кожну окремо. Для простоти я виділив три класи інструментів.

• Інструменти для фіксації баг репортів
• Інструменти для створення Чек листів
• Інструменти планування

Як тепер виділити головний із них

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

Баг репорти та баг трекінгова система

Основа основ, наріжний камінь тестування, найважливіший тестовий артефакт та інше.

Чи обов’язкова для тестування система баг трекінгу? Виходячи з мого досвіду — ні. Шостий принцип тестування свідчить — тестування залежить від контексту. Простою мовою якщо для виконання завдання не потрібна баг трекінгова система, то від неї можна відмовитися.

Я довгий час працював у компаніях, що займаються веб розробкою на основі WordPress. Проекти там невеликі та не надто складні. Але головне, вони одноразові. Виконали проект. Передали замовнику і більше з ним не взаємодіємо. Список багів там вівся просто в чаті з розробником або в загальному документі. Пов’язано це було з тим, що цінності у багах, після їх виправлення, не було. Тому не було причин зберігати їх та аналізувати. У такій ситуації баг трекінгова система буде надмірною.

Оскільки кожна подібна система, крім вартості впровадження, має ще вартість адміністрування. На те, щоб оформити баг, витрачається час, який оплачується роботодавцем. І якщо заробіток компанії не пов’язаний з кількістю багів у баг трекінгової системи на пряму, то це втрачені гроші. Гаразд, це були маленькі проекти в яких не дотримувалися формальних процедур. Але як щодо нормального серйозного проекту, який триває роками і вимагає зусиль десятків людей?

Такий досвід у мене теж є, я працював у компанії, яка входить у топ три у світі за доходами на App Store, ті хто там зараз працює легко її впізнають. Коли я туди влаштувався працювати, вони навіть баг репортів не писали. Замість них у них були повідомлення на кшталт: «У середу я підключила айпад до комп’ютера та виявила краш репорт. Не знаю, коли він виник, але прикріплюю до повідомлення».

Як з’ясувалося, краш репорт формувався при кожному переходу пристрою в сліп мод. З того часу баг репорти з’явилися, а от баг трекінгова система — ні. Замість неї використовується таск трекінгова. Ці два приклади переконують мене, що незважаючи на важливість, як баг репортів так і баг трекінгових систем, якщо дуже потрібно, то можна працювати без них.

Системи для створення та моніторингу чек листів

Другим класом інструментів я помістив системи для створення та моніторингу чек листів, тест кейсів та всього такого.

Їх дуже багато: від Test rail до банальних гугл таблиць. Вони допомагають структурувати процес тестування. Привести його до впорядкованого процесу, що легко піддається плануванню. У великих компаніях це один із основних інструментів. Але в них є й низка вроджених вад. Вони страшенно схильні до ефекту пестициду.

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

Це ефект пестициду. Ви витравили баги на тих маршрутах тестування, які ви проводили. І тут ви потрапляєте у наступну пастку. Помилка про відсутність багів. Чек лист пройдений, багів не знайдено, отже, все добре?

Ні, не добре. Тут як у приказці Ти бачиш ховраха? І я не бачу, а він є. Якщо ви не знайшли баг, це не означає, що його нема. Це означає, що ви його не знайшли. Виконуючи тестування за одним і тим же сценаріями ми ризикуємо пропустити баги за крок від тих місць де ми дивимося. Ну і як би цього було мало, є ще одна проблема з чек листами. Величезна вартість адміністрування. Мало того, що чек лист потрібно розробити, та його ще й увесь час потрібно підтримувати в актуальному стані. Додавати нові тест кейси на основі виявлених багів. Адаптувати перевірку під новий функціонал. Таким чином, весь парк чек листів повинен аналізуватися і переписуватися буквально після кожного релізу. Таку систему можна підтримувати у великих компаніях, де для адміністрування виділяються спеціальні люди, які займаються лише написанням чек листів та підтримкою їх у актуальному стані. Це має сенс в компаніях, де релізи рідкісні, а самі чек листи є юридичною документацією. Наприклад у компаніях, що розробляють медичне ПЗ.

Я якось співбесідався до компанії, яка розробляє апарати УЗД. Я запитав у них, як часто у них йдуть релізи. Вони відповіли двічі на рік. Як багато багів ви бачите за один реліз? Вони кажуть, звичайно п’ять. Уявіть собі один реліз на півроку і всього п’ять багів. Причина такої неквапливості в тому, що є державний орган, який допускає медичні апарати до продажу. Йому слід надати правильно задокументовані перевірки. Тобто пройдені чек листи. І у разі їх відсутності чи помилок ліцензія не видається і весь цикл потрібно розпочинати з початку. Якщо пропускаються баги, то вони призводять до багатомільйонних юридичних позовів, особливо якщо це призводить до загибелі людей, як це трапляється з апаратами МРТ. Співбесідуючись до такої специфічної компанії, я звичайно не втримався і запитав. У апаратів УЗД є насадки для досліджень різних порожнин у тілі людини, як ви їх тестуєте? Співрозмовники трохи нервово хихикнули і запевнили, що всі частини УЗД апарату докладно тестуються)

Так, ось повертаючись до чек листів, у Харкові була одна ігрова компанія, яка дуже любила чек листи. На всі випадки життя писали їх. І так само вона страшенно не любила підтримувати ці чек листи у актуальному стані. Що призводило до ситуації коли потрібно було слідувати не так букві чек листа, як його духу. Доходило до того, що ситуація прямо протилежна описаному в чек листі вважалася правильною, оскільки чек лист застарів. Виникає питання, навіщо такий чек лист потрібен?

Закінчуючи цей довгий та важливий розділ, скажімо, що організувати процес тестування без чек листів можливо. Тобто, за нашою системою, це не головний інструмент тестування.

Таск менеджери

Третій клас інструментів, це інструменти планування, а простіше таск менеджери. Будь-які канбан дошки, Trello, Redmine, Asana та інші.

Ось тут будь-який проджект менеджер вам скаже, що це і є суть будь-якого проекту. Немає тасків, немає і результатів. Без системи планування нічого вдіяти неможливо. Вона і є головною складовою без якої не можна працювати. І я навіть не стану сперечатися. І справді в роботі проджект менеджера це головний інструмент. А ось у тестуванні ні.

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

Наведу приклад такої пріоритезації завдань. Перший пріоритет у завдань, від яких можна втратити гроші. Зазвичай вони пов’язані із безпекою. Ідея тут у тому, що той, хто не програє, одного разу виграє, суто теоретично. Тому потрібно захиститися від програшів, у нашому випадку від втрати грошей. Другий пріоритет у завдань внаслідок реалізації яких можна заробити більше грошей. Наприклад, нову гру зробити або нову фічу. Третій пріоритет у завдань, які роблять життя користувачів кращим або зручнішим. Це може стати конкурентною перевагою та дати можливість виділитися серед інших компаній. При інших рівних користувачі воліють користуватися більш зручними та красивими рішеннями. На останньому місці у мене завдання, які роблять адміністрування проекту простіше для самої компанії. Ідея в тому, що якось і раніше справлялися, значить і зараз впораємося без термінової імплементації фічі. Я тут не заперечую, що підвищення зручності та прозорості адміністрування економить час, а отже й гроші команди. Але все ж таки поміщаю це у своїй системі пріоритетів на останнє місце. Таким чином, інструменти планування виявляються не обов’язковими для тестування.

І ось тут постає питання: а що ж тоді взагалі обов’язкове?

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

Можливо, існують і електронні аналоги, але особисто для мене важливо записувати все руками та на папері. Тут принцип як у школі, де дітей все ще вчать писати руками, а не друкувати на клавіатурі.

Справа в тому, що в момент запису на папері ви запам’ятовує не тільки те, що ви пишете, але і як це пишется і де це пишется. Виходить, що до тієї самої інформації ведуть різні спогади. Ти можеш не пам’ятати про що писав, але пам’ятаєш, коли писав і можеш повернутися.

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

Думаю багатьом з вас знайома ситуація коли весь день щось робив, а до кінця робочого дня не просунувся в основних завданнях. Зошит дуже допомагає у цих випадках зрозуміти, куди пішов час, проаналізувати та спланувати новий день. Якщо додавати дати на сторінках, виходить повний робочий лог. Просто погортавши який можна зрозуміти, що робилося минулого тижня або навіть минулого місяця.

Під час прибирання в шафках мені якось потрапив до рук робочий зошит, який я використовував дві або три роботи тому. Я просто її погортав і згадав, як проекти так і ситуації, які на них виникали. Так працює людська пам’ять. Якийсь маяк запускає цілий каскад спогадів. Це дуже важливо у сучасних навантажених проектах, коли намагаєшся нічого не забути та не проґавити. Найпростіше це записати собі в зошит і може навіть виділити кольором. Воно не дасть себе забути.

Хтось може зараз подумати — це все очевидно, навіщо про це стільки говорити? Це як писати інструкцію з надягання светра. Усі і так справляються. І на свій захист хочу навести два аргументи.

По-перше якість досягається увагою до дрібниць. І ігнорування такого простого, доступного, але водночас потужного інструменту тестування просто недбале.

А по-друге, хочу навести приклад із військової справи. На американських авіаносцях часів Другої світової війни стояли дошки, що зображали палубу, на якій кольоровими фігурками відзначали літаки. Переміщаючи фігурки відповідно до того, як літаки рухаються палубами. Неофіційна назва цього інструменту Дошка Уїджі. Цей примітивний і невибагливий пристрій допоміг планувати операції за рахунок наочності. Що надавало перевагу в часі підготовки вильотів, що зрештою призвело до більшої ефективності авіаносної авіації США порівняно з Японською, де такої дошки не було. Така дошка зберігається на американських авіаносцях і зараз. Незважаючи на існування електронного аналога. Вона наочніша і може працювати без електрики. Доводячи, що найпростіші рішення є найнадійнішими.

На цьому я хочу завершити свою розповідь, сподіваюся вона видається вам корисною або хоча б смішною.