Відмінності тестування web та desktop

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

Тестування UI сайту

"У нас були зміни лише на UI-ї, повністю регресію проганяти не будемо." - казали вони.

У Джеррі Вайнберга був чудовий розділ про "колиско́ві слова", і "лише" - одне з них. Щоразу як тестер чує "лише" - тестер починає нервувати. Або навпаки, радіти, бо в повітрі запахло багами :-)

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

Питання на співбесіді: Потестуйте логін-форму

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

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

Тому, на мою думку, першим тестом має бути перевірка від "доступу за дурно", тобто:
1. Спроба логіну із порожніми полями - нема доступу.

Далі, має бути перевірка "недоступу" за неповними креденшелами:
2. Спроба логіну з порожнім паролем та вірним логіном - нема доступу.

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

Сподіваюсь, комусь це пояснення допоможе!

Я особисто стикався з випадками, коли починали тестувати з пункта 3., забуваючи про 1. та 2., і баги, пов’язані з ними, вилазили аж за кілька місяців на продакшені, залишаючи систему вразливою, покладаючись тільки на те, що "злі хакери" не встигли нічого зробити.