Про кнопки, как правило, легко забыть. Кнопка "Сохранить" настолько универсальна, что кажется, что она просто не может не сработать. Однако игнорирование тестирования кнопок на странице может привести к игнорированию багов. Недавно мне рассказали о тестировании функциональности существующей веб-страницы. Новая фича отлично работала, но команда забыла проверить кнопку "Удалить". Оказалось, что разработчики забыли добавить действие удаления, и кнопка делала ничего!
Иногда среди нас возникают споры, что такое тестирование, и каким лексиконом пользоваться, говоря о разных его аспектах. Лично я не особо заморачиваюсь с этими вопросами, но есть одна штука, которая, по моему опыту, истинна: по своей сути любое тестирование – это исследовательское тестирование. Нельзя найти ничего интересного в продукте, не исследуя его.
Это верно вне зависимости от того, каким видом тестирования вы занимаетесь. Размышляя о тестировании, требующем глубоких технических навыков, мы полагаем, что оно не особенно требует исследования, но лично я так не думаю. К примеру, я много тестирую 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, нормативным документам ФСТЭК России и пр.). Опыт работы Испытательной лаборатории, проводящей такие оценки позволил сформулировать основные проблемные технические моменты, которые могут возникнуть в ходе такой оценки. Владислав подробно рассмотрел, как правильно подготовить свой продукт к процедуре оценки соответствия, какие тесты необходимо проводить перед передачей материалов в Испытательную лабораторию, а также типовые ошибки, допускаемые разработчиком и пути их разрешения.
Были ли у вас когда-либо трудности с объяснением возможного бага разработчику, архитектору, проектному менеджеру? Бывает ли, что вас не понимают, или вы не понимаете других участников команды, обсуждая систему проекта или другие абстрактные концепции? Вы не одиноки. Большие и сложные системы влекут за собой возможность абсолютного отсутствия единства их понимания среди коллег. Эта статья рассматривает использование символов и рисунков как инструмента, который поможет вам понимать и объяснять сложные системы.
На днях меня вновь спросили "Когда заказчик спрашивает, сколько времени займет тестирование нашего проекта, что мне ему отвечать?"
Простейший ответ, который я могу предложить, таков: если тестирование – часть процесса разработки, то оно займет ровно столько же времени, сколько разработка. Это связано с тем, что эффективное и продуктивное тестирование не разделено с разработкой – оно встроено в разработку.
Когда мы разрабатываем программный продукт или услугу, мы создаем дизайны, прототипы, функции, модули, компоненты, интерфейсы, интегрированные компоненты, сервисы, системы целиком… С каждым созданным нами элементом ассоциируется какой-либо уровень риска – возможности возникновения проблем. Дабы преуспеть, каждый элемент системы должен вписываться в общую картину совместно с другими элементами, и удовлетворять запросам тех, кто использует и создает систему.
Тестировщик всегда работает в условиях недостатка времени: беклог не уменьшается, релиз на носу, а протестировать нужно еще многое. Чтобы обеспечить качество продукта, нужно постоянно повышать эффективность собственной работы. Один из способов - освоить некоторые инструменты, облегчающие рутинные действия в тестировании.
