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

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

 «Погане» ціле з «хороших» частин

Дані, які користувач вводить в програму, часто мають кілька складових, що утворюють разом ціле –  значуще для додатка. До кожної з частин можна застосувати традиційні техніки тест-дизайну, але варто подумати і над їх комбінуванням. Стандартний приклад тут – дата, яка складається з дня, місяця і року. До кожного з параметрів всередині дати можна застосувати класи еквівалентності і граничні значення, але ось як скласти саме ті комбінації з дня, місяця і року, які потрібно буде вводити в інтерфейсі? Один з підходів до складання негативних тестів – взяти «хороші» значення для кожного компонента і отримати з них «погану» дату. Наприклад, 31.02.2018 – невалідна дата, хоча всі її складові відносяться до позитивних значень, якщо розглядати їх окремо. Таке застосування причини-наслідку дозволить знайти нові баги там, де компоненти цілого задаються окремо один від одного. І звичайно, це не тільки дата.

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

Не варто недооцінювати стани та переходи

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

Спосіб здійснення дії або точки входу

Коли пишуть тести, де вводяться якісь дані, найчастіше ніяк не згадується спосіб введення. Проте він може бути важливий для виявлення певної кількості помилок. Чи можна ввести недозволені символи з клавіатури? А за допомогою копіювання і вставки? А якщо викликати ці операції з контекстного меню? Як щодо віртуальної клавіатури, голосового введення, перетягування (drag&drop)? Певні способи можуть дозволити користувачеві обійти обмеження на введення. Точка входу або спосіб виклику функції, може мати значення. Варто перевірити кожен спосіб для кожної функції хоч би по одному разу. Це зручно робити за допомогою комбінаторних тестів, де спосіб здійснення тієї або іншої операції буде одним з параметрів.

Мобільні додатки: повертаємо екран

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

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

Веб-додатки: прості перевірки на безпеку

При тестуванні веб-додатків варто зробити прості перевірки на безпеку для текстових полів. Це легко, навіть якщо нічого не знати про те, чим і як займаються хакери. Є деякі «небезпечні» комбінації символів, які, скажімо, не бажано зберігати в базі даних, якщо ці значення потім показуються користувачу в текстовому вигляді на якомусь іншому екрані. До таких комбінацій відносять %3C%73%63%72%69%70%74%3E, <script>, /(\%27)|(\')|(\-\-)|(\%23)|(#)/ix, &ls та інші. 

Наприклад, якщо вийшло зберегти рядок виду <script>alert(“Hello!”)</script>, а потім на якійсь іншій сторінці, де вона повинна відображатися у вигляді тексту, ви побачите спливаюче вікно з текстом «Hello!», це означає, що пора заводити баг про безпеку і ставити йому severity вище, якщо це додаток публічно доступний. Коли ж захочеться складати такі тести свідомо, то подорож в захопливий світ тестування на проникнення можна почати з XSS і SQL-ін'єкцій.

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

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

Висновок

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