Багато хто вважає, що тестування ПЗ – це пошук помилок. Іноді я кажу тестувальникам: «Не намагайся знайти якомога більше помилок, старайся пропустити якомога менше!», І мене не розуміють: а в чому різниця?
А різниця величезна! У цій статті я хочу розповісти, в чому вона полягає, і які інструменти необхідно використовувати для справжнього корисного тестування.
Що таке пошук помилок?
Я тестую продукт. Моє завдання – завести якомога більше багів. Воно й логічно! Заводити баги тестувальнику завжди приємно, це видимий вимірний результат роботи, І чим їх більше, тим більше мене цінують як тестувальника.
Які області я буду тестувати в такому випадку? В першу чергу, найнестабільніші. Найчастіше вони нестабільні тому, що менш пріоритетні, але це неважливо, значно важливіше кількість багів.
Що буде, якщо я зіткнуся з багом, який складно відтворити? ROI (Return on Investment) на його дослідження рахується в голові дуже швидко. Навіщо мені з ним возитися, якщо я за цей же час зможу завести 3 менш критичних, зате більш простих?
Які тести я проводитиму в першу чергу? Звісно, найбільш нестандартні. Ввести в поле логіну «Війну і мир», поділити на нуль, вставити в профіль фотографію у форматі .exe.
Іноді на співбесідах тестувальники у відповідь на прохання «протеструйте калькулятор» перераховують цікаві та слушні тести, але в числі перших тридцяти немає тесту «перевірити складання» та інші базові операції.
Саме так виглядає пошук помилок, що не має нічого спільного з тестуванням.
Що таке тестування?
Я тестую продукт. Моє завдання – пропустити якомога менше пріоритетних для користувача багів. Чим менше багів пропущено, чим менше невдоволення клієнтом виражено – тим вище я оцінюю ефективність своєї роботи.
Які області я буду тестувати в цьому випадку? Природно, я почну з найпріоритетніших для користувача. Навіть якщо вони стабільно і успішно працюють, я все одно буду перевіряти основні користувальницькі сценарії, щоб ні в якому разі не пропустити серйозних проблем.
Що буде, якщо я зіткнуся з труднощами? Наприклад, з дефектом, що складно відтворюється, або нерозумінням бізнес-процесу користувача, або нестачею вимог? Якщо це важливий функціонал, то я буду з’ясовувати «що не так», «як правильно». На створення дефекту в підсумку може піти чимало часу, і з точки зору баг / час результат ефективності тестування буде не дуже високий, проте у мене з’являться більш глибокі знання про продукт, архітектуру, користувачах.
Які тести я буду проводити в першу чергу? Звичайно, найбільш стандартні. Виконання найосновнішого сценарію в найосновніших умовах щоб переконатися, що найважливіший функціонал працює. І тільки після цього я перейду до менш стандартних сценаріїв.
Результати тестування і пошуку помилок
У випадку з пошуком помилок, в короткостроковій перспективі результати вище: багів заводиться більше і відразу.
Але в довгостроковій перспективі все не так райдужно:
- через відсутність глибоких знань про продукт, поступово починає зростати % пропущених дефектів
- команда розробки зайнята виправленням страшних-жахливих-немислимих багів, отриманих шляхом кліка на одну і ту ж кнопку 144 рази в IE в повний місяць
- в реліз потрапляють деякі жахливо неприємні і очевидні для користувача баги
- кількість помилок, що будуть знаходитися, в довгостроковій перспективі падає
Як перейти від пошуку помилок до тестування?
Щоб тестування було ефективним і корисним в довгостроковій перспективі, необхідно слідувати простим правилам і використовувати ключові інструменти тестування:
1. Аналіз продукту і документування тестів
Клікаючи на кнопки, можна завести багато багів – але не можна сказати, що було перевірено. Єдине рішення – документування тестів. Докладні тест-кейси, що пригнічують тестувальників і віднімають багато часу, бувають потрібні дуже рідко. А ось чек-листи з переліком «що потрібно перевірити» – необхідні.
Що вони дають:
- Ви аналізуєте продукт, виписуєте основні фічі, дії, їх параметри. Таким чином істотно знижується ризик що-небудь забути.
- Чек-листи – відмінне нагадування «тут треба заглибитися». Є якась невиразна фіча з недостатнім описом. Як її тестувати? У тестуванні без тестів найпростіше сказати «я повернуся до цього пізніше», і вже ніколи не повернутися. А з тестами – у вас висітиме тест, в якому незрозуміло як і що перевіряти, ви будете такі тести бачити і не забудете необхідність з’ясування.
- Чек-листи можна і ПОТРІБНО узгоджувати. З розробниками, аналітиками. Вся команда включається в процес тестування, тестувальники дізнаються багато нового про продукт, колективний розум покращує якість тестування. І крім одноразового підвищення якості окремо взятого чек-листа, підвищується якість тестування в цілому: тестувальники починають більше розвиватися, ці знання з часом окупаються у вигляді більш результативного тестування.
Запорука успіху у веденні тестів – створення карти, по якій ви будете йти. Мета – покрити весь продукт. Тільки, будь ласка, не треба відмазок про жахливу ресурсоємність – можна покрити проекти з мільйонами рядків коду менше ніж за місяць-півтора. І в процесі написання таких тестів піднімалися несподівані питання і спливали критичні помилки, які незважаючи на наявність горе-тестерів бовталися в продукті роками.
2. Оцінка тестування
Щоб не бути сліпими кошенятами, необхідно оцінювати ефективність тестування. Аналізувати припущення помилки і причини їх пропуску. Покриття функціоналу та коду тестами. Рівень задоволення користувачів, через анкети і збір зворотного зв’язку. Якість заведення помилок, опитуючи розробників.
ЗАВЖДИ є що покращувати, і відсутність безперервного процесу вдосконалення – неминуче болото.
3. Обговорення цілей тестування з командою
Багато хто вважає, що у тестування є певні міфічні цілі. І що вони завжди однакові.
Як би не так!
У кожному проекті, компанії, команді цілі свої власні. Чи всі їх розуміють однаково? Проговорювали ви їх вголос?
Щоб приносити максимум користі, треба добре розуміти, в чому ця сама користь полягає. І не дивуйтеся, якщо думка РМ-ів і розробників не буде відповідати вашому розумінню. Треба не переконувати їх, а підлаштовуватися під поточні проектні цілі!
4. Розуміння користувачів і їх бізнес-процесів
Залишається загадкою, як це можливо, але тим не менше це факт: найчастіше тестувальники перевіряють продукт, нічого не знаючи про користувача.
- Як цей продукт використовується?
- Навіщо він взагалі потрібен, які проблеми вирішує?
- Яка середня кваліфікація у користувачів?
- В яких умовах працюють користувачі? На яких середовищах, обладнанні?
Не треба здогадок і додумок про «в середньому про галузі»! Тестувальники повинні ідеально знати своїх користувачів. Часто їм цю інформацію не надають аналітики. Схаменіться! Не знаючи користувача, тестувати продукт по-нормальному неможливо.
5. Технічна кваліфікація і розуміння архітектури
Для ілюстрації наведу баг, який недавно завели в баг-трекері:
Зайти на сайт тестованого продукту http: //****.ru в браузері Firefox
Ввести логін і пароль
Зайти з того ж комп’ютера в браузері Opera
Просить повторно ввести логін і пароль, автоматично НЕ логинится.
Такі баги не просто неприйнятні, вони ганьблять тестувальників і діскредитують цю галузь в цілому! Щоб заводити дефекти правильно, необхідно розуміти платформу, на якій написаний тестований продукт. Якщо ми говоримо про веб-тестування, то можна хоча б вказати в баг-репорті код помилки, що повертається сервером, подивитися подробиці файрбагом, надати докладну інформацію і заощадити розробці масу часу!
Висновки
Дуже багато розробників не люблять тестувальників. І правильно роблять!
Проте хороших тестувальників люблять і цінують всі. Але тестувальників, а не клікерів і шукачів багів!
Вчіться дізнаватися, що не так, що не подобається іншим учасникам команди розробки. Обов’язково дослідіть пропущені помилки і робіть все для того, щоб більше їх не пропускати. Не женіться за заведенням багів – вашою мантрою повинні бути «щастя користувача», «якісний продукт» і «успішний проект», а не «завести якомога більше багів» – дуже часто ці 2 мети виявляються занадто далекі один від одного.