Меня недавно спросили, занимаюсь ли я исследовательским тестированием API, и как именно я это делаю. Вот мой ответ.
Прикладной программный интерфейс (API) – это средство, при помощи которого мы можем использовать ПО для отправки команд продукту, чтобы он сделал нечто требуемое. Мы тестируем и API как таковое. Интерфейсы – это одно из измерений/факторов/элементов продукта. В широком смысле мы не просто тестируем API – мы используем их для контроля и наблюдения за продуктом, чтобы узнать о нем много интересного и нового.
Про кнопки, как правило, легко забыть. Кнопка "Сохранить" настолько универсальна, что кажется, что она просто не может не сработать. Однако игнорирование тестирования кнопок на странице может привести к игнорированию багов. Недавно мне рассказали о тестировании функциональности существующей веб-страницы. Новая фича отлично работала, но команда забыла проверить кнопку "Удалить". Оказалось, что разработчики забыли добавить действие удаления, и кнопка делала ничего!
Иногда среди нас возникают споры, что такое тестирование, и каким лексиконом пользоваться, говоря о разных его аспектах. Лично я не особо заморачиваюсь с этими вопросами, но есть одна штука, которая, по моему опыту, истинна: по своей сути любое тестирование – это исследовательское тестирование. Нельзя найти ничего интересного в продукте, не исследуя его.
Это верно вне зависимости от того, каким видом тестирования вы занимаетесь. Размышляя о тестировании, требующем глубоких технических навыков, мы полагаем, что оно не особенно требует исследования, но лично я так не думаю. К примеру, я много тестирую API и работаю над курсами, обучающими API-тестированию. Это тестирование тоже требует исследовательского подхода!
Множество инструментов может помочь вам с тестированием API, и я пользуюсь многими из них. позвольте внести ясность: использование инструментов не отменяет исследования. Я находил в API множество багов, но сделал я это совсем не способом "заставить инструмент прочитать спецификацию в Swagger, а потом нажать на запуск". Я сделал это, изучая API. Большая часть инструментов для тестирования API направлена на то, чтобы помочь вам настроить автоматизированный регресс. У регрессионного тестирования есть свои задачи и своя польза, но не забывайте, что те же самые инструменты могут помочь вам при исследовании вашего API.
Я размышлял о багах, которые я нашел в API в ходе последних тест-сессий, и обнаружил, что их можно разделить на несколько категорий. С моей точки зрения, эта категоризация демонстрирует, насколько тестирование API требует исследовательского подхода.
В начале 2019 года мы (совместно с порталами Software-Testing.ru и Dou.ua) провели исследование уровня оплаты труда QA-специалистов. Теперь мы знаем сколько стоят услуги тестировщиков в разных уголках планеты. А ещё мы знаем какими знаниями и опытом должен владеть QA-специалист, чтобы сменить душный кабинет и скромный оклад, на пляжный шезлонг и толстую пачку валюты. Хотите узнать обо всём подробнее? Читайте нашу статью.
Итак… Представьте себе ситуацию, вы пришли на собеседование и в ваш адрес звучит вполне стандартный вопрос об «Ожидаемом уровне заработной платы». Как тут не прогадать с ответом? Кто-то начнёт отталкиваться от ЗП на последнем месте работы, кто-то от средней ЗП по данной вакансии в Москве, кто-то за основу возьмёт уровень оклада, которым вчера за рюмкой чая хвастал ваш знакомый QA-инженер. Но согласитесь, как-то это всё расплывчато, хотелось бы знать себе цену наверняка.
Поэтому любой заинтересованный в деньгах тестировщик иногда задаёт следующие вопросы:
Сколько я стою как специалист?
Какие навыки нужно развить, чтобы повысить свою ценность для работодателя?
Не стану ли я получать больше, сменив офисную работу в Барнауле на удалёнку в Москве?
Виктория Соковикова, Тест-аналитик at «Лаборатория качества»
Начнём со сладкого и приведём примеры из практики тестирования.
Представьте себе готовый к запуску интернет-магазин. Ничего не предвещает беды. Маркетологи разработали стратегию продвижения, были написаны статьи в профильные интернет-ресурсы, оплачена реклама. Руководство ожидало до 300 покупок еженедельно. Проходит первая неделя, менеджеры фиксируют 53 оплаты. Руководство магазина в ярости...
Менеджер проекта бегает в поисках причин: непродуманность usability? нецелевой трафик? что-то еще? Начали разбираться, изучили данные системы аналитики. Оказалось, что до оформления заказа дошли 247 человека, а оплатили только 53.
Эта история повторяется вновь и вновь – коллега говорит мне, что сотрудничает с организацией, обучая ее разработчиков тестированию. Поначалу это звучит, как отличная идея – хотя большинство разработчиков и так достаточно хорошо тестируют то, что должны тестировать разработчики, особенно если они сотрудничают друг с другом и проводят ревью своей работы.
Однако это не то тестирование, на которое нацелен тренинг. Оказывается, что разработчиков обучают высокоуровневому интеграционному и системному тестированию – видам глубокого тестирования, требующим значительных доменных знаний и существенного отхода от образа мышления разработчика. Зачем разработчикам этот тренинг? Затем, что организация избавилась от тестировщиков, которые занимались этим ранее, и надеется, что теперь этим займется разработка.
Публикуем доклад Владислава Савченко «Сертификация с точки зрения разработчика», собравший много хороших отзывов на прошлой конференции TestCon Moscow.
Современные разработчики всё больше сталкиваются с техническими вопросами в части оценки соответствия их изделий требованиям безопасности (соответствия стандартам PCI DSS, нормативным документам ФСТЭК России и пр.). Опыт работы Испытательной лаборатории, проводящей такие оценки позволил сформулировать основные проблемные технические моменты, которые могут возникнуть в ходе такой оценки. Владислав подробно рассмотрел, как правильно подготовить свой продукт к процедуре оценки соответствия, какие тесты необходимо проводить перед передачей материалов в Испытательную лабораторию, а также типовые ошибки, допускаемые разработчиком и пути их разрешения.
Были ли у вас когда-либо трудности с объяснением возможного бага разработчику, архитектору, проектному менеджеру? Бывает ли, что вас не понимают, или вы не понимаете других участников команды, обсуждая систему проекта или другие абстрактные концепции? Вы не одиноки. Большие и сложные системы влекут за собой возможность абсолютного отсутствия единства их понимания среди коллег. Эта статья рассматривает использование символов и рисунков как инструмента, который поможет вам понимать и объяснять сложные системы.
