Як стати успішним тестувальником

Багато хто вважає, що тестування ПЗ – це пошук помилок. Іноді я кажу тестувальникам: «Не намагайся знайти якомога більше помилок, старайся пропустити якомога менше!», І мене не розуміють: а в чому різниця?

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


Що таке пошук помилок?

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

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

Що буде, якщо я зіткнуся з багом, який складно відтворити? ROI (Return on Investment) на його дослідження рахується в голові дуже швидко. Навіщо мені з ним возитися, якщо я за цей же час зможу завести 3 менш критичних, зате більш простих?

Які тести я проводитиму в першу чергу? Звісно, найбільш нестандартні. Ввести в поле логіну «Війну і мир», поділити на нуль, вставити в профіль фотографію у форматі .exe.

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

Саме так виглядає пошук помилок, що не має нічого спільного з тестуванням.


Що таке тестування?

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

Які області я буду тестувати в цьому випадку? Природно, я почну з найпріоритетніших для користувача. Навіть якщо вони стабільно і успішно працюють, я все одно буду перевіряти основні користувальницькі сценарії, щоб ні в якому разі не пропустити серйозних проблем.

Що буде, якщо я зіткнуся з труднощами? Наприклад, з дефектом, що складно відтворюється, або нерозумінням бізнес-процесу користувача, або нестачею вимог? Якщо це важливий функціонал, то я буду з’ясовувати «що не так», «як правильно». На створення дефекту в підсумку може піти чимало часу, і з точки зору баг / час результат ефективності тестування буде не дуже високий, проте у мене з’являться більш глибокі знання про продукт, архітектуру, користувачах.

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


Результати тестування і пошуку помилок

У випадку з пошуком помилок, в короткостроковій перспективі результати вище: багів заводиться більше і відразу.

Але в довгостроковій перспективі все не так райдужно:

  • через відсутність глибоких знань про продукт, поступово починає зростати % пропущених дефектів
  • команда розробки зайнята виправленням страшних-жахливих-немислимих багів, отриманих шляхом кліка на одну і ту ж кнопку 144 рази в IE в повний місяць
  • в реліз потрапляють деякі жахливо неприємні і очевидні для користувача баги
  • кількість помилок, що будуть знаходитися, в довгостроковій перспективі падає

Як перейти від пошуку помилок до тестування?

Щоб тестування було ефективним і корисним в довгостроковій перспективі, необхідно слідувати простим правилам і використовувати ключові інструменти тестування:

1. Аналіз продукту і документування тестів

Клікаючи на кнопки, можна завести багато багів – але не можна сказати, що було перевірено. Єдине рішення – документування тестів. Докладні тест-кейси, що пригнічують тестувальників і віднімають багато часу, бувають потрібні дуже рідко. А ось чек-листи з переліком «що потрібно перевірити» – необхідні.

Що вони дають:

  • Ви аналізуєте продукт, виписуєте основні фічі, дії, їх параметри. Таким чином істотно знижується ризик що-небудь забути.
  • Чек-листи – відмінне нагадування «тут треба заглибитися». Є якась невиразна фіча з недостатнім описом. Як її тестувати? У тестуванні без тестів найпростіше сказати «я повернуся до цього пізніше», і вже ніколи не повернутися. А з тестами – у вас висітиме тест, в якому незрозуміло як і що перевіряти, ви будете такі тести бачити і не забудете необхідність з’ясування.
  • Чек-листи можна і ПОТРІБНО узгоджувати. З розробниками, аналітиками. Вся команда включається в процес тестування, тестувальники дізнаються багато нового про продукт, колективний розум покращує якість тестування. І крім одноразового підвищення якості окремо взятого чек-листа, підвищується якість тестування в цілому: тестувальники починають більше розвиватися, ці знання з часом окупаються у вигляді більш результативного тестування.

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

2. Оцінка тестування

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

ЗАВЖДИ є що покращувати, і відсутність безперервного процесу вдосконалення – неминуче болото.

3. Обговорення цілей тестування з командою

Багато хто вважає, що у тестування є певні міфічні цілі. І що вони завжди однакові.

Як би не так!

У кожному проекті, компанії, команді цілі свої власні. Чи всі їх розуміють однаково? Проговорювали ви їх вголос?

Щоб приносити максимум користі, треба добре розуміти, в чому ця сама користь полягає. І не дивуйтеся, якщо думка РМ-ів і розробників не буде відповідати вашому розумінню. Треба не переконувати їх, а підлаштовуватися під поточні проектні цілі!

4. Розуміння користувачів і їх бізнес-процесів

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

  1. Як цей продукт використовується?
  2. Навіщо він взагалі потрібен, які проблеми вирішує?
  3. Яка середня кваліфікація у користувачів?
  4. В яких умовах працюють користувачі? На яких середовищах, обладнанні?

Не треба здогадок і додумок про «в середньому про галузі»! Тестувальники повинні ідеально знати своїх користувачів. Часто їм цю інформацію не надають аналітики. Схаменіться! Не знаючи користувача, тестувати продукт по-нормальному неможливо.

5. Технічна кваліфікація і розуміння архітектури

Для ілюстрації наведу баг, який недавно завели в баг-трекері:

Зайти на сайт тестованого продукту http: //****.ru в браузері Firefox
Ввести логін і пароль
Зайти з того ж комп’ютера в браузері Opera
Просить повторно ввести логін і пароль, автоматично НЕ логиниться.

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


Висновки

Дуже багато розробників не люблять тестувальників. І правильно роблять!

Проте хороших тестувальників люблять і цінують всі. Але тестувальників, а не клікерів і шукачів багів!

Вчіться дізнаватися, що не так, що не подобається іншим учасникам команди розробки. Обов’язково дослідіть пропущені помилки і робіть все для того, щоб більше їх не пропускати. Не женіться за заведенням багів – вашою мантрою повинні бути «щастя користувача», «якісний продукт» і «успішний проект», а не «завести якомога більше багів» – дуже часто ці 2 мети виявляються занадто далекі один від одного.