Сучасна диджитал-освіта для дітей — безоплатне заняття в GoITeens ×
Mazda CX 30
×

Як розробити тест-дизайн — від паніки до готового набору артефактів

Усі статті, обговорення, новини про тестування — в одному місці. Підписуйтеся на 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 великої команди — як до неба пішки.

Тому ділюся не стільки «методичкою», скільки баченням, спробою сформулювати послідовність кроків, виконання яких допоможе робити правильний вибір на всіх етапах процесу підготовки тестування.

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

👍ПодобаєтьсяСподобалось16
До обраногоВ обраному3
LinkedIn
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter
Дозволені теги: blockquote, a, pre, code, ul, ol, li, b, i, del.
Ctrl + Enter

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

прочитаю у ваших в коментарях.

о_О
Інші «але» виклав інший Олег у коментарях. =)

Проте, мені. як новачку було цікаво ознайомитись з вашим міркуваннями на тему...

Мене теж стиль зацепив :)

бо текст варто було прочитати комусь ще перед публікацією

дякую за уважність, читатиму краще :)

Гарно написано, з гумором, але якось занадто узагальнено. Бажаю автору натхнення на нові статті 😇

Так багато запитань до автора статті:
— назва не відображає змісту. Я розраховував побачити якісь реальні бізнес-кейси з поясненням як певна (неочевидна) техніка тест-дизайну допомогла протестувати цей кейс, або підходи по дизайну тест-кейсів, а побачив загальні міркування про тестову політику и тестову стратегію (особливо в першій половині статті). Це так зроблено навмисне чи я чогось не розумію?
— деякі терміни вжиті занадто загально і абстрактно, наприклад «документація» в

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

Документація — це ви про що? Про тестартефакти, що створюють QA, чи про вихідну документацію бізнесу, архітектури та дизайну проекту?

Весь розділ «Мета» — не додає нічого нового до розкриття теми про тест-дизайн. Більш того, останнє ствердження в ньому є хибним. Я про це

Тест-дизайн — засіб, що організовує та структурує роботу, а не робить її ефективнішою автоматом. Ваша ефективність або достатня без нього, сформульованого та (не обов’язково) чітко виписаного, або ні.

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

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

Компанія продуктова чи аутсорс?
Команда на 100, 500 чи 100500 людей?
Яка загальна плинність кадрів?
Яка ціна помилки
Чи є тенденція до розширення та наскільки?

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

Знову і знову зустрічається міксування різних рівней асбтракції

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

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

Міфологія давнього IT стверджує, що тестери — нижча каста, і до розробника їм просто так підійти не варіант.

Так давайте не поширювати старі міфи и принаймні не створювати такі відчуття меншовартості самі у себе.

Сукупний досвід довів, що зробити вашу спільну скриньку якомога білішою — справа корисна для всієї команди.

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

Від протилежного: обрана без глибокого розуміння організації продукту комбінація технік тест-дизайну майже 100% буде заскладною та надмірною. Не треба так.

Все навпаки, якщо у вас нема розуміння архітектури продукту, то тестування буде більш прости і інтуітивним, адже ви будете застсовувати exploratory testing, use case і якісь інші 1-2 техніки тест дизайну, що відносяться до black box. Чи більше у вас інформації про продукт, тим більшим стає ваш спектр доступних технік, включаючи доволі складні model-based, pairwise. Збільшується кількість метрик, якими ви можете зазначати покриття тестами, зявляється та сама цикломатична складність системи і т.д.

Переходимо до підходів і інструментів. Хоча в цілому ці 2 ствердження є вірними в цілому:

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

Але їх вплив на техніки прям зворотній. Ви спочатку обираєте техніки тест-дизайну, а вже потім працюєте зі статистичною інформацію завершених етапів тестування і починаєте розуміти які тести виявляють найсерйозніші дефекти (не забуваємо про парадокс пестициду).
Якщо ж статистики нема, проект новий, все створюємо з нуля, то тут точно більш ефективними за замовчуванням стають experienced-based техніки такі як error guessing та exploratory testing. Помноживши їх на risk-based сратегію, відсікаємо всі замудрені методологічні підходи. Як же ш тоді вийти на 100500 юніт-тестів, на які ви натякали в розділі «Що в чорному ящику?»

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

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

