Як розробити тест-дизайн — від паніки до готового набору артефактів
Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на DOU | QA!
Вітання. Я — Валентина Кузенко, QA інженерка в «Таксер». Останні декілька місяців наша команда готує низку оновлень, одна частина яких покликана зробити продукт цікавим для потенційних клієнтів, а друга — зручнішим для тих, хто вже з нами, та (дякуємо!) ділиться з нашою службою підтримки побажаннями щодо вдосконалення сервісу.
Багато з цих та інших ідей, а також потенційно (сподіваємося, що кілер) фіч вже реалізовано. З технічної точки зору це, зокрема, нові, масивні елементи в архітектурі проєкту та його бізнес-логіці.
Щодо безпосередньо моїх задач — це потреба переглянути загальні підходи до тестування з поправкою на нові фактори: доповнити, та відкоригувати наявну документацію.
Саме ця потреба привела мене до дослідження, яким, як я вважаю, зовсім не зайве поділитися з QA-спільнотою. Адже, щоб документація не просто стояла і метрики красиві були, в ідеалі б на кожному етапі уявляти, що це і навіщо — як інструмент, і як концепція. І як розбивати це все на етапи... Та й взагалі. Сподіваюсь, зацікавила ;)
So, let’s dive into it.
Перш ніж щось змінювати за покликом серця, пішла на простори мережі згадувати теорію, та почала із золотих стандартів. Враження: IEEE 829 — окремий всесвіт. Час та простір в ньому, підозрюю, прямують до безмежності, що заворожує. Проте, видається надмірним для локальнішого практичного застосування.
Далі були вищі, з точки зору рівня абстракції, багатоВеликихЛітер (ISTQB). Там (pov) дуже детально та глибоко показано наскільки непосильно та загрозливо можна описати мої повсякденні справи. Читати це — корисний досвід, але застосовувати його на практиці я, певно, буду іншим разом.
Розчарувавшись в авторитетах абревіатур, я пішла до людей: слухати лекції, подкасти та виступи на конференціях.
Тут колобку пощастило більше — моє одне, але надто широке «Як?» трансформувалося в багато, але цілком однозначних питань, відповіді на які, здається, дійсно здатні допомогти обрати: в який саме спосіб вичерпно та доцільно структурувати й формулювати цю «базу» (знання, цілі, підходи... артефакти✨). Адже мета ледачої розумної (науково доведено) трудової одиниці — не стільки зробити справу, скільки не брати в процесі зайвого тяжкого ні до голови, ні до рук.
Отже, нижче наведу мої результати пошуку, інколи узагальнені, «доповнені та розширені», для більшої універсальності матеріалу, які допоможуть розробити тест-дизайн.
Мета (чому для IT не підходить кодекс самурая)
Перефразовуючи широко відомих у вузьких колах класиків:
Довільний проєкт ґрунтується на ідеї, яка або змінює щось для когось на краще, або допоможе робити щось звичне набагато ефективніше та швидше.
Задача продукту загалом — цю ідею втілити.
Відповідь на запитання «Якою є така задача для вашого продукту?» визначає, якими властивостями повинен володіти продукт, що достатньо якісно виконує цю задачу та викликає в цільової аудиторії, по можливості, нестримне прагнення («обґрунтована необхідність» теж підійде) цей продукт придбати.
Відповідь на запитання: «Продукт в якому стані та вигляді можливо вважати тим, що задачу виконав?» направляє в бік того, з яким світлим образом, власне, має збігатися результат, про який головний по QA гордо скаже: «До релізу готово!».
Підхід актуальний як для першого, так і для всіх подальших релізів.
Отже, ставлячи собі за мету організувати підготовку до безпосереднього тестування продукту, пам’ятаймо, заради чого все починалося, оскільки протестований продукт, що відповідає новим вимогам, повинен дорівнювати реалізації тієї самої розвиненої ідеї.
Відхилитися від цієї концепції значно легше, ніж здається. Хоча питання це ближче до філософії, проте саме команда QA зобов’язана, після достатньої перевірки того, куди нові ідеї та сформовані на їх основі вимоги привели продукт на практиці, давати свою остаточну оцінку — чи стоїть вище вказаний знак рівності.
Інколи проєкт достатньо маленький. Для нього справді володіння навичками користування необхідними у вашому випадку інструментами тестування, складання чеклістів та написання зрозумілих вашому розробнику баг-репортів — цілком достатньо. Усереднена теорія ідеалізує картинку того, які компоненти документації є необхідними на проєкті (привіт, IEEE). Переважно, меджик «воно працює — його купують» відбувається і без чіткого їй слідування.
Чітко сформулювати те, що цілком успішно й так живе в голові, необхідне та доцільне у двох випадках:
- коли ступінь комплексності інформації зростає до рівня, що тримати в голові ще реально, а от гарантувати, що при застосуванні нікого не забули, вже важко;
- коли з’являється потреба поділитися тим, що є в одній голові, з іншою головою, бажано без смс, реєстрації та надмірного витрачання особистого часу.
Тест-дизайн — засіб, що організовує та структурує роботу, а не робить її ефективнішою автоматом. Ваша ефективність або достатня без нього, сформульованого та (не обов’язково) чітко виписаного, або ні.
Якщо таки ні, йдемо далі.
Контекст (Середовище розробки. Ні, не те)
Розібравшись з тим, що ми тут робимо, визначивши мірило того, а чи добре ми це робимо, сформулювавши та узгодивши ідеологічне «Нахіба?», час перейти до оцінки «А в яких умовах (з якими ризиками) це все відбувається».
Це перелік загальних питань, який повністю скласти навряд реально. Проте для кожного конкретного проєкту їх скінченність більш ймовірна. Якщо я тут забула щось надважливе, сподіваюсь, прочитаю у ваших коментарях. Тож, без претензії на вичерпність, задаю вектор:
- Який загалом бюджет «свята»?
- Компанія продуктова чи аутсорс?
- Команда на 100, 500 чи 100500 людей?
- Як організовані процеси в команді?
- Які передбачаються терміни виконання в спринтах?
- Як часто та якого масштабу оновлення є типовими для проєкту?
- Яка загальна плинність кадрів?
- Яка ціна помилки (в найгіршому випадку — клієнт образиться та піде до конкурентів/ втратить гроші/ посадить всіх до останнього trainee в буцигарню/ помре, можливо в муках)?
- Якими є пріоритети цільової аудиторії?
- Якого рівня спеціалістами частіше поповнюється команда?
- Чи є тенденція до розширення та наскільки?
- Чи зобов’язаний продукт відповідати якимсь жорстким міжнародним стандартам?
- ...
Особливим пунктом до них додається питання «Хто це буде тестувати і кому вони будуть звітувати?». Воно найбільше впливає на необхідність деталізувати описи тест-кейсів, вибір та застосування метрик, доцільність будувати матрицю відповідності вимог та ін..
Команда тестування — справжнє організоване угруповання з внутрішньою ієрархією, мідлами, своїм менеджером й аніматорами на свята✨ / трійко джунів з перманентно круглими очима, одне з яких в одного з яких періодично смикається / я сам собі собою в себе на проєкті керую, себе, за можливості, контролюю, і мій психолог каже, що це дуже добре...
- Хто ці люди?
- Яка в них кваліфікація?
- Як в них розподілені обов’язки?
- В який спосіб ця команда комунікує з менеджерами та розробниками?
Знаючи, для яких умов створюється дизайн, є більше шансів, що створене буде ефективно використовуватись, а не стояти під скельцем в рамочці з табличкою «Розбити у крайньому разі».
Що в чорному ящику? (Ось тут про те)
Цей блок, на відміну від попереднього, стосується роботи самого продукту.
Тут питання про архітектуру, організацію коду, ролі розробників. Якщо перші були про умови праці учасників процесу, ці — про те, якими засобами та в який спосіб в продукті досягається виконання заявлених до нього вимог. Чим з детальнішим розумінням продукту ми підходимо до організації процесу тестування, тим простіше нам обирати оптимальні стратегії й техніки тест-дизайну, та формувати вичерпне покриття вимог.
Міфологія давнього IT стверджує, що тестери — нижча каста, і до розробника їм просто так підійти не варіант. До того ж програмування — процес конструктивний, створення, тоді як тестування — деструктивні спроби зламати створене і зовсім інший підхід та мотивація. Про що ж таким двом базовим антагоністам балакати?
На щастя, галузь та ролі в ній отримують дедалі зріліше сприйняття. Сукупний досвід довів, що зробити вашу спільну скриньку якомога білішою — справа корисна для всієї команди.
Запитувати, чим зумовлене прийняття тих чи інших рішень, яким засобом досягається той чи інший результат, безцінне «а що буде, якщо?» — традиція, що потенційно економить час та вирішує проблеми.
Тестуючи «білу скриньку» (попередньо отримавши достатню для цього експертизу, необхідну для розробника дизайну) ми не тільки скорочуємо час пошуку бага в коді для девелопера, а й усуваємо ту, популярну колись, ідею антагонізму — говоримо однією мовою.
Від протилежного: обрана без глибокого розуміння організації продукту комбінація технік тест-дизайну майже 100% буде заскладною та надмірною. Не треба так.
Підходи та інструменти. Як обрати
Комбінація технік, яку потрібно сформувати, повинна базово відповідати двом характеристикам:
- Створений набір тестів виявляє найсерйозніші дефекти продукту.
- Кількість тестів, що виявляють критичні дефекти зведена до достатнього мінімуму.
З патетичних істин, що стають такими, як тільки їх озвучити, але чомусь часто ігноруються, якщо цього не зробити: краще довго писати тести, які швидко виконуються, ніж швидко написати ті, що... (оберіть самі, яким обсценним словом завершити це речення, щоб зробити аксіому веселішою).
Щоб створити гідний набір тестів, нам потрібно:
- розбити цілісну систему на складові;
- зібрати та проаналізувати увесь перелік вимог до продукту;
- розставити пріоритети (не дивитися в бік мінорних дефектів, доки не розібралися з критичними);
- сформулювати зібрані ввідні дані, унеможлививши їх хибне трактування;
- взяти і застосувати обрані техніки.
Довільна техніка вирізняється тим, що дає певні однозначні відповіді на частину питань з переліку нижче, на решту питань команда відповідатиме самостійно, що забезпечить процесу гнучкість.
Вони:
- Що ми тестуємо?
- Наскільки ретельно?
- Хто тестує?
- Якого типу дефекти ми очікуємо виявити?
- В який спосіб?
- Який принцип оцінки результатів?
- Якою є мета тесту?
Обираємо, виходячи з пріоритетів. Наприклад:
- Прагнемо щільного тестового покриття? Дивимося в бік функціонального тестування та розбиття на класи еквівалентності.
- Важливо чиїми саме очима дивитися на продукт? Бета та користувацьке — до ваших послуг.
- Хочете зрозуміти, як продукт виконує свою бізнес-задачу? Організовуйте UAT (user acceptance testing).
Залежно від мети (хоча, скоріше, етапу), також визначаємо підхід. Базові підходи: дослідницький та тестування за тест-кейсами.
В першому є трохи вайбу засліпленого оленя, що біжить крізь палаючий ліс, але він дозволяє приходити до очікуваних результатів неочікуваними шляхами, які, можливо не перевірялися раніше, отримувати розуміння, а чи достатньо user-friendly продукт, та чи дозволяє він формувати однозначні очікування від функціоналу. А ще, дозволяє знайти багато несподіванок в неочікуваних місцях, де тест-кейси шукати не наказували. Плюс, навіщо просто знайомитися з продуктом, якщо можна в той самий час його тестувати.
Scripted testing. Тут все, як в аптеці. Зручно вести облік. Зрозуміло, що робити далі. В нього засобами тест-дизайну виливається зібрана, в тому числі й дослідницьким тестуванням, інформація. Підхід дозволяє вести подальший облік, давати обґрунтовані оцінки та гарантії.
Вообщє ніхачю ухадіть с праекта, настолько всьо душевно, па-домашнєму (що значить «пиши зрозуміло» і кому це треба)
Досягнення на момент тут — ми усвідомлені, наче юний Сіддхартха після медитації. Знаємо, що саме і з якою метою робимо. Маємо чітке уявлення, яким стає продукт після чергового апдейту та яка реакція аудиторії є для нас бажаною. Бачимо, в яких умовах і тенденціях зовні та всередині команди відбувається наш робочий процес.
Розуміємо, як з програмної точки зору влаштований продукт: середовище розробки, додаткові інструменти, сторонні сервіси, платформи та пристрої, на яких продукт повинен справно функціонувати. Враховуємо вузькі місця, виходячи з переліченого, на які слід звертати максимальну увагу. Маємо набір тестів та опис, що за чим робити, знаємо, за що відповідає кожен з них (неподільних, за одну вимогу відповідальних).
Вони чудові, вичерпні та достатні, не пропускають жодного критичного моменту. Бага не проскочить. Traceability matrix по проходженню аж хочеться пошарити у всіх своїх соцмережах. Впорядкування виконано успішно.
Але є одне але.
Чи зможе довільна інша людина, окрім «творця», так само ефективно застосовувати створене? Та чи прагнення написати достатньо зрозуміло є порядністю або легковажністю? Такі питання часто породжують той тип дискусій, де ступінь неформальності сильно впливає на позицію учасників.
Документація загадкова (або як стати незамінним)
Мінімум контексту. Скорочення без посилання на їх розшифровку. Скачіть між мовами. Нехай колеги знають, що ви — поліглот. Знають, поважають, бояться, не розуміють... Вживайте абстрактні поняття та вказівники, («той, що тоді», «зробити нормально», «коли я роблю, щоб було так», «воно не працює»), умовно «відносні» координати замість «абсолютних»: «одного разу, коли я лікував бронхіт, в моєму улюбленому браузері застарілої версії сталось щось незрозуміле, фіксив чорнявий, що курить вінстон, пофіксив вроді норм».
Документація розбита на багато маленьких документів — дуже добре, нічого зайвого. Але складені вони за хронологією створення, а частина — в алфавітному порядку, ще частина — запаролена, бо тоді ви як раз прочитали одну статтю про безпеку, а ще одна частина документів — на флешці, бо потім ви читали іншу.
З безпекою врешті вирішили, що це не ваше, тому все, що писалось після, закинули на файлообмінник, пароль шість зірочок. Нє, ну тест-кейси всі разом: відкриваєш, йдеш від першого до останнього. Якщо не ясно, як щось робиться, най питають — так швидше буде.
Співробітник, що сумлінно слідує цим принципам, може не переживати про втрату роботи, звісно. З роботою він буде разом і назавжди. В горі, і в радості, при хворобі та на великі свята, у вихідні... Жартую, які такі вихідні)
Обмеження, які дають свободу
Принципи організації документації для внутрішнього користування, якщо підрахувати всі заощаджені години, рятують не одне життя. З них стає зрозуміло, де що знаходиться, в яких правилах редагується, на які умовні модулі поділено та за яким принципом, щоб під час створення нового модуля було ясно, як його оформити та куди віднести (дуже подібно до організації коду) ті елементи, які неможливо віднести до однієї категорії, супроводити поясненням та додатковими посиланнями.
Час пошуку інформації в проєктній документації — також параметр її якості. Як варіант, вимоги до написання репортів та тест-кейсів можна використати як стиль написання решти документації, де можливо представити інформацію в подібному форматі. Уніфікована подача сприяє глибшому засвоєнню, скорочуючи час між «я прочитав» та «я зрозумів».
Які інструменти обрати, щоб мінімізувати цей сукупний час — справа індивідуальна, але мета одна: звільнитися від статусу незамінного. Спитати все ще простіше, але коли ця опція не єдина, свободи стає більше у всіх.
Що це все було
Моя попередня, не пов’язана з тестуванням діяльність дала мені досить багато різнотипного досвіду, як впорядковувати документацію, формулювати наявні roadmap та створювати нові. Тому я підходила до описаних на початку задач не те щоб з пустими руками, а проте в IT мені до позицій типу lead великої команди — як до неба пішки.
Тому ділюся не стільки «методичкою», скільки баченням, спробою сформулювати послідовність кроків, виконання яких допоможе робити правильний вибір на всіх етапах процесу підготовки тестування.
Сподіваюся ця стаття буде корисною та посприяє комусь також прийти до зручнішого та ефективнішого робочого процесу. Дякую за увагу.
9 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарів