Сорвем пелену непонятности с терминов и определений видов тестирования, чтобы для вас это стало просто как кот чихнул!
Итак, пристегнулись, поехали от простого:
Функциональное (Functional)
Основной и важный вид тестирования, смотрим работоспособность заявленных фичей в соответсвии с требованиями или... здравым смыслом.
Сюда входят как позитивные так и негативные проверки, т.е. клацнули на кнопку заказа пиццы один раз после заполнения всех нужных полей или же бесконечно кликаете по ней в голодном экстазе, забыв заполнить пару обязательных полей, например, адрес доставки и телефон.
Пользовательского интерфейса (GUI)
Второй блок основных проверок на "красивость" - проверяем достаточно ли зеленит этот зеленый цвет на логотипе и совпадает ли он с тем, что наваял дизайнер (и чудно, если на макете будет указан код цвета, например, # 3CB371 или таки прекрасный MediumSeaGreen, дабы не потонуть в спорах с разработчиком обвиняя друг друга в неправильном цветовосприятии 🧐). Также бежим заводить "гуи" дефекты, если вдруг фото товаров расплющило или покосило, а названия недостаточно italic и недостаточно Times New Roman.
//следующие виды тестирования выполняются опытными и/или узкоспециализированными тестировщиками, но если вы начинающий, вам все равно следуют про них знать - и на собеседовании не растеряетесь, и кто знает, вдруг именно вы поможете отловить интересный нефункциональный баг.//
Проверка эргономичности/юзабили (Usability)
Возможно, вы скажите, а в чем же разница с GUI тестированием, сейчас всё разрулим - если для юай важно, чтобы все было сделано по мокапам/макетам/требованиям, то для юзабилити важно, насколько удобно будет пользователю.
Пример,
🔸гуи - по требованиям баннер регистрации должен быть внизу странички и светло-желтого цвета, проверяем, что так оно и есть;
🔸юзабилити - проверяем, удобен ли такой баннер регистрации конечному пользователю, скорее всего не очень - ведь он внизу и до него можно и не дойти, а светло-желтый цвет совсем не привлекает внимание. Дружелюбней к пользователю (user friendly) будет расположить его сверху и сделать красным.
Существуют общие стандарты и гайдлайны для тестирования юзабилити, а так же на проектах проводятся сессии юзер тестирования, на которые приглашают реальных пользователей или совершенно незнакомых с приложением людей, чтобы получить отзывы "с полей".
Вынесу пару общих идей юзабилити для понимания:
🔜 до результата должно быть минимальное количество действий /переходов. Если голодный пользователь, хочет заказать пиццу, так дайте же ему это сделать коротким путем - не водите как Красную Шапочку через лес страничек и кнопок. На одной страничке выбрали - на другой сразу все заполнили и подтвердили заказ.
🛒 все должно быть максимально интуитивно понятно и привязано к реальной жизни. Кнопку для перехода к оформлению выбранных покупок обычно обозначают иконкой корзины или тележки, а не рандомным синим ромбиком.
🍞 простая навигация и возможность вернуться на любой из предыдущих шагов, например, хороший тон оставлять "хлебные крошки" (breadcrumbs), это навигационная цепочка в верхней части сайта, показываем путь от главной странички до текущего местоположения.
🤷♀ тексты должны быть информативны и ясны, если юзер получает ошибку с мыслями "что-то на татарском", значит надо срочно менять текстовки (если, конечно, приложение изначально не на татарском).
Доступности (Accessibility)
Среди нас есть люди с особыми потребностями, поэтому мир станет чуточку лучше и добрее, если мы учтем эти потребности и при разработке ПО. Тут тоже существуют гайдлайны и требования, чтобы им могли пользоваться люди с проблемами зрения, слуха, физическими особенностями, которые не позволяют использовать обычные мышь и клавиатуру, или с когнитивными нарушениями.
Существуют легко выполнимые требования, например, шрифт хорошо читаем, достаточная контрастность (никакого мелкого темно-серого текста на светло-сером фоне), но есть и дополнительная функциональность, которую следует прикрутить:
🔊 возможность озвучивать все элементы в приложении при наведении и клике на них;
🎤 управление голосом;
👁🗨 все картинки, аудио или видео должны быть продублированы Alt-текстом (альтернативный текст);
🔎 возможность увеличивать текст или страничку без того, чтобы страдал внешний вид или положение остальных элементов;
🦾 возможность использовать только клавиатуру без мыши (вспоминаем про чекбоксы, линки, для которых нужна мышь);
В целом удобная навигации и понятная логика управления положительно отразится и на общем уровне юзабилити для всех пользователей без исключения.
Интернационализации (Internationalization / i18n)
Такое тестирование проверяет, как хорошо задизайнено и разработано приложение с учетом потенциального использования множества других локалей (читай языков) в будущем. Это означает, что данное тестирование проводится на ранних этапах разработки приложений, и даже если у нас пока еще используется только один язык. Что мы, как куа, должны предусмотреть и проверить:
🔣 поддержка Unicode, и европейских языков, и азиатских, где есть горизонтальные письмена, возможность отображения справа налево.
📆 поддержка различных форматов даты, календаря, формат чисел, сортировки, адресов, валют, имен, титулов и пр. (например, для США неделя начинается с воскресенья; в каких-то странах в ходу имена больше чем из двух частей; а индексы некоторых регионов могут содержать еще и буквы).
🧩 элементы завязанные на язык не должны быть захардкожены (т.е. не прописаны конкретными значениями в коде), гибкость и возможность использовать дополнительные библиотеки. Добавлю, что это касается не только текстовых элементов, но и мультимедийных - их должно быть легко заменить или поменять место расположения в соответствии с культурными и языковыми особенностями. //Пример, на сайте о здоровом образе жизни использован бэкграунд с фото девушек в открытых спортивных костюмах, в случае выхода на арабский рынок, должна быть возможность просто заменить фоновое фото для данного региона.//
Как же все это проверить, если доступа в код нет? Здесь на помощь придут консоли, devtools, proxy tools, через них можно пробовать подставлять символы или менять и двигать текст. Также можно поставить другой язык в системе (мобильная, декстоп ОС, язык браузера) и проверить, меняются ли форматы дат, времени, валюты и других измерений. Если есть поля ввода или загрузки текстовых документов - проверяем принятие и отображение различных символов, умляуты, иероглифов, диакритических знаков и пр. Проверить изменяются ли размеры кнопок и элементов при увеличении длинны слов, и каким образом будет перенесен или обрезан слишком длинный текст. А еще в таких случаях не бойтесь обращаться за помощью к команде разработки.
Локализации (Localization / l10n)
Вжух, и мы получаем конкретную новую локаль (язык) и идем в пляс. Необходимо будет проверить, что все части приложения переведены на нужный язык, и это не вызвало новых GUI багов (знание всех языков для тестирования локализации совсем необязательно; куа следит только за наличием переводов для приложения, а за правильность и качество отвечают переводчики). Тестирование локализации переплетается с тестирование интернационализации по той причине, что после добавления конкретной локали нам потребуется снова проверить для нее форматы дат, валют, адресов..., культурные аспекты - соответствует ли внешний вид и контент данному региону (этакая проверка на благопристойность 👀).
Вынесу статью на английском, в которой подробней разобраны i18n и l10n.
Совместимости (Сompatibility)
Как мы видим из названия - это тестирования совместимости нашего приложения с разным окружением.
Существуют различные подтипы:
~ кроссбраузерное
~ кроссплатформенное
~ аппаратная совместимость
~ совместимость баз данных
Разберемся на примере кроссбраузерного. Вряд ли вы хотите потратить бесконечность на тестирование на всех версиях всех существующих браузеров😵.
Шаг 1 - получить информацию о необходимых браузерах и версиях у заказчика, или если таковой нет, идем смотреть статистику использования для своей ЦА и/или региона на statcounter (или другой сайт, которому вы доверяете). Выбираем и согласовываем с заказчиком браузеры, например, можно взять два или три самых популярных варианта.
Шаг 2 - определиться какой браузер будет главный для тестирования, на остальных будем проводить только основные проверки + полное GUI тестирование, а также прогонять на них регрессию (конечно можно проводить полный скоуп проверок сразу на всех выбранных версиях, но не всегда на это хватает времени и бюджета).
Шаг 3 - поднять виртутальную машину, чтобы иметь у себя все необходимые конфигурации окружения (и не нужно удалять и заново ставить разные версии браузера у себя на компьютере). //про вируталочки уже писала здесь//
Вы великолепны!
Защищенности (Security)
Крутые ребята безопасники ищут уязвимости и анализируют риски взлома хакерами и утечки данных. Интересное и сложное направление, которое помогает защитить свои данные, денюжки и имидж.
По сути тестирование безопасноти заключается в попытке взломать приложение. 🚧Но для начала всегда нужно брать разрешение у начальства и заказчиков на то, чтобы провести какие-либо проверки на безопасность!🚧
Итак, для игры в мамкиного хацкера вам понадобится умение проводить
Сode injections - с помощью sql, php или др. языка, запускаем скрипт, который поможет получить нам доступ к секретным данным.
Сross-site request forgery - оборачиваем нехороший код в тег картинки и размещаем на сайте - ждем жертву, которая перейдет по нему.
Также есть server-side include injection, cross-site-scripting, обход авторизации и др.
Для интересующихся - существует такая организация как The Open Web Application Security Project (OWASP), и каждый год они публикуют top 10 уязвимостей.
Производительности (Performance)
Разделяют на различные подтипы, тут приведу 3 часто упоминаемых:
Нагрузочное - достаточно ли шустро будут загружаться картинки котиков при посещении сайта планируемым количеством пользователей.
Стрессовое - через какое количество одномоментных пользователей картинки котиков станут загружаться намного дольше, а через какое -сайт ляжет полностью.
Объемное - проверяем, как себя будет вести сайт при увеличении количества операций с загрузкой, редактированием и удалением кото-картинок пользователями.
Данное тестирование выполняется автоматизаторами с использованием специальных программ.
В разных классификациях встречаются еще некоторые дополнительные виды, но здесь я прошлась по тем, которые проводила сама или пересекалась на проектах.
//Даже если ваш скоуп не выходит дальше тестирования функциональности и гуи, не бойтесь делиться с командой своими мыслями о юзабилити или безопасности.//