Щоб створити гідний набір тестів, нам потрібно:
— розбити цілісну систему на складові;
— зібрати та проаналізувати увесь перелік вимог до продукту;
— розставити пріоритети (не дивитися в бік мінорних дефектів, доки не розібралися з критичними);
— сформулювати зібрані ввідні дані, унеможлививши їх хибне трактування;
— взяти і застосувати обрані техніки.

Дуже абстрактний список вийшов, хоча ви його і розбили на булети. Проходжу по кожному:

розбити цілісну систему на складові;

що значить розбити на складові? А для чого? А користувач теж розбиває на складові чи користується продуктом as isб в цілому? А якщо таки на складові, чи не про test conditions ви хотіли сказати? Не зрозуміло

зібрати та проаналізувати увесь перелік вимог до продукту;

що значить проаналізувати? що це нам дає? як ми цей аналіз використовуємо подальшому? Памаятаєте назву статті? «... до готового набору артефактів».

розставити пріоритети (не дивитися в бік мінорних дефектів, доки не розібралися з критичними);

А коли ви кажете про мінорні, ви маєте на увазі priority чи severity? А якщо продукт у нас загинається від тисячі порізів, як ми будемо себе поводити?Я згоден з тим, що треба розставляти пріоритети, але я б подав це під соусом, що більш ризиковані частини вважаємо більш пріоритетними, а тому тестуємо більш ретельно. Хоча окей, тут ви хоча б навели приклад, варто було б зробити це і по іншим булетам списку

взяти і застосувати обрані техніки.

як кажуть у нас у селі «план надійний як швейцарський годинник» :)

Прагнемо щільного тестового покриття? Дивимося в бік функціонального тестування та розбиття на класи еквівалентності.

Розбиття на класи еквівалентності — це прям сама поверхня функціонального тестування. Більш щільне -> +граничні значення +pairwise +більше уваги error handling (коли інвалідних класів може виявитись знаааачно більше ніж ми вважали).

Важливо чиїми саме очима дивитися на продукт? Бета та користувацьке — до ваших послуг.

В комерційній розробці QA завжди дивляться очима користувача, чи ні?

Хочете зрозуміти, як продукт виконує свою бізнес-задачу? Організовуйте UAT (user acceptance testing).

UAT — практично невідємна частина процесу розробки. Кількість проектів, що минують цю фазу незначна. Тому і UAT, і все, про що йдеться вище разом, не окремо.

Залежно від мети (хоча, скоріше, етапу), також визначаємо підхід. Базові підходи: дослідницький та тестування за тест-кейсами.

А наведіть будь-ласка приклади мети (етапів). А логічно, чому ця інформація не потрапила до розділу «Мета»?

Але є одне але.
Чи зможе довільна інша людина, окрім «творця», так само ефективно застосовувати створене?

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

Розділи «Документація загадкова» та «Обмеження, які дають свободу» абсолютно зайві та ніяк не розкривають тему тест-дизайну.

Субєктивні висновки:
Заінтригував стиль написання, власне прочитавши вступні абзаци, збирався почитати щось іронічне та кумедне, але коли подивився на суть, то просто не міг не прокоментувати. Нажаль, стаття не несе ознак практичності, які слід було б очікувати, прочитавши її назву. Дуже велика кількість контроверсійних стверджень (а іноді і відверто хибних). Хоча може авторка задумала це як певний тролінг, то тоді я явно не збагнув задуму.

P.S. Сподіваюсь коментарій буде корисним і Валентині і потенційним читачам статті
P.P.S. Відкритий до подальшої дискусії

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

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

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

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

