Життєві ресурси 

Як відбувається тестування? Юзабіліті-тестування

Переклад:Ольга Аліфанова

Якби вам довелося відповісти на запитання "Що таке тестування?", що ви сказали б? Це поняття досить важко впхнути в пару-трійку коротких речень.

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

З чого складається тестування

Розслідування

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

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

Дослідження

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

Тестування не повинно сприйматися як прогін списку готових тестівабо тест-кейсів, що дають твердий "pass/fail" результат. Якщо у вас є користувачеві або набір вимог, звичайно, важливо мати їх на увазі. Проте критерії приймання корисно переформулювати як " критерії відмови " . Коли критерії приймання не задоволені, продукт не прийнято, але якщо вони в порядку, це не означає, що в програмному забезпеченні немає багів.

Перевірки та верифікація повинні поєднуватися з дослідженням та розслідуванням, а також питаннями в дусі "Що буде, якщо…", на які ви можете не знати відповіді, поки не спробуєте, та відповіді на які не покриті готовими кейсами.

Зниження ризиків

Одна з причин, з якої ми тестуємо, – пошук дефектів, ризиків та іншої інформації про продукт, яка дозволяє нам діяти, щоб кінцевий користувач не постраждав. Ми можемо:

  • Виправляти баги.
  • Переоцінити та змінити початкові вимоги.
  • Допомогти користувачеві продукту.
  • Створити документацію користувача.
  • Донести інформацію про проблеми до зацікавлених осіб.

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

Цінність

Тестування – це цінна частина розробки ПЗ, але його часто недооцінюють через його непередбачувану та креативну природу.

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

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

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

Тестування цінне всіх стадіях життєвого циклу розробки, як коли пишеться код. Ось що ще можна протестувати:

  • Вимоги
  • Дизайн
  • Припущення
  • Документацію
  • Інфраструктуру
  • Процеси.

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

Комунікація

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

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

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

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

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

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

Потенційна нескінченність

По суті, ми завжди тестуємо лише вибірку. Кожен нетривіальний продукт має непредставну кількість параметрів з великою кількістю можливих значень. Звідки знаєте, що тестуєте важливі значення? Ми не можемо протестувати все.

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

З чого тестування не складається

Простота

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

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

Навіть перевірки – не така проста справа. Ми приймаємо непрості рішення, де потрібні ці перевірки, і які слід автоматизувати. Ці рішення вимагають розуміння фреймворків автоматизації, навички програмування, знання, як працює API, та володіння інструментами на кшталт Selenium. Резюмуючи, ми повинні розумітися на пристойному наборі технологій. Крім цього, нам потрібно знати, що потрібно автоматизувати, а чого автотести підпускати не можна.

Автоматизованість

"Ручні випробувачі нам більше не потрібні - ми можемо автоматизувати все!" Всі ми бачили ті чи інші варіації цієї фрази у Твіттері, на форумах та у статтях. Тестування – це дослідницька, детективна діяльність, її неможливо замінити автоматизованими перевірками. p align="justify"> Комп'ютер технічно не здатний досліджувати продукт так, як це робить людина.

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

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

Підвищення якості

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

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

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

Якість визначається як "цінність для людини, чия думка значуща". Його важко виміряти, і тому з певністю заявити, що тестування на будь-якому етапі покращує якість продукту, досить важко, навіть неможливо.

Фіксована діяльність, що не вимагає уяви, підпорядковується суворим правилам

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

Не існує кращих практик тестування, які застосовуються в будь-яких проектах. Ви повинні з'ясувати, що найкраще працює у вашому контексті та у вашій області.

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

Життєво необхідно для успіху продукту

Проект може бути цілком успішним і без тестувальників – тому багато прикладів. Однак навіть у разі відсутності тестувальників як таких тестування все ж таки кимось виконується на тій чи іншій стадії життєвого циклу. Розробники тестують власний код, а замовники вимоги. Кінцевий користувач іноді тестує продукт до релізу. Люди можуть тестувати, навіть не усвідомлюючи, що вони цим займаються.

