Ответ
Наибольший профессиональный интерес представляют функциональное и UX/UI-тестирование, так как они напрямую влияют на качество продукта и пользовательский опыт.
Почему эти виды?
- Функциональное тестирование: Позволяет глубоко анализировать бизнес-логику, валидацию данных и интеграции, что критично для стабильности ядра продукта.
- UX/UI-тестирование: Дает возможность оценить удобство, интуитивность и соответствие интерфейса ожиданиям конечного пользователя.
Пример сценария ручного тестирования формы входа:
- Валидация полей: Проверка реакции на некорректный email, короткий пароль.
- Граничные значения: Ввод пароля максимально допустимой длины, проверка обрезки.
- Сообщения об ошибках: Ясность, однозначность и тональность системных сообщений.
- Юзабилити: Удобство ввода на мобильном устройстве, работа скринридеров.
Также ценю исследовательское тестирование (Ad-hoc) для поиска неочевидных дефектов за рамками формальных чек-листов.
Ответ 18+ 🔞
А, ну вот смотри, когда начинаешь ковыряться в тестировании, то понимаешь, что всякие там нагрузочные штуки — это, конечно, круто, но реально-то продукт держится на двух китах, блядь. Это функциональное и UX/UI-тестирование. Вот где собака зарыта, ёпта! Потому что если тут косяк — пользователь просто плюнет и уйдёт, а не станет разбираться, выдержит ли твоя база десять тысяч RPS.
А че они так важны-то, спросишь?
- Функциональное тестирование: Это ж основа основ, сука! Ты копаешься в самой сути — в бизнес-логике. Валидация данных, интеграции... Если тут хромает — всё, пиздец, ядро продукта сыпется, как карточный домик. Никакой красивый интерфейс не спасёт, если логика гонит хуйню.
- UX/UI-тестирование: А вот это уже про то, чтобы пользователь не орал "да что за пиздопроёбина!" через три секунды после открытия приложения. Оцениваешь, насколько всё удобно, интуитивно и соответствует ожиданиям. Без этого — хоть обосрись, а народ не пойдёт.
Вот, например, возьмём тупейшую форму входа. Казалось бы, что там тестировать? Ан нет!
- Валидация полей: Суём в поле email "ya@ebuchiy". Смотрим, что система скажет. Или пароль из одной цифры. Если молча проглотит — это пиздец, а не форма.
- Граничные значения: Вбиваем пароль длиной в километр, который только в спецификации разрешили. Не обрежется ли? Не сломается ли всё к хуям?
- Сообщения об ошибках: Это отдельная песня, блядь! Если после ввода "123" в поле пароль вылезет "Ошибка валидации поля P-12-A", то я, как пользователь, просто ебнусь. Сообщение должно быть человеческим, а не как из шизофренического бреда.
- Юзабилити: Ткнул пальцем с телефона — попал в кнопку? Для незрячих скринридер адекватно читает? Если нет — значит, ты создал барьер, пидор несчастный.
А ещё, между прочим, обожаю исследовательское тестирование (Ad-hoc). Это когда откладываешь все чек-листы в сторону и начинаешь просто тыкать во всё подряд, как обезьяна с гранатой. Часто самые сочные, ебучные баги на поверхности не лежат, а прячутся где-то в дебрях неочевидных сценариев. Вот их-то и ищешь таким методом научного, блядь, тыка.