1. Документація — артефакти
2. Мета — суб’єктивно для вас не дає. Мені дало, тому вирішила записати. Хибно, дійсно, я сформулювала недостатньо чітко, і так не зрозуміло, що я маю на увазі саме дизайн виписаний текстом як не 100% необхідний. Перепрошую.
3. Чим більше людей і проміжних ланок, тим важливіше спрощувати та розбивати на менші елементи, + жорсткий контроль та чіткий шаблон, якщо виконавці змінюються — на це також витрачається ресурс, і він повинен бути врахований. Є різниця чи ви звітуєте тому, хто приймає рішення, чи тому, їх передає — різниця в якості та доцільності дискусії, в затратах часу, а оскільки час обмежений і частина його зарезервована під «щоб усі з усіма побалакали», час на тестування зменшується... ціна помилки = кількість уваги до критичних місць = кількість різних підходів, які вважаються достатніми = час (вища ціна — більше зусиль уникнути потреби її платити) така була логіка
4. Стратегії. Тут, 100% вам видніше. Можу хіба опонувати, що схилятись і обирати оптимальне — різні речі і для спеціаліста, по ідеї метою є куди б не схилявся пам’ятати що потрібно шукати оптимальність та критично оцінювати свої пориви в тому числі (ідеалізую, але треба ж чогось і прагнути).
5. Скринька — моє посилання фактичне ширше за вказане, вибірка завжди буде обмежена, що моя, що ваша. Ваша, певно більша, тож рада, що маю нагоду дізнатись, як правильно
6. Про навпаки. Ви тут, певно, уявляєте собі одну людину — яка і складає план, обирає підходи, і тестує. Тут я мала на увазі, що розуміння потрібне — ви не знатимете, для якої фічі, грубо кажучи, достатньо буде exploratory testing, може й smoke досить, а для чого потрібно і по юнітах, і integrated після і т.п. якщо нема розуміння якої кількості коду стосуються апдейт, з чим він пов’яханий і в яких місцях потенційно може щось зламати
7. Комбінація технік. Зворотній якщо сприймати в хронології. Тут твердження позв нею. Вони скоріше як мета на яку потрібно орієнтуватись, даючи якісну оцінку тому, що є. Вийти в динаміці, якщо буде визначено, що така кількість виправдана
8. Патетичними я їх назвала, якраз з метою викликати протест)
9. Список: 1. Ідея умовного поділу. висновок розгляду якої може бути й цілий неподільний єдини елемент. Як користується користувач залежить від користувача. Приклад з життя: в нас є розділ бухгалтерія, можна вести всю свою бухгалтерію і ми порахуємо податки з її даних користувачу автоматично. Дуже зручно. Тим не менше, велика частина користувачів її ігнорить, їм простіше відкрити раз на період декларацію і вписати сумму і все, решта послуг не цікавить і це теж прекрасний, популярний спосіб користування продуктом.
10. Це дозволяє прийти до приорітетів. Приорітети дають відповідь про що в першу чергу та наскільки ретельно з яких пишуться тест-кейси
11. Ви скачете від загального до конкретного. Якби я розглядала більше таких випадків цей текст став би безкінечним. Є концепція, для застосування на конкретному прикладі, вона потребує своєї індивідуальної кастомізації. Що я буду робити якщо, це вже концепція + кастомізація, яка може і доповнити і змінити саму концепцію.
12. Я тут даю перелік «точок входження» до теми. Це нормальна практика для реальної ситуації їх переосмислювати або відкидати. Вони тут є саме всі, саме такі, тому, що я не скажу про жодну з них, що ось це, точно нікому ніколи не вийде доречним
13. Функціональне: дякую за доповнення.
14. Чиї ті очі: тут питання було «хто саме той користувач», користувачі ж теж бувають різні і хочуть різного від продукту
15. UAT: тому я зпоміж інших в таком у малому переліку його і згадала
16. Тому що в розділі мета, малася на увазі загальна проекту, а не конкретної ітерації тестування. Варіанти: 1) ми дописали нову фічу, перевірити чи працює як треба і нічого іншого не зламалося.2) ми адаптувались під стандарт нової країни, якій продаватимемо продукт, перевірити відповідність стандарту, що все працює ок... як етап acceptance чи sanity наприклад
17. Зайві розділи. Ми з моєю поганою кармою стикалися з ситуаціями, коли нерозуміння цих речей сильно впливало на робочий процес. Такий мій досвід, розумію, що у вас він інший
18. Я джун, якщо шо) і для мене були справді дуже цінними ваші коментарі