Ніколи не закінчується

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

Частина роботи тестувальника – це прийняття рішень, що саме тестувати, та розуміння наслідків цих рішень та пов'язаних з ними ризиків.

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

Тестування - це багато, багато іншого

Я перерахувала лише деякі аспекти того, що таке тестування. Ця стаття могла б бути значно довшою! Немає єдиного визначення, що мається на увазі під тестуванням, а впхнути в одну пропозицію все те, чим займаються тестувальники просто неможливо! Якщо пошукати визначення тестування в Інтернеті, можна натрапити на фрази на кшталт "пошук багів у додатках" – але, як ми вже з'ясували, це не тільки не стільки пошук багів.

Ми випустили нову книгу«Контент-маркетинг у соціальних мережах: Як засісти в голову передплатників та закохати їх у свій бренд».

Якщо в дитинстві ви любили розбирати на частини машинки з моторчиком або змішувати всі рідини, які були в будинку, то ця стаття для вас. Сьогодні розуміємося на A/B тестуванні сайту і з'ясовуємо, чому в умілих рукахвоно перетворюється на потужна зброя. Відкопуємо в глибинах свідомості дух експериментатора, струшуємо з нього пилюку і читаємо.

Що таке – А/Б тестування сайту?

Якщо коротко, це метод оцінки ефективності двох варіантів однієї й тієї ж сторінки. Наприклад, є два дизайни картки товару і обидва вони настільки круті, що ви навіть спати і їсти не можете. Логічний вихід – перевірити, який варіант працює краще. І тому половині відвідувачів показується варіант №1, а половині – варіант №2. Перемагає той, хто краще справляється із поставленими завданнями.

Це не єдиний спосіб застосування А/Б (або спліт) тестування сайту. З його допомогою можна перевіряти божевільні гіпотези, зручність нової структуристорінки чи різних варіантів тексту.

Як проводиться A/B тестування сайту

Постановка задачі

Спочатку потрібно визначитись із метою. Зрозумійте, чого ви хочете досягти: збільшення конверсії, часу перебування на сайті або зменшити відсоток відмов. Якщо з цілями та завданнями все ОК, змінюйте контент чи дизайн, спираючись на них. Наприклад, можна піти шляхом всіх growth-хакерів і змінити розташування і дизайн кнопки «Купити». Зараз вона висить ліворуч унизу і ви хочете подивитися, що буде, якщо змінити її зовнішній вигляді пересунути кнопку вище та правіше.

Технічна реалізація

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

Підготовка контрольних даних

Сторінка перероблена та все готове до запуску тесту. Але спочатку потрібно виміряти вихідні показники конверсії та всіх інших параметрів, які ми враховуватимемо. Вихідному варіанту сторінки надають ім'я «A», а новому – «B».

Тест

Тепер потрібно випадково розділити трафік навпіл. Половині користувачів показується сторінка A, а іншим – B. Для цього можна скористатися спеціальними сервісами (їх дуже багато) або зробити все руками програміста.

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

Аналіз

Тепер потрібно чекати, доки набереться достатньо статистики та порівняти результати А/Б тестування. Скільки саме доведеться чекати, залежить від популярності сайту та деяких інших параметрів. Вибірка має бути статистичну значимість. Це означає, що ймовірність випадковості результату має бути не вищою за 5%. Приклад: Припустимо, на обох сторінках однакова кількість візитів – тисяча. При цьому у сторінки A 5 цільових дій, а у сторінки B – 6. Результат відрізняється надто незначно, щоб говорити про закономірність, тому він годиться.

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

Вироблення рішення

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

Як зробити A/B та спліт-тестування об'єктивним

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

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

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

Чи впливає A/B тестування сайту на SEO?

