Чем вооружен современный тестировщик?

Знаете, что общего между хирургом и тестировщиком? Оба ищут проблемы там, где их быть не должно (кажется, такое сравнение вполне уместно). Тестирование – это не просто поиск багов, это своего рода «медицинский осмотр» программного продукта, который помогает убедиться, что всё работает как надо, а если что-то пошло не так – выявить это до того, как об этом узнает пользователь.

В современной разработке тестирование играет роль того самого друга, который честно скажет, что с твоим кодом что-то не так. Оно помогает командам выпускать более стабильные продукты, экономить деньги (поверьте, фиксить баги в проде – то еще удовольствие) и сохранять репутацию компании. А главное – спокойный сон всей команды разработки.

Основные типы тестирования ПО

Думаю, вы уже догадались, что тестирование – это не просто тыкать кнопки и надеяться на чудо (хотя, признаться, иногда работает и такой подход). На самом деле это целый зоопарк различных видов проверок, каждый из которых отвечает за свой аспект качества продукта.

Представьте, что вы проверяете новый автомобиль. Одно дело – убедиться, что руль крутится и педали нажимаются (это наше функциональное тестирование), и совсем другое – проверить, как машина ведет себя на скорости 180 км/ч или в -40°C (привет, нефункциональное тестирование). А еще нужно убедиться, что после замены колес машина не развалится (регрессионное тестирование) и что все детали работают вместе (интеграционное тестирование).

Давайте рассмотрим каждый тип поподробнее, а то я уже увлекся автомобильными аналогиями.

Функциональное тестирование

Если отбросить умные слова, функциональное тестирование – это проверка того, что программа делает то, что должна (кажется, звучит логично, не так ли?).

Представьте, что вы тестируете кофемашину: кнопка «эспрессо» должна выдавать эспрессо, а не капучино или, того хуже, апельсиновый сок. В мире ПО это работает так же – мы проверяем, что при нажатии на кнопку «Отправить» сообщение действительно отправляется, а не удаляется, что калькулятор складывает числа правильно, а не умножает их на случайное число для развлечения.

Нефункциональное тестирование

А вот тут начинается самое интересное – то, о чем часто забывают, увлекшись проверкой функционала. Нефункциональное тестирование отвечает на вопрос «А насколько хорошо это работает?» (и иногда ответы бывают… неожиданными).

Представьте, что ваше приложение работает идеально, но загружается со скоростью старого модема из 90-х, или падает под нагрузкой в пять пользователей, или его может взломать младшеклассник, изучивший основы HTML. Вот тут-то и приходит на помощь нефункциональное тестирование – проверка производительности, безопасности, удобства использования и прочих «нефункциональных» радостей.

Другие виды тестирования

Держитесь крепче, сейчас будет небольшой парад остальных видов тестирования (спойлер: их немало):

• Смоук-тестирование – быстрая проверка, что приложение хотя бы запускается и не падает сразу (название пошло от проверки электроприборов – если не дымится при включении, уже хорошо)
• Sanity-тестирование – проверка, что разработчики не сошли с ума и новый функционал работает как задумано (да, такое тоже бывает нужно)
• Бета-тестирование – когда мы выпускаем продукт «в народ» и ждем, что пользователи найдут то, что мы пропустили (а они найдут, поверьте)

Инструменты для тестирования ПО

Знаете, что общего между тестировщиком и спецназовцем? Правильно – арсенал! Только вместо оружия у нас инструменты (хотя иногда хочется и оружие, особенно когда находишь баг за 5 минут до релиза).

Современный тестировщик без инструментов – как хирург с тупыми ножницами: вроде и может работать, но результат будет… специфическим. Давайте пройдемся по нашему арсеналу, который поможет делать нашу работу эффективнее (и сохранять рассудок в процессе):

• Баг-трекеры – наши цифровые дневники страданий, куда мы скрупулезно записываем все найденные «особенности» продукта (читай: баги)
• Системы автоматизации – потому что даже самый терпеливый тестировщик устанет кликать одно и то же по 100 раз
• Инструменты мониторинга – чтобы понимать, почему всё внезапно начало работать медленно (спойлер: обычно это не само починится)
• Средства для нагрузочного тестирования – когда нужно проверить, выдержит ли ваш сайт наплыв покупателей в черную пятницу