1. Про документацію і тест артефакти. Все ж таки цікаво, що тест-дизайн це про тест-кейси, а ви впродовж статті апелюєте до всіх артефактів, аж від тест плану (а то і тест стратегії) і до тест репортів. Чи нема у вас тут певної плутанини у визначеннях?
2. А чи дало вам? А розкажіть простими словами? І взагалі мета чого, Тест дизайну чи цієї статті? І чому для IT не підходить кодекс самурая?
3.

Чим більше людей і проміжних ланок, тим важливіше спрощувати та розбивати на менші елементи,

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

Стратегії.

Розумієте, тут така фішка, що багато хто, коли навчиться читати код, і писати автотести, то не дуже поспішають з ручним тестуванням (навіть якщо воно ефективніше або оптимальніше в конкретному випадку). А навіщо? Займаєшся складною справою, корисною для кар’єрного просування і платять за це більше. І приходимо до того, що починаємо пхати ті автотести де треба і не треба. А exploratory? То хай у менеджера голова болить.
5.

Скринька — моє посилання фактичне ширше за вказане

вибачте не зрозумів чи апелюєте до мого якогось конкретного коментаря
6.

Ви тут, певно, уявляєте собі одну людину — яка і складає план, обирає підходи, і тестує.

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

достатньо буде exploratory testing, може й smoke досить

цікавий приклад. Smoke testing — це про звуження вибірки ваших існуючих тестів для швидкої перевірки працездатності системи. Чи можна його взагалі ставти в один ряд з повноцінною технікою тест-дизайну (exploratory testing)?

якщо нема розуміння якої кількості коду стосуються апдейт, з чим він пов’яханий і в яких місцях потенційно може щось зламати

а й не завжди потрібно. Женемо регресійні автотести на кожен білд і можна взагалі про це не думати (що багато хто і робить).
7.

Комбінація технік.

. Дивіться як справа. Ви створили тести, які знайшли критичні дефекти, але їх доля невелика, в переважній більшості баги були мінорні. Продукт вийшов в реліз, клієнт задоволений? Чи гарно ви попрацювали? Моя відповідь — так, а ваша? Чи от така ситуація, серйозний медичний софт, питання життя і смерті і все таке. Окрім стандартних функціональних тестів, для яких ви використовували blackbox техніки, ви також застосовуєте model-based, створюєте модель, і вона у вас покриває абсолютно всі можливі переходи, які існують в продукті. Вона навіть не вимикається, тобто у вас там даже не то щоб тест-кейсів багато, вони взагалі виконуються нон-стоп стільки, скільки йде етап тестування. Тобто кількість виконань — мільйони, кількість унікальних paths — десятки тисяч. Знайдено 1 критичний дефект, всього один, але який, десятки людей можливо будуть жити завдяки вам. То що там про нашу комбінацію технік, вона була ефективною чи ні? А як ми могли про це дізнатись, не протестувавши і не знаючи результат?
9.

Список: 1. Ідея умовного поділу.

В принципі ідея декомпозиції — це вже застосування певних технік тест-дизайну з аналітичної добірки. Тобто, що у вас перше — курка чи яйце?
10.

10. Це дозволяє прийти до приорітетів. Приорітети дають відповідь про що в першу чергу та наскільки ретельно з яких пишуться тест-кейси

Не обов’язково. Уявимо, що ми застосовуємо на проекті ризик-менеджмент. І ми знаємо, які ризики є критичними, які — середніми, які можна ігнорувати. Ви все ще повинні прийняти рішення, що «тут» необхідно застосувати «decision table», «там» — класи еквівалентності, а «ось там» вистачить і чек-ліста на основі use cases, які нам надав клієнт в scope of work. Та й той же coverage на мапиться до певних ризиків (пріоритетів) за певним шаблоном. Це вже ваше персональне рішення, засноване на навяних даних і вашому досвіді/знаннях.

Якщо чесно кажучи, то пункти з 11 до 17 були б придирками до окремих слів, вирваних з контексту, тому перейду одразу до узагальнюючого висновку:

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

Підписатись на коментарі