Все найкраще з методології Lean Startup, і як з цим жити тестувальникам


«Це повинно бути зроблено ще вчора», «Протестуйте як-небудь швиденько», «Час від початку розробки до викладення на продакшн має бути мінімальним, а якщо можливо — ще менше» — напевно, багатьом знайомі подібні цитати. І доки ми (тестувальники) — одне з останніх ланок в ланцюжку розробки, саме нам найчастіше доводиться балансувати між швидкістю виходу фіч і їх якістю.

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

Пара слів про себе: я тестувальник, мала досвід роботи в проектах різного масштабу, була єдиним тестувальником на проекті і працювала в командах, в яких використовувалися різні підходи та методології. З мого досвіду, працювати за Lean Startup — це круто, але тут є і підводні камені для тестування, про які непогано знати заздалегідь.

Для початку варто трохи розповісти про те, чим займається наша компанія. Туту.ру — сервіс онлайн-купівлі ж/д, авіа — та автобусних квитків, турів та інших речей, пов'язаних з подорожами. Один з наших проектів — "Тури" — ще в стадії активного розвитку, він дуже динамічний, функціональність швидко змінюється. Наші PO (продукт-оунеры) практикують Lean Startup і, зокрема, ми проводимо дуже багато експериментів.

Lean Startup, бажання менеджерів і реальність простого тестувальника
Ми, звичайно, не зовсім стартап, але в концепції Lean Startup є чимало цікавих речей, в тому числі і для нас. Що само собою передбачає Lean Startup?

  1. Мінімізацію непотрібних витрат і економію усіх можливих засобів.
  2. Залученість в процес створення продукту кожного співробітника. Іншими словами, про те, скільки коштує дане рішення; коли можна зробити швидше, а коли — додати більше функцій, ретельно перевірити результат — повинні думати не тільки менеджери, РВ або ще якісь міфічні люди, але й ми самі. Кожен з нас. Перед тестуванням варто запитати себе: а яка мета у фічі/проекту? Не тестувати заради процесу тестування, а тестувати у відповідності з якимись цілями, особливостями.
  3. Орієнтацію на користувача і отримання максимальної кількості інформації про клієнта в одиницю часу. Так, ми думаємо про наших користувачів і піклуємося про них. Намагаємося робити не тільки так, як зручно нам, інженерам, з технічної сторони, а саме їм — тим людям, які будуть користуватися нашим кінцевим продуктом.
І щоб зрозуміти, хто наші користувачі, чого вони хочуть, що їм подобається, а що ні — ми використовуємо експерименти з швидкими ітерацій.

Сенс всього цього в тому, щоб зробити мінімально-життєздатну функціональність, для перевірки якої-небудь гіпотези, а потім вже за результатами аналітики з'ясувати, чи треба розвивати цю гіпотезу (фічу) далі. Експериментуючи, ми знижуємо ризик розробки фічі, яка нікому не потрібна. При цьому нам потрібно максимально короткі ітерації: отримати потрібну інформацію як можна швидше, доопрацювати все у відповідності з отриманими даними — теж максимально швидко.

З точки зору менеджменту — все це, звичайно, дуже весело і здорово: швиденько пиляємо потрібну функціональність, швиденько перевіряємо гіпотези і варіанти, швиденько змінюємо функціональність за підсумками. Але що з усім цим робити нам — тестерам? Коли ми постійно чуємо: «Швидше, ще швидше! Ця фіча повинна була вийти на продакшн ще вчора!».

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

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

Для цього ми використовуємо наступні методології та інструменти:

  1. Бізнес-аналіз завдання
  2. Робота з ризиками
  3. Градації якості
  4. Чек-листи для розробників
  5. «Відкладене» написання документації
А тепер розглянемо кожен з цих пунктів детальніше:

Бізнес-аналіз завдання
Звичайно, не можна сказати, що ми (тестувальники) проводимо повноцінний бізнес-аналіз: зрештою, для цього існують спеціальні люди, так і завдання досить обширна. Але ми намагаємося застосувати це до наших реалій і нашої ситуації. Ми концентруємося на цілі проекту.
Наприклад, якщо ми знаємо, що кількість користувачів, які купують тури на двох дорослих і двох інфантів (дітей молодше 2 років) прагне до нуля — ми швидше за все не будемо перевіряти, який тип номера пропонує нам туроператор в даному випадку — тому що легше від цього нікому не стане. Але при цьому обов'язково перевіримо пошук і пропонований тип номера для 2 дорослих та однієї дитини — тому що така історія трапляється набагато частіше, тому що при пошуках з дітьми взагалі частенько спостерігаються помилки — можна сказати, що цей кейс є граничним.
Або, наприклад, тестуючи API підключення нового провайдера, ми не будемо звертати особливу увагу на ціни турів з перельотом бізнес-класом (головне, щоб вони не підставлялись за замовчуванням, замість економічного!), оскільки знаємо, що полетіти бізнес-класом, купуючи тур, побажав тільки один турист за весь час роботи нашого розділу.
Спокуса перевірити хитровыдуманные кейси для тестувальника завжди великий, але головне — не забувати про реальність.

