Рим был построен не за один день, но хватило всего шести дней, чтобы он по случайности сгорел дотла в 64 году нашей эры. Он был заново отстроен с учетом пожарной безопасности. А когда в 1903 году при пожаре в театре "Ирокез" в Чикаго погибло 502 человека, уже в 1904 году нормы пожарной безопасности повысились. Пожар на фабрике "Трайангл" в Нью-Йорке (146 погибших) привел к основанию Нью-Йоркского Бюро пожарной безопасности, а Национальная Ассоциация Пожарной Безопасности сейчас поддерживает несколько сотен различных норм и требований – и многие из них появились вследствие особо трагичных пожаров. Люди учатся на трагедиях.
Наша компания разрабатывает систему КОМПАС-3D для построения трехмерных моделей и чертежей. Проект зрелый – в этом году ему исполнилось 30 лет. Над продуктом работают 9 команд в двух городах – Коломне и Рязани.
В системе автоматизированного тестирования мы используем Telegram для уведомлений, управления тестами и администрирования. Технически боты реализованы очень просто. Главная ценность заключается в их интеграции с системой автотестирования. Итак, что у нас делают Telegram-боты.
Меня недавно спросили, занимаюсь ли я исследовательским тестированием 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, нормативным документам ФСТЭК России и пр.). Опыт работы Испытательной лаборатории, проводящей такие оценки позволил сформулировать основные проблемные технические моменты, которые могут возникнуть в ходе такой оценки. Владислав подробно рассмотрел, как правильно подготовить свой продукт к процедуре оценки соответствия, какие тесты необходимо проводить перед передачей материалов в Испытательную лабораторию, а также типовые ошибки, допускаемые разработчиком и пути их разрешения.