Є популярний міф, що А/Б тестування може вийти боком, тому що через дублювання сторінок можна потрапити під пошукові фільтри. Це не правда. Google навіть розповідає, як зробити все правильно і дає для цього спеціальні інструменти.

Що і як можна покращити за допомогою A/B тестування

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

Зазвичай намагаються міняти:

  • Дизайн кнопок "Купити", "Залишити заявку".
  • Контент сторінки: заголовки, опис продукту, зображення, заклики до дії та інше.
  • Розташування та зовнішній вигляд блоку з цінами.
  • Структура сторінки.
  • Розташування, структуру та дизайн форми заявки.

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

Інструменти для A/B тестування сайту

Їх просто купа, тому ми вибрали найкращі. Всі вони англомовні і тому дорогі, але кожен має безкоштовний пробний період. У Росії щось подібне робить тільки lpgenerator.ru, але тестувати там можна лише лендинги, створені у конструкторі сервісу. Свою сторінку завантажити не вдасться.

Optimizely.com

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

Changeagain.me

Досить зручний сервіс, головна перевага – проста і повна інтеграція з Google Analytics: цілі можна створювати прямо в сервісі, а потім автоматично підвантажуються в систему. Інші функції більш-менш стандартні: простий візуальний редактор, націлення на пристрої та країни. конкретний набір залежить від тарифного плану.

ABtasty.com

Цей сервіс відрізняється великим пробним періодом – він триває аж 30 днів замість стандартних 14-15-ти. Плюс, інструмент інтегрується в WordPress, Google Analytics та кілька інших сервісів, якими користуються зарубіжні маркетологи та веб-майстри. З додаткових плюсів: зручний інтерфейс та детальний націлення.

Як провести A/B тестування через Google Analytics

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

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

Там задаються адреси сторінок A і B. Якщо поставити галочку «Уніфікація варіантів інших звітів за змістом», то інших звітах показники всіх варіантів враховуватимуться як показники вихідної сторінки.

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

Як налаштувати «Яндекс Метрику» для A/B тестування

Робота поділяється на дві частини. Спочатку потрібно створити дві сторінки, або налаштувати одну на показ користувачеві двох різних типів елементів. Як це зробити – тема для окремої великої статті, тому її поки що обійдемо

Після цього потрібно передати до метрики інформацію про те, який варіант сайту побачив користувач. Невелику інструкціюдає сам «Яндекс» . Для нас потрібно створити параметр А/Б тестування та присвоїти йому потрібне значення. У випадку з кнопкою ми визначаємо параметр як:

var yaParams = (ab_test: "Кнопка1");

або

var yaParams = (ab_test: "Кнопка2");

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

Підсумки

А/Б (або спліт) тестування сайту – це важливий, потрібний та майже обов'язковий інструмент. Якщо регулярно перевіряти нові гіпотези, ефективність сторінки можна вивести новий рівень. Але не можна сказати, що зусиль для цього потрібний мінімум. Щоб просто змінити розташування або колір кнопки доведеться підключити до справи програміста чи дизайнера, нехай це не займе багато часу. Плюс будь-яке припущення може виявитися помилковим. Але хто не ризикує, той не отримує потік заявок, що збільшився, і не бігає по офісу щасливим.

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

Що називають тестуванням?

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

Ефективність

Те, наскільки добре та швидко знаходяться помилки, істотно впливає на вартість та тривалість розробки програмного забезпечення необхідної якості. Так, незважаючи на те, що тестери отримують заробітну плату в кілька разів меншу, ніж програмісти, вартість їхніх послуг зазвичай сягає 30-40% від вартості всього проекту. Це відбувається через чисельність особового складу, оскільки шукати помилку – це незвичайний та досить важкий процес. Але навіть якщо програмне забезпечення пройшло значну кількість тестів, то немає 100% гарантії, що помилок не буде. Просто невідомо, коли вони виявляться. Щоб стимулювати тестерів вибирати типи перевірки, які з більшою ймовірністю знайдуть помилку, застосовуються різноманітні засоби мотивації: як моральні, так і матеріальні.