Робота з ризиками
Мета забезпечення якості — зниження ризиків. Навіть якби ми володіли необмеженими ресурсами, повністю виключити всі ризики ми б не змогли.
Якщо ми обмежені часом, коштами або якимись іншими речами, то ми ділимо ризики на 2 групи:

  1. Допустимі
  2. Неприпустимі
До першої категорії відносяться речі, які можуть не працювати, працювати неправильно, ми можемо навіть не знати про те, що з ними щось не так (це найстрашніше!) — і для нас це нормально. Ми можемо прийняти ці ризики заради швидкості виходу завдань або іншої мети.

Що можна сюди віднести? Деякі додаткові сценарії, місця, куди за статистикою «майже ніхто не тикає» (0,1 % користувачів, наприклад), робота в популярних браузерах і т. д.

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

Ми управляємо допустимими ризиками та знижуємо неприпустимі.

Градації якості
Градації в цілому випливають з попереднього пункту і були зроблені для зручності як тестувальників, так і РО. Вони узгоджують правила гри між нами. У нас є 5 градацій якості, кожній з яких відповідає певна кількість речей, на які ми дивимося.



Наприклад, у 2 градації ми повинні переконатися в тому, що функціональність веде себе адекватно в одному, самому популярному в наших користувачів браузері, виконуються основні користувальницькі сценарії, працездатна основна бізнес-функція.

На рівні якості 5, у добавок до всього вищепереліченого, ми звертаємо увагу на:

  • додаткові користувальницькі сценарії та бізнес-функції;
  • UI;
  • відображення у всіх підтримуваних браузерах і на мобільних пристроях;
  • максимальний рівень автоматизації основних і додаткових користувальницьких сценаріїв;
  • тестабилити.
Це зручно ще й тим, що можна встановлювати різний і цілком певний рівень якості для різних проектів і навіть різних завдань.
Для завдань експериментів встановлюється рівень якості нижче, а якщо такі завдання вирішують розвивати далі, то і градація якості росте разом з ними. Наприклад, ми припускаємо, що користувачам буде цікаво і корисно, якщо ми запропонуємо їм ціни на сусідні дні і місяці, а також схожі країни (порівняно з поточним пошуком). Але технічно це завдання досить складна, тому виконуємо і запускаємо її, так би мовити, в демо-режимі, щоб подивитися, чи буде інтерес з боку наших користувачів. Припустимо, в такому вигляді завдання потрапляє до нас на тестування. І ми раптом з'ясовуємо, що якщо пошук виконується на двох осіб (наш дефолтний варіант, самий популярний), то ціни на сусідні місяці/в схожі країни адекватні і не брешуть. Але от якщо пошукати не на двох, а на трьох або одного — то тут «ой» — не все так райдужно. І на даному етапі ми, як тестувальники, порадившись з розробниками і дізнавшись, що правка досить трудомістка, приймаємо рішення випустити завдання як є.
Далі ми збираємо аналітику та розуміємо, що цим нашим новим блоком користується близько 40% відвідувачів. Тоді ми запускаємо наступну ітерацію завдання, і ось тут вже градація якості буде вище — ми зрозуміли, що функціональність треба розвивати і не можемо собі дозволити «неправильні ціни» при пошуку на відмінну від двох кількість людина.

Тут ще може виникнути питання про те, що є в даному випадку основним сценарієм, а що — додатковим.



Якщо повернутися до Lean, то все дуже сильно залежить від стадії проекту, на якій ми знаходимося.

На цьому малюнку зліва зображені стадії проекту з Lean Analytics, і так звані «гейти» (праворуч), через які необхідно пройти, щоб перейти на наступну стадію. Ось короткий опис цих стадій:

  • Empathy. Мета цієї стадії — поінформувати потенційних покупців про розробку продукту і ваших експериментах. Гейт в даному випадку — чітке визначення реальної, актуальною і не розв'язаною до цього моменту проблеми. Тепер, коли ви з цим визначилися, можна йти далі.
  • Stickiness. Тепер зробити що-то таке, таку фічу, яка змусить користувачів повертатися. Гейт — сформульована методика вирішення проблеми, за яку готові платити.
  • Virality. Максимизируем кількість користувачів (бажано без використання або з мінімальним використанням платних методів). Гейт — кількість користувачів, а також якість і затребуваність фіч зростає.
  • Revenue. Проект повинен приносити гроші, причому більше, ніж ви витрачаєте на нього. Гейт — ви знайшли і зайняли свою нішу на ринку.


Таким чином, щоб зрозуміти, які сценарії зараз вважати додатковими і основними, варто подумати на якій стадії зараз перебуває проект.
Наприклад, на стадії Stickiness для нас будуть важливі різні «фішечки» і відмінні риси, на стадії Virality не обійтися без SEO — і якщо ми знаємо які пріоритети у проекту на даний момент ми можемо більш ефективно підходити до процесу забезпечення якості і «наносити особливу користь» тільки там, де це дійсно потрібно.