А теперь давайте копнем глубже и посмотрим на каждый тип инструментов подробнее. Поверьте, это будет интересно (по крайней мере, интереснее, чем писать баг-репорты).

Инструменты для функционального тестирования

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

Лидер парада – Selenium – широко распространенный инструмент для автоматизации тестирования веб-приложений. Он специализируется на работе с веб-браузерами, позволяя эмулировать действия пользователя на веб-страницах, хотя и не подходит для тестирования десктопных или мобильных приложений. JUnit для Java-разработчиков – как верный спутник, предоставляющий надежную среду для написания и запуска юнит-тестов с четким отображением результатов. TestComplete – для тех, кто любит GUI и готов за это платить. А для любителей «пощупать руками» есть Postman – незаменимый помощник в тестировании API (и да, он правда помогает, а не просто красиво выглядит).

Инструменты для нагрузочного тестирования

Представьте, что ваш сайт – это ночной клуб. JMeter в этом случае – как профессиональный вышибала, который проверяет, сколько людей может войти, прежде чем начнется давка (кажется, метафора немного пугающая, но точная).

Apache JMeter – настоящий ветеран нагрузочного тестирования. Бесплатный, опенсорсный и пугающий новичков интерфейсом из 2000-х. LoadRunner – профессиональный инструмент корпоративного уровня, предоставляющий расширенный функционал: поддержку широкого спектра протоколов, продвинутые средства анализа результатов и мониторинга производительности, а также мощные возможности для распределенного тестирования. Gatling – для хипстеров от тестирования, которые пишут сценарии нагрузки на Scala (и почему-то этим гордятся). K6 – новичок в этой компании, но уже успел всем понравиться своей простотой и удобством.

Инструменты для безопасности

Тестирование безопасности – это как работа параноика-профессионала: нужно подозревать всё и всех (и чаще всего эти подозрения оправдываются, что немного пугает).

OWASP ZAP – настоящий швейцарский нож в мире безопасности. Бесплатный, открытый и пугающе эффективный. Умеет искать уязвимости так, что даже опытные разработчики начинают нервно поправлять галстук. Burp Suite – его старший брат, который просит деньги за свои услуги (и, надо признать, не зря). Acunetix – специализированный инструмент для автоматизированного сканирования веб-приложений, способный обнаруживать более 7000 веб-уязвимостей, включая XSS, SQL-инъекции и уязвимости в современных одностраничных приложениях (SPA). А Nmap – для тех, кто любит старую школу и командную строку.

Автоматизация тестирования

Представьте, что вы сотый раз за день проверяете одно и то же (нет, это не дежавю, это ручное тестирование). В какой-то момент ваш мозг начинает умолять: «Автоматизируй это!» И знаете что? Он прав!

Автоматизация – это как хороший помощник по хозяйству: не заменит вас полностью, но возьмет на себя всю рутину. Правда, есть нюанс: автоматизация требует времени на настройку (много времени, если честно), и не всё можно автоматизировать. Например, проверить, что кнопка синяя и красивая – можно, а вот действительно ли она красивая – уже сложнее (пока что ИИ не научился понимать эстетику).

К тому же, автоматизация – это инвестиция. Иногда написать и поддерживать автотесты дороже, чем просто взять и проверить всё руками. Особенно если ваш продукт меняется чаще, чем погода в Петербурге. Но когда автоматизация уместна – это просто песня!

Подходы к автоматизации

Давайте поговорим о подходах к автоматизации, или «как не превратить автотесты в полигон ядерных отходов» (да, такое тоже случается).

Data-Driven – когда ваши тесты питаются данными как информационный вампир. Одни и те же проверки, но с разными данными. Например, проверяем логин с сотней разных комбинаций логин/пароль (и да, кто-то реально пытался залогиниться как ‘admin/admin123’).

Keyword-Driven – для тех, кто любит порядок. Каждое действие описывается ключевым словом. Хорошо для не-программистов, но можно запутаться в терминах (особенно когда «нажать» и «кликнуть» – это разные действия).

Behavior-Driven (BDD) – когда ваши тесты читаются как книга: «Дано: я на главной странице, Когда: я нажимаю кнопку, Тогда: что-то происходит». Красиво, понятно менеджерам, но требует дисциплины в написании.