Підхід до роботи

Оптимальною є ситуація, коли реалізуються різні механізми, спрямовані на те, щоб помилок у програмному забезпеченні не було від початку. Для цього необхідно подбати про грамотне проектування архітектури, чітке технічне завдання, а також важливо не вносити корективи у зв'язку, коли роботу над проектом вже розпочато. У такому разі перед тестером стоїть завдання знаходження та визначення невеликої кількості помилок, що залишаються в кінцевому результаті. Це заощадить і час, і гроші.

Що таке тест?

Це важливий аспект діяльності перевіряючого, який необхідний успішного виявлення недоліків програмного коду. Вони необхідні для того, щоб контролювати правильність програми. Що входить до тесту? Він складається з початкових даних і значень, які повинні вийти як результуючі (або проміжні). Для того, щоб успішніше виявляти проблеми та невідповідності, тести необхідно складати після того, як був розроблений алгоритм, але не почалося програмування. Причому бажано використовувати кілька підходів для розрахунку необхідних даних. У такому випадку зростає можливість виявлення помилки завдяки тому, що можна досліджувати код з іншого погляду. Комплексно тести повинні забезпечувати перевірку зовнішніх ефектів готового програмного виробу та його алгоритмів роботи. Особливий інтерес надають граничні та вироджені випадки. Так, у практиці діяльності з помилками часто можна виявити, що цикл працює на один раз менше чи більше, ніж було заплановано. Також важливим є тестування комп'ютера, завдяки якому можна перевірити відповідність бажаного результату різних машинах. Це необхідно для того, щоб переконатися, що програмне забезпечення зможе працювати на всіх ЕОМ. Крім того, тестування комп'ютера, на якому виконуватиметься розробка, є важливим при створенні мультиплатформних розробок.

Мистецтво пошуку помилок

Програми часто націлені працювати з великим масивом даних. Невже його потрібно створювати повністю? Ні. Широкого поширення набула практика «мініатюризації» програми. У даному випадкувідбувається розумне скорочення обсягу даних у порівнянні з тим, що має використовуватись. Давайте розглянемо такий приклад: є програма, де створюється матриця розміром 50x50. Іншими словами – необхідно вручну ввести 2500 тисяч значень. Це, звичайно, можливо, але займе багато часу. Але, щоб перевірити працездатність, програмний продукт отримує матрицю, розмірність якої становить 5x5. Для цього потрібно буде запровадити вже 25 значень. Якщо у разі спостерігається нормальна, безпомилкова робота, це означає, що усе гаразд. Хоча і тут існують підводні камені, які полягають у тому, що при мініатюризації відбувається ситуація, внаслідок якої зміни стають неявними та тимчасово зникають. Також дуже рідко, але все ж таки трапляється і таке, що з'являються нові помилки.

Переслідувані цілі

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

Перевірка у різних умовах

Як правило, тестування програм відбувається у обсягах, які необхідні мінімальної перевірки функціональності в обмежених межах. Діяльність ведеться із зміною параметрів, а також умов їхньої роботи. Процес тестування можна розділити на три етапи:

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

Тестування ПЗ: види

Створювати програмне забезпечення без помилок дуже важко. Це потребує значної кількості часу. Щоб отримати хороший продукт часто застосовуються два види тестування: Альфа і Бета. Що вони являють собою? Коли говорять про альфа-тестування, під ним мають на увазі перевірку, яку проводить сам штат розробників у «лабораторних» умовах. Це останній етап перевірки перед тим, як програма буде передана кінцевим користувачам. Тому розробники намагаються розвернутися максимально. Для легкості роботи дані можуть протоколюватись, щоб створювати хронологію проблем та їх усунення. Під бета-тестуванням розуміють постачання програмного забезпечення обмеженому колу користувачів, щоб вони змогли поексплуатувати програму та виявити пропущені помилки. Особливістю в даному випадку є те, що часто використовується не за своїм цільовим призначенням. Завдяки цьому несправності виявлятимуться там, де раніше нічого не було помічено. Це цілком нормально і переживати із цього приводу не потрібно.