Чек-листи для розробників (acceptance criteria).
Тут мова піде про підвищення швидкості виконання всього циклу роботи над завданням.
В ідеальному світі кожен член команди несе відповідальність за якість. У тестування не надходять сирі завдання. Тестувальники не знаходять критичних багів, т. к. розробники вже все врахували. Наш світ не ідеальний. Ми стикалися з тим, що завдання потрапляла до нас з очевидними багами. Але не буває очевидних речей. Такі ситуації були прозорі тільки для нас – тестувальників.

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

Ми знайшли такий спосіб: ми використовуємо так звані «чек-листи для розробників»(acceptance criteria).

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

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

Приклад уривка нашого чек-листа:

  1. Перейти на /hotel/3442/ (сторінка без параметрів пошуку)
  2. Там немає плашки «надіслати посилання на тури»

  3. Перейти на ХХХ (приклад посилання на сторінку готелю за параметрами)
  4. Плашка присутній
  5. Можна перейти на наступний крок при кліці на ціну пропозиції
  6. Присутні написи про можливість часткової оплати та про те, що входить в тур
  7. Навпроти них, під кнопками про ціни, розташована плашка з псевдоссылкой «Дізнатися, якщо ціна знизиться», в ній відсоток активний і червоніє при наведенні
  8. Клікнути на посилання «Показати ще N пропозицій»
  9. Нижче підписки, вже поза локалу в правій колонці знаходиться плашка з написом «Надіслати посилання на тури в цей готель по ел.поштою»
Ми використовуємо чек-листи більше року і вже змогли зробити деякі висновки. І тестувальники, і розробники кажуть, що чек-листи однозначно корисні і користуватися ними зручно. Так в чому ж, власне, плюси?

Чому це подобається тестувальникам?
  • менше сирих завдань;
  • тестувальники раніше включаються в процес роботи над завданням.
Коли методологія розробки гнучка, то на проекті, як правило, дуже мало документації і специфікацій. Якщо проект динамічний і РО постійно експериментують (як це відбувається у нас), то «попередня» документація не має особливого сенсу — звичайно, у нас є тільки юзер-сторі і зразкові варіанти рішення. Тому в даній ситуації етап «тестування вимог» як окрема одиниця просто відсутня. Але тестувальникам важливо брати участь у формуванні вимог і ми робимо це як раз на етапі створення чек-листів для розробників. Звичайно, існують ще й окремі зустрічі для обговорення завдань, обговорення макетів, але і цього буває недостатньо.

  • На тестування з чек-листами йде менше часу, ніж на тестування аналогічних без чек-листів.
  • Ми вчимося формулювати конкретно і чітко, виділено проблемні місця у продукті.
  • У нас є можливість подивитися на завдання з різних точок зору.
Часто буває так, що тестує завдання одна людина, а чек-лист до неї писав інший. У всіх нас трохи різні стилі, погляди, методика тестування. Коли вдається подивитися на задачу «свіжим» поглядом — це дуже здорово і корисно.

Чому це подобається розробникам?
  • чіткий перелік сценаріїв з конкретними даними, які треба перевірити;
  • попередній аналіз завдання;
  • розробники отримують статистику і зворотний зв'язок.
Ми враховуємо характер помилок, знайдених за чек-листів і можемо сказати, що, наприклад, хтось допускає помилки певного характеру: логіка, код і т. п. Коли люди знають, де вони помиляються, їм є до чого прагнути і легше виправляти свої помилки.

Що подобається всім нам: ми не кидаємо завдання від розробки до тестування по сто тисяч разів. Багато речей виправляються ще на етапі чек-листів. А ще ми стаємо все ближче до того ідеального світу, де всі все врахували і зробили з першого разу як треба. Може бути, коли-небудь.

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

До того ж далеко не всі завдання у наших спринтах «заслуговують» чек-листів. На плануванні ми прикидаємо, потрібен чек-лист у задачі чи ні. У підсумку маємо 6-7 чек-листів за спринт (в середньому ми робимо близько 30 завдань за спринт). Близько 67% чек-листів були пройдені успішно (розробники не знайшли багів за ним). У 35% завдань з чек-листами не було знайдено помилок при тестуванні.



«Відкладена» документація
Ми не ставимо собі за мету писати докладні тест-кейси на все нові фічі. І причина все та ж: завдання-експерименти. Ми не хочемо писати документацію, яка нікому не знадобиться. Краще описати функціональність, коли буде точно відомо, що її чекає подальший розвиток. Ми пишемо кейси без зайвої деталізації, щоб їх було простіше підтримувати. Крім того, намагаємося кілька разів подумати перед тим, як написати кейс, щоб уникнути знову ж непотрібних втрат часу.

Всі перераховані вище інструменти в наших реаліях правда працюють – ми перевіряли.

Вони допомагають нам підтримувати баланс між якістю і швидкістю.

За мотивами мого виступу на SQA Days-19

Відео виступу можна подивитися тут:


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.