Брудний посуд тестування web-проектів

Зміст статті

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

ТЕСТУВАЧ – ЦЕ ОСТАННЯ ІНСТАНЦІЯ. ЯКЩО ТИ НЕ ЗНАЙДЕШ БАГ, ТО ЙОГО ВЖЕ НІХТО НЕ ЗНАЙДЕ, — ПЕРШЕ НАВЧАННЯ ТЕХНІЧНОГО ДИРЕКТОРА.

І ось web-система готова. Тестувальник приступає до пошуку багів. Тестування сайту можна розбити на три етапи: тестування на відповідність ТЗ та Стандартам, тестування верстки та спроби поламати web-систему.

Тестування на відповідність ТЗ та Стандартам

Це основний етап тестування. Перша проблема, яка постає перед тестувальником – розібратися у ТЗ. Ось фрагмент ТЗ, що описує календар подій на сайті www.5chka.com (сайт мережі магазинів «П'ятірочка»):

ВІДДІЛИТИ ЯК-ТО ВІЗУАЛЬНО

«Сутності «Подія» на сайті відповідає підрозділ «IR Events Calendar» у розділі «Investor Relations». Його індексна сторінка є списковою, на ній розміщуються календар подій на поточний місяць і список коротких описів подій. Календар є таблицею чисел поточного місяця. Якщо для деякого числа місяця існує подія з датою, що відповідає даному числу, то число місяця є посиланням на:

- сторінку повного опису цієї події, якщо в системі існує тільки одна подія з такою датою; - на індексну сторінку підрозділу "IR Events Calendar" зі списком коротких описів подій на обрану дату.

Також календар містить посилання для перемикання на наступний/попередній місяці.

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

- дату події; - заголовок події; — посилання на сторінку повного опису цієї події (якщо поле «текст» цієї події не порожнє)».

Або складніший приклад. Є інтернет-магазин. Його каталог має таку структуру: існують каталоги та підкаталоги в них (вкладеність необмежена), у каталогах та підкаталогах існують групи товарів, у групах товарів – товари, у товарів – параметри. При цьому жодна з перерахованих вище сутностей (крім товарів і параметрів) на сайті не виводиться. А виводяться на сайті образ каталогу (2 рівні вкладеності) та образи груп товарів. З якихось спонукань так зроблено – питання десяте, а заплутатися тут дуже легко.

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

Тестований календар

У ТЗ описані всі сутності, робота з ними та те, як вони мають виводитися на сайті (у «front'і»). У різних web-системах бувають різні сутності, і з ними відбувається по-різному. Також ТЗ описує можливості адміна: чи можна додавати нові сторінки до структури сайту, чи можна їх редагувати, змінювати порядок їхнього прямування тощо. Аналогічно відбувається перевірка стандартів.

У Стандартах описані аспекти роботи web-системи, які однакові всім проектів.

Тестування верстки

Тестування верстки, у свою чергу, розбите на два етапи: верстка динамічного та статичного контенту. Верстка динамічного контенту (тобто висновок сутностей)тестується на попередньому етапі (на відповідність ТЗ). Верстку ж статичного контенту можна назвати «загальною» версткою, так як до неї відноситься і загальне графічне обваження сайту.

  • Internet Explorer версії 5.0 і вище
  • Mozilla Firefox 1.0.1 та вище
  • Mozilla 1.3 та вище
  • Opera 7.54 і вище (вкрай рідко opera 6.0)

Ще півроку тому у цьому списку був присутній Netscape 7.0, а іноді клієнти (особливо європейські та міжнародні компанії) вимагають Safari. Верстка в різних браузерах може відрізнятися разючим чином. Простий приклад: FireFox та Internet Explorer (два найпопулярніші браузери на сьогоднішній день) по-різному обробляють внутрішній і зовнішній відступи елементів сторінки.

FireFox та Internet Explorer - відступ елементів і самі елементи відображаються по-різному

Детальна інформація про знайдені помилки Початковий код з описом помилок

Найчастіше валідатор дозволяє виявити приховані помилки, які можуть виявитися лише за певного збігу обставин. Наприклад, для новин виводяться Заголовок, Картинка та Анонс. І при довжині анонсу першої новини понад 300 символів картинка другої новини кудись «їде».

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

Спроби поламати web-систему

Є легенда про тестувальника. Дівчина влаштовувалась тестувальником у якусь компанію, і її попросили продемонструвати здібності до тестування. Дівчина підійшла до настільної лампи, вимкнула її з розетки, поставила вимикач у положення між"ввімкнено" і "вимкнено" і встромила вилку назад в розетку. Лампа перегоріла і дівчину взяли на роботу. У хорошого тестувальника повинен бути дар ламати все, чого він не доторкнеться. Тому що якщо у web-системи є слабке місце, легкий удар в яке «впустить» її, цей удар обов'язково відбудеться.

Тестовий контент

Окремою проблемою постає питання про те, як має виглядати тестовий контент. Рекомендуємо дотримуватись двох простих правил:

  1. Тестовий контент має бути коректним з морально-етичної точки зору — він не повинен містити слів та виразів на межі цензури, і тим більше нецензурних (ніж нерідко грішать розробники та тестувальники). В ідеалі, тестовий контент повинен лише показувати, що він є. Наприклад, для новин варто задавати параметри наступного виду. Заголовок - "я заголовок новини", Анонс - "а я - її анонс", Текст - "а я текст новини, я повинен бути більш-менш довгим, тому що так воно зазвичай і буває ..." і все в такому дусі. Звичайно, з деякими варіаціями, щоб відрізняти одну новину від іншої.
  2. Тестовий контент повинен явно відрізнятись від реального контенту. Наведений приклад із новиною в цьому плані не дуже добрий. Він не впадає у вічі. Питання, як виділити тестовий контент, вирішується «за ситуацією». Наприклад, якщо новина має ще й поле Картинка, то достатньо всім тестовим новинам задати яскраву картинку (яка вирізняється з дизайну) з написом «test». Або можна просто починати всі поля префіксом AHTUNG! TEST!» чи подібним.

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

Систематизація багів, bug-tracking

І ось нарешті всі баги знайдені. Тепер потрібно їхсистематизувати. І тому існують звані «баг-трекери» – програми, які ведуть історію багів. Найчастіше баг-трекери є web-системами, влаштованими за принципом форумів або блогів. Розберемося в систематизації багів на прикладі баг-трекера Mantis.

Перший рівень систематизації багів – це проекти (сайти). Цілком логічно відокремлювати баги одного сайту від багів іншого сайту. До проекту прив'язані баги, які мають ще кілька рівнів систематизації. На них зупинимося докладніше.

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

Форма редагування даних бага з вибором статусу

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

Приклад 1: Новини мають виводитися у хронологічному порядку, але вони виводяться хаотично – явний баг програмування.

Приклад 2: Заголовок новини має бути виділений жирним шрифтом, а виділений курсивом – явний баг верстки.

Приклад 3: Для новин повинен виводитись анонс, але він не виводиться. Можливо, програміст забув вивести анонс, а можливо, верстальник неправильно його оформив і через помилку на рівні HTML анонс не відображається.

Список багів у Mantis'і

Типові баги

Для початку трохи статистики. Незалежні статистичні дослідження у компанії DEFA Gruppe виявили кілька цікавих фактів:

Топ типових багів

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

Два слова про автоматизацію процесу тестування. Жодна програма не здатна протестувати сайт. Тестування – це творчий процес. Єдине, що можна автоматизувати, – це перевірка верстки на відповідність стандартам W3C. Ну і, мабуть, тестування вразливості сайту (SQL-ін'єкції, DoS-атаки тощо).

І насамкінець народна мудрість: якщо тебе не люблять розробники, значить, ти — хороший тестувальник!