Завершення тестування

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

Автоматизоване тестування

Раніше вважалося, що динамічний аналіз розробленого ПЗ – це надто важкий підхід, який неефективно використовуватиме виявлення дефектів. Але через збільшення складності та обсягу програм з'явився протилежний погляд. Автоматичне тестування застосовується там, де найважливішими пріоритетами є працездатність та безпека. І вони повинні бути за будь-яких вхідних даних. Як приклад програм, котрим доцільним є таке тестування, можна навести такі: мережеві протоколи, веб-сервер, sandboxing. Ми розглянемо далі кілька зразків, які можна використовувати для такої діяльності. Якщо цікавлять безкоштовні програмиТестування, то серед них якісні знайти досить складно. Але існують зламані «піратські» версії проектів, що добре зарекомендували себе, тому можна звернутися до їхніх послуг.

Avalanche

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

KLEE

Це гарна програмадля тестування пам'яті Вона може перехоплювати приблизно 50 системних викликів і велику кількість віртуальних процесів, таким чином, виконується паралельно та окремо. Але в цілому програма не шукає окремих підозрілих місць, а обробляє максимально можливу кількість коду і проводить аналіз шляхів передачі даних, що використовуються. Через це час тестування програми залежить від розміру об'єкта. Під час перевірки ставка зроблена на символічні процеси. Вони є одним з можливих шляхіввиконання завдань у програмі, що перевіряється. Завдяки паралельній роботіможна аналізувати багато варіантів роботи досліджуваного докладання. Для кожного шляху після закінчення тестування зберігаються набори вхідних даних, з яких починалася перевірка. Слід зазначити, що тестування програм за допомогою KLEE допомагає виявляти велику кількість відхилень, яких не повинно бути. Вона може знайти проблеми навіть у програмах, які розробляються десятиліттями.

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

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

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

З чого починати організацію процесу тестування?

Я виділяю 11 основних критеріїв в організації процесу тестування:

  1. Цілі та область тестування
  2. Команда
  3. Управління
  4. Комунікація та взаємодія
  5. Методологія тестування
  6. Документованість процесу
  7. Управління ризиками
  8. Вимірювання процесу
  9. Інструменти
  10. Тестові середовища
  11. Удосконалення процесу

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

Тому будь-який керівник, перед яким стоїть завдання організації процесу тестування, повинен поставити такі питання:

  • Навіщо нам потрібне тестування?
  • Що ми маємо зробити тестування?
  • Які процеси потрібно формалізувати чи створити?
  • Як і що ми маємо тестувати?

Тільки після того, як ми отримаємо відповіді на ці питання, можна починати переходити до стандартів.

Я виокремлю наступні стандарти, які дійсно потрібно вивчити перед тим, як починати будувати процес:

  • ISO 29119
  • IEEE 829\1008
  • TPI Next&TMap
  • ISTQB

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

Будь-який ІТ процес завжди повинен задовольняти потреби бізнесу!

Ми розберемо основні критерії побудови тестування.

Цілі та область тестування

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

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

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

  • Що треба випробувати?
  • Що тестуватимемо?

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

Команда та управління

Команда – це найважливіша складова процесу тестування. Без команди ви як керівник нічого не зробите. Найчастіше до формування команди підходять кількома підходами:

Інструменти та інфраструктура

Який процес тестування без інструментів? Я думаю багато хто з вас часто чув про написання тест-кейсів у документах ворд, про побудови графіків та діаграм в екселі. Але, навіщо витрачати зусилля, якщо ринок пропонує нам готові продукти управління тестування, такі як HP ALM, MS TFS, TestRail, TestLink, JIRA Zephyr та багато інших.
Тому, якщо ви приступили до організації процесу тестування, то робіть цей процес зручним та ефективним. Пишіть тест-кейси у зручних формахготових продуктів, інтегруйте інструменти із системою управління завданнями, налаштовуйте тощо.

Підходячи до вибору інструменту, потрібно завжди розуміти:

  • Які завдання ви плануєте виконувати?
  • Який бюджет у вас на інструменти?

Отримавши відповіді на ці питання, ви зможете визначити найбільш зручні для вас інструменти тестування, а можливо і розробити власні.

Крім інструментів управління тестування, до інструментів тестування також можна віднести:

  • Система управління дефектами та завданнями (може включатися до системи управління тестуванням)
  • Допоміжні інструменти (для скріншотів, зняття логів, роботи з БД, SOUP UI для XML і т.д.)
  • Інструменти автоматизації ( , Selenium і т.д.)
  • Системи управління знаннями (на wiki движку)

Тепер поговоримо про інфраструктуру. У поточному контексті своєї розповіді я маю на увазі тестові середовища.

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

Стандартно виділяю такі типи тестових середовищ:

  • Середовище розробки (чи можна її відносити до тестової?, проте)
  • Середовище тестування системи (може бути розгорнуто одну або кілька систем, компонент, що не вимагає серйозних потужностей)
  • Середовище інтеграції (повноцінне інтеграційне середовище для перевірки працездатності наскрізних бізнес-процесів)
  • Середовище (основне вимоги - відповідність потужностям бойового контуру)
  • Середа ПродЛайк/ПреПрод (середовище для налагодження готового протестованого білда, проведення інсталяційного тестування)

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

Удосконалення процесу

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

Але це не так. Чому ми повинні постійно удосконалювати процес тестування:

1. Цілі тестування не можуть бути однаковими, вони постійно змінюються залежно від потреб бізнесу, що диктується ринком.

2. ІТ сфера постійно розвивається. Приходять нові технології підходи, які завжди дозволяються вдосконалювати процес тестування.

Як кажуть, досконалості немає меж!

Ну а як удосконалювати це стандартний цикл Деммінга.

Запланували -. Зробили - Проаналізували - Скоригували

Ну і насамкінець скажу, що правильна дозволяє в найкоротші терміни створити дійсно ефективний процес тестування, що вирішує поставлені йому цілі та завдання.

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

Одним із інструментів розвитку веб-проектів є A/B-тестування. Цей метод дозволяє виміряти переваги аудиторії та впливати на ключові показники ефективності сайту, включаючи конверсії, час перебування користувачів на сторінці, середню суму замовлення, показник відмов та інші метрики. З цієї статті ви дізнаєтесь, як правильно проводити A/B тестування.

Що таке A/B-тестування

A/B-тестування – це маркетинговий метод, який використовується для оцінки та управління ефективністю веб-сторінки. Цей метод також називається спліт-тестуванням (від англ. Split testing – роздільне тестування).

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

Спліт-тестування починається з оцінки метрик існуючої веб-сторінки (A, контрольна сторінка) та пошуку способів її покращення. Наприклад, ви створили інтернет-магазин. Уявіть собі сторінку цього магазину з коефіцієнтом конверсії 2%. Маркетолог бажає збільшити цей показник до 4%, тому планує зміни, які допоможуть вирішити це завдання.

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

За допомогою інструментів для проведення спліт-тестування експерт у випадковому порядку поділяє трафік між сторінками A та B на дві приблизно рівні частини. Умовно кажучи, половина відвідувачів потрапляє на сторінку A, а друга половина на сторінку B. При цьому маркетолог тримає на увазі джерела трафіку. Щоб забезпечити валідність та об'єктивність тестування, необхідно направити на сторінки A та B по 50% відвідувачів, які прийшли на сайт із соціальних мереж, природного пошуку, контекстної реклами тощо.

Зібравши достатньо інформації, маркетолог оцінює результати тестування. Як зазначено вище, коефіцієнт конверсії сторінки A становить 2%. Якщо на сторінці B цей показник склав 2,5%, то зміна конверсійної кнопки з блакитного на червоний колір справді збільшила ефективність лендінгу. Однак показник конверсії не досяг бажаних 4%. Тому маркетолог далі шукає способи вдосконалення сторінки за допомогою A/B тестування. При цьому як контрольна виступить вже сторінка з червоною конверсійною кнопкою.

Що тестувати

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

Наприклад, якщо показник відмов посадкової сторінки становить 99%, більшість відвідувачів залишають лендинг протягом 2-3 секунд після «приземлення», варто задуматися про зміну візуальних компонентів сторінки. За допомогою A/B-тесту маркетолог може знайти оптимальний варіант макета сторінки, вибрати привабливу кольорову гаму та зображення, використовувати шрифт читабель. А якщо перед маркетологом стоїть завдання збільшити кількість передплат, він може спробувати змінити відповідну конверсійну форму. Спліт-тест допоможе фахівцю вибрати оптимальний колір кнопки, кращий варіанттексту, кількість полів у формі підписки або її розташування.

Найчастіше маркетологи тестують такі елементи веб-сторінок:

  • Текст та зовнішній вигляд конверсійних кнопок, а також їхнє розташування.
  • Заголовок та опис продукту.
  • Розміри, зовнішній вигляд та розташування конверсійних форм.
  • Макет та дизайн сторінки.
  • Ціну товару та інші елементи бізнес-пропозиції.
  • Зображення товарів та інші ілюстрації.
  • Кількість тексту на сторінці.

Які інструменти спліт-тестування використовувати

Щоб виконати A/B-тестування, маркетологу необхідно скористатися одним із спеціалізованих сервісів. Найбільш затребуваним є Content Experiments компанії Google, доступний користувачам системи Analytics. До середини 2012 року цей інструмент називався Google Website Optimizer. З його допомогою можна протестувати різні елементи сторінки, включаючи заголовки, шрифти, конверсійні кнопки та форми, зображення тощо. Сервіс Content Experiments залишається безкоштовним, що стосується його основних переваг. До його недоліків належить необхідність роботи з HTML-кодом.

Також ви можете використовувати для проведення спліт-тестування такі російські та іноземні інструменти:

  • Optimizely – найбільш популярний у буржунеті платний сервіс A/B-тестування. Вартість його використання становить від 19 до 399 доларів США, залежно від типу передплати. До переваг даного сервісувідноситься можливість створення експериментів у візуальному інтерфейсі, що позбавляє маркетолога необхідності працювати з HTML-кодом тестованих сторінок.
  • RealRoi.ru – ще один вітчизняний сервіс, який дозволяє проводити А/Б-тестування. Серед головних плюсів можна виділити те, що він безкоштовний і дуже простий у використанні. Про те, як він працює, можна докладно подивитися на наступному відео:

  • Visual Website Optimizer – платний сервіс, що дозволяє тестувати різні елементи сторінки. Щоб використовувати цей інструмент, маркетолог повинен мати навички роботи з HTML-кодом. Вартість передплати становить від 49 до 249 доларів.
  • Unbounce – сервіс, призначений для створення та оптимізації лендінгів. У тому числі він дозволяє виконувати A/B-тестування. Вартість використання складає від 50 до 500 доларів на місяць. Вітчизняний аналог – LPGenerator. Цей сервіс дозволяє тестувати лише створені за його допомогою сторінки.

Як провести A/B-тестування за допомогою Content Experiments

Сервіс "Експерименти" Google Analytics дозволяє одночасно перевірити ефективність п'яти варіантів сторінки. Використовуючи його, маркетологи можуть виконувати A/B/N-тестування, що відрізняються від стандартних A/B-експериментів, можливістю стежити за ефективністю декількох нових сторінок, кожна з яких може мати декілька нових елементів.

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

