Брудний посуд: тестування web-проектів
Зміст статті
Принципи роботи різних студій веб-дизайну можуть кардинально відрізнятися. Відрізняються пріоритети, відрізняються підходи. Але все зводиться до одного: баги є у всіх і з ними потрібно боротися.
ТЕСТИРОВЩИК - ЦЕ ОСТАННІЙ ІНСТАНЦІЯ. ЯКЩО ТИ НЕ ЗНАЙДЕШ БАГ,
ТО ЙОГО ВЖЕ НІХТО НЕ ЗНАЙДЕ, - ПЕРШЕ НАСТАВЛЯННЯ ТЕХНІЧНОГО ДИРЕКТОРА.
І ось web-система готова. Тестувальник приступає до пошуку багів. Тестування сайту можна розбити на три етапи: тестування на відповідність ТЗ і Стандартів, тестування верстки і спроби поламати web-систему.
Тестування на відповідність ТЗ і Стандартів
Це основний етап тестування. Перша проблема, яка постає перед тестувальником - розібратися в ТЗ. Ось фрагмент ТЗ, що описує календар подій на сайті
www.5chka.com (Сайт мережі магазинів «Пятерочка»):
ВІДОКРЕМИТИ ЯКОСЬ ВІЗУАЛЬНО
«Сутності« Подія »на сайті відповідає підрозділ« IR Events Calendar »в розділі« Investor Relations ». Його індексна сторінка є облікової, на ній розміщуються: календар подій на поточний місяць і список коротких описів подій.
Календар являє собою таблицю чисел поточного місяця. Якщо для деякого числа місяця існує подія з датою, яка відповідає цьому числу, то дане число місяця є посиланням на:
- сторінку повного опису даної події, якщо в системі існує тільки одна подія з такою датою;
- на індексну сторінку підрозділу «IR Events Calendar» зі списком коротких описів подій на обрану дату.
Також календар містить посилання перехід до наступного / попередній місяці.
У списку коротких описів виводяться тільки активні (не приховати) події в хронологічному порядку. За замовчуванням виводяться 10 перших за датою подій, починаючи з поточної дати. Кожен блок короткого опису містить:
- дату події;
- заголовок події;
- посилання на сторінку повного опису даної події (якщо поле «текст» даної події не порожньо) ».
І це далеко не самий складний приклад. Також варто зауважити, що ТЗ пишуть живі люди, яким властиво помилятися. Тобто тестувальник повинен ще оцінювати адекватність ТЗ. Наприклад, в цьому фрагменті ТЗ не сказано, що має відбуватися з посиланнями «перехід до наступного / попередній місяці», якщо, наприклад, за всі попередні місяці немає жодної події.
Або більш складний приклад. Є інтернет-магазин. Його каталог має наступну структуру: існують каталоги і підкаталоги в них (вкладеність необмежена), в каталогах і підкаталогах існують групи товарів, в групах товарів - товари, у товарів - параметри. При цьому жодна з перерахованих вище сутностей (крім товарів і параметрів) на сайті не виводиться. А виводяться на сайті образ каталогу (2 рівня вкладеності) і образи груп товарів. З яких мотивів так зроблено - питання десяте, а заплутатися тут дуже легко.
Але припустимо, що ТЗ адекватно, і тестувальник розібрався у всіх його тонкощах. Тоді даний етап тестування стає досить банальним. На прикладі з календарем тестування виглядає так:
- йдеш в розділ investor relations / ir events calendar;
- читаєш, що «календар являє собою таблицю чисел поточного місяця», і дивишся, чи є описана таблиця, чи правильно вона складається (перевіряєш, наприклад, кількість днів у лютому в високосному / невисокосному році);
- перевіряєш, чи правильно формуються посилання на числа місяця (при цьому «тільки одна подія» означає або «всього одна подія», або «одне активне подія»);
- перевіряєш, як працює перемикання між місяцями (особливу увагу потрібно приділити переключенню «січня року x» на «грудня року x-1» і назад)
- і далі по тексту ...
тестований календар
У ТЗ описані всі сутності, робота з ними і те, як вони повинні виводитися на сайті (у «front`е»). У різних web-системах бувають різні сутності, і робота з ними відбувається по-різному. Так само ТЗ визначає повноваження адміністратора: чи можна додавати нові сторінки в структуру сайту, чи можна їх редагувати, змінювати порядок їх наслідком