Диаграмма отображает результаты Data-Driven тестирования с частотой успешных и неуспешных попыток логина для различных комбинаций логин/пароль

Примеры автоматизированных тестов

Знаете, что общего между хорошим автотестом и хорошим анекдотом? Оба должны быть короткими, понятными и выполнять свою задачу. Давайте посмотрим на пару примеров (спойлер: они не очень смешные, зато полезные).

Вот классический пример: автоматизация проверки формы регистрации. Вместо того чтобы 100 раз вводить данные вручную, мы пишем тест, который проверит все валидации, граничные значения и специальные символы (потому что кто-то обязательно попытается использовать эмодзи в качестве пароля).

Или возьмем E2E-тесты для интернет-магазина: от входа на сайт до оформления заказа. Такие тесты экономят часы ручного тестирования и первыми кричат «Караул!», когда что-то ломается в боевом окружении.

Навыки и компетенции тестировщика

Знаете, каким должен быть современный тестировщик? Это что-то среднее между детективом, программистом и психологом (а иногда еще и экстрасенсом – особенно когда баг воспроизводится только по четным вторникам).

В наши дни уже недостаточно просто уметь находить баги – нужно понимать, как работает код, уметь писать автотесты, разбираться в базах данных и API. А еще желательно быть дипломатом, потому что объяснить разработчику, что его код работает не совсем так, как задумано – это отдельный вид искусства.

И да, если вы думаете, что тестировщику достаточно знать, где находится кнопка «Отправить баг-репорт» – у меня для вас не очень приятные новости. Современный тестировщик – это специалист-многостаночник, и сейчас мы разберем, почему.

Технические навыки

Помните времена, когда тестировщику достаточно было уметь включать компьютер? Так вот, эти времена прошли быстрее, чем модем на 56k (если кто помнит такой).

Современному тестировщику нужно:

• Знать SQL, чтобы понимать, куда и как утекают данные (и почему иногда они не утекают, хотя должны)
• Разбираться в API, потому что всё современное ПО общается через API (даже если об этом не знает)
• Понимать основы программирования – хотя бы для того, чтобы говорить с разработчиками на одном языке (а не делать вид, что понимаешь, о чём они)
• Уметь работать с системами контроля версий, потому что «а у меня на компьютере сохранено» – это не метод

Кажется, список получился внушительным. И это мы ещё не всё перечислили!

Soft skills

Знаете, что может быть важнее умения находить баги? Умение о них рассказывать так, чтобы разработчики не впадали в депрессию (да, такое тоже бывает).

В нашем арсенале soft skills должны быть:

• Коммуникативность – потому что «оно не работает» – это не баг-репорт, а крик души
• Внимательность к деталям – иногда баг прячется в одном пикселе или лишнем пробеле
• Критическое мышление – потому что «у меня работает» не значит «работает правильно»
• Эмпатия – нужно уметь понять и пользователя, который злится, и разработчика, который не спал три ночи

А ещё нужно уметь объяснять технические вещи простым языком – например, почему удаление всей базы данных одним кликом это не фича, а «небольшая проблема безопасности».

Освоить все эти навыки самостоятельно может быть непросто. Если вы хотите структурированно изучить тестирование или повысить свою квалификацию, обратите внимание на специализированные курсы для QA-инженеров. Там вы найдете программы разного уровня сложности: от базовых курсов для начинающих до углубленного изучения автоматизации тестирования.

Современные тренды в тестировании ПО

Помните, как раньше тестировали софт? А теперь забудьте – всё меняется быстрее, чем успеваешь обновить браузер (спойлер: он уже обновился, пока вы читали это предложение).

Искусственный интеллект врывается в тестирование как слон в посудную лавку – красиво, мощно и немного пугающе. AI-powered тестирование уже умеет генерировать тест-кейсы и предсказывать, где искать баги (хотя пока не умеет объяснять разработчикам, почему их код работает не так).

DevOps и непрерывное тестирование становятся нормой – теперь мы тестируем не «когда будет готово», а «пока пишется код». А тестирование микросервисов превратилось в отдельный вид искусства – попробуйте найти баг, когда у вас сотня сервисов общается между собой на разных языках!