Щоб провести спліт-тестування за допомогою Content Experiments, виконайте такі дії:

  1. Увійдіть до облікового запису Google Analytics, виберіть сайт, ефективність якого потрібно перевірити. Після цього виберіть меню "Поведінка - експерименти".

  1. Введіть у відповідну форму URL сторінки, яку ви тестуватимете, і натисніть кнопку «Почати експеримент».

  1. Виберіть назву та мету тестування. Визначте відсоток трафіку, який бере участь у експерименті. Вирішіть, чи ви хочете отримувати сповіщення про хід тестування на електронну пошту. Натисніть кнопку «Далі» після вибору потрібних параметрів.

  1. Виберіть сторінки, які беруть участь у тестуванні. Додайте їх у відповідні форми та натисніть «Далі».

  1. Створіть код експерименту. Якщо ви не знаєте, як вставити його на сторінку, виберіть «Надіслати код веб-майстру». Якщо вас не кидає в піт при згадці HTML-коду, виберіть варіант "Вставити код вручну".

Вибирайте «Вставити код вручну», якщо вмієте поводитися з HTML-кодом

  1. Скопіюйте зазначений на попередній ілюстрації код та вставте його у вихідний код контрольної сторінки. Код має бути вставлений безпосередньо після тега . Після цього натисніть кнопку «Зберегти зміни».

  1. Перевірте наявність коду тестування на контрольній сторінці та натисніть кнопку «Почати експеримент». Зверніть увагу, що код необхідно додати тільки на контрольну сторінку.

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

Ідеї, ефективність яких варто обов'язково перевірити за допомогою спліт-тестування

Вище неодноразово зазначалося, що A/B тестування допомагає збільшити ефективність веб-сторінок. Щоб цей маркетинговий метод дав результат, маркетолог повинен генерувати ідеї, здатні позитивно впливати на ті чи інші метрики сайту. Не можна просто брати будь-які зміни зі стелі, впроваджувати їх та тестувати ефективність. Наприклад, навряд чи метрики сайту зміняться, якщо ви просто вирішите змінити фон сторінки з блакитного на салатовий.

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

  • Видаліть зайві поля з конверсійної форми. Можливо, ваші потенційні передплатники не хочуть розкривати свої паспортні дані.
  • Додайте на конверсійну сторінку слова "безкоштовно" або free. Звичайно, аудиторія знає, що передплата на розсилку є безкоштовною. Але іноді слово free творить справжні дива, адже дармовий оцет солодкий.
  • Опублікуйте на посадочній сторінці відео. Зазвичай це позитивно впливає на ряд метриків, включаючи показник відмов, коефіцієнт конверсії та час перебування на сторінці.
  • Збільште термін, протягом якого користувачі можуть безкоштовно випробувати ваш продукт. Це простий і ефективний спосібзбільшення конверсій для компаній, що продають ПЗ та веб-сервіси.
  • Експериментуйте із кольором конверсійних кнопок. У деяких випадках добре працюють кнопки агресивного червоного кольору. Однак іноді вони дратують користувачів. Використовуйте A/B тест, щоб знайти найбільш ефективний колір кнопки для вашого сайту.
  • Пообіцяйте бонуси першим 10 або 100 покупцям (передплатникам). Не поспішайте видаляти цю обіцянку навіть після завершення акції. Багато користувачів не розраховують увійти до числа щасливчиків, проте все одно підсвідомо реагують на вигідну пропозицію.

Як і навіщо тестувати різні варіанти сторінок

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

Щоб протестувати ту чи іншу зміну, необхідно створити новий варіант сторінки та зберегти старий. Обидва варіанти повинні мати різні URL-адреси. Після цього слід скористатися одним із сервісів для проведення спліт-тестів, наприклад Content Experiments. Оцінку результатів тестування можна проводити щонайменше за два тижні після запуску експерименту.

Як ви вважаєте, чи варто проводити A/B тести? У яких випадках цей маркетинговий метод залишається марною тратою часу?

kak-провести-a-b-тестування