Привет! Меня зовут Миша, и я Senior QА с коммерческим опытом более 6 лет. Сейчас я работаю в Provectus, но начинал я свой путь тестировщика еще в студенческие годы с участия в альфа- и бета-тестах различных игр. В какой-то момент подумал: «Почему бы не начать заниматься этим профессионально?». И пошло-поехало. За это время я успел поучаствовать в разных проектах: от стартапов до энтерпрайзов, от небольших обучающих юнити-игр до огромных приложений с сильнейшей бизнес-логикой.
Но зачастую меня внедряли в небольшие команды, в которых было от 5 разработчиков на 1-2 тестировщика и, как правило, большая жара в проекте. Собственно, о том, как научиться понимать, где вы очутились и как начинать продвигаться в постановке QA-процессов, я и хочу поделиться с вами.
Вопросы на собеседованиях тестировщиков часто походят друг на друга. Один из самых часто задаваемых - задача на тестирование программы, проверяющей существование треугольников. Задача хорошая, но довольно абстрактная, и бывает сложно вспомнить все кейсы, которые стоит провести.
Чтобы сделать задачу более наглядной, мы создали небольшой тренажер: https://playground.learnqa.ru/puzzle/triangle. К нему мы добавили самые популярные кейсы для тестирования, а также несколько багов разной сложности. Можете попробовать найти их все и получить приятные скидки на наши курсы! Ну и конечно похвастаться перед другими тестировщиками, когда найдете все :)
В прошлый раз я описывал процесс изучения факторов проектного окружения, которые влияют на мою стратегию, когда я занимаюсь тестированием API. Теперь я нырну глубже, узнаю больше, и начну взаимодействовать с продуктом. То, что я узнаю в процессе взаимодействия с ним, даст мне информацию для новых действий и базу для новых знаний.
В ходе тестирования я буду генерировать идеи, отраженные в эвристической модели тест-стратегии. Я буду думать о возможных проблемах и рисках, связанных с критериями качества, а также о том, что этим критериям угрожает. Я идентифицирую продуктовые факторы и пойму, как лучше покрыть продукт тестами. А затем я применю эти идеи на практике, используя техники тестирования.
Заметьте, что хоть я и помечаю идеи ссылками, они не берутся напрямую из модели тест-стратегии. Идеи приходят ко мне, когда я сталкиваюсь с какими-то элементами продукта и его контекста. Каждое взаимодействие с продуктом, каждое наблюдение провоцирует развитие идей о рисках и способах тестирования. Некоторые из них вытекают из моего личного опыта в разработке и тестировании, а другие – из рассказов коллег или новостей, самого продукта и его документации, и все это приводит к образованию совершенно новых идей.
Возможно, вы посчитаете, что это очень длинная статья. Ее длина отражает объем идей, посещающих тестировщика в процессе исследования.
Karate – это относительно свежий фреймворк с открытым исходным кодом, предназначенным для тестирования веб-сервисов. Несмотря на то, что Karate написан на Java, его основная ценность в том, что тестировщикам не нужно программировать на Java, чтобы создавать полностью автоматизированные тесты. Вместо этого тестировщики используют похожий на Gherkin язык с шагами для создания запросов и валидации ответов. Это похоже на Cucumber с нестандартными шагами Web API! У Karate есть и другие приятные особенности.
Эта статья – мое руководство для делающих первые шаги в Karate. Убедитесь, что вы понимаете, как работают веб-сервисы (например, REST API). Знание BDD тоже пригодится.
Иногда среди нас возникают споры, что такое тестирование, и каким лексиконом пользоваться, говоря о разных его аспектах. Лично я не особо заморачиваюсь с этими вопросами, но есть одна штука, которая, по моему опыту, истинна: по своей сути любое тестирование – это исследовательское тестирование. Нельзя найти ничего интересного в продукте, не исследуя его.
Это верно вне зависимости от того, каким видом тестирования вы занимаетесь. Размышляя о тестировании, требующем глубоких технических навыков, мы полагаем, что оно не особенно требует исследования, но лично я так не думаю. К примеру, я много тестирую API и работаю над курсами, обучающими API-тестированию. Это тестирование тоже требует исследовательского подхода!
Множество инструментов может помочь вам с тестированием API, и я пользуюсь многими из них. позвольте внести ясность: использование инструментов не отменяет исследования. Я находил в API множество багов, но сделал я это совсем не способом "заставить инструмент прочитать спецификацию в Swagger, а потом нажать на запуск". Я сделал это, изучая API. Большая часть инструментов для тестирования API направлена на то, чтобы помочь вам настроить автоматизированный регресс. У регрессионного тестирования есть свои задачи и своя польза, но не забывайте, что те же самые инструменты могут помочь вам при исследовании вашего API.
Я размышлял о багах, которые я нашел в API в ходе последних тест-сессий, и обнаружил, что их можно разделить на несколько категорий. С моей точки зрения, эта категоризация демонстрирует, насколько тестирование API требует исследовательского подхода.
Утилита Android Debug Bridge обладает огромным функционалом. Даже простая установка приложения может производиться различными способами. Это удобно, если вам нужно одновременно обновлять приложение на большом количестве девайсов, или устанавливать их часто. Также в ADB есть различные ключи, которые ограничивают установку устаревших версий, или наоборот - позволяют обновить приложение. Об этих и некоторых других функциях утилиты adb install мы рассказываем в этом видео.
Это и другие видео вы можете увидеть на нашем youtube-канале. Подписывайтесь, чтобы регулярно получать новые видео по тестированию!
Я бэкенд-разработчик в серверной команде Badoo. На прошлогодней конференции HighLoad я выступал с докладом, текстовым вариантом которого и хочу поделиться с вами. Этот пост будет наиболее полезен тем, кто самостоятельно пишет тесты для бэкенда и испытывает проблемы с тестированием legacy-кода, а также тем, кто хочет тестировать сложную бизнес-логику.
О чём пойдёт речь? Сначала я коротко расскажу о нашем процессе разработки и о том, как он влияет на нашу потребность в тестах и желание эти тесты писать. Затем мы пройдёмся снизу вверх по пирамиде автоматизации тестирования, обсудим используемые нами виды тестов, поговорим об инструментах внутри каждого из них и о том, какие проблемы мы решаем с их помощью. В конце рассмотрим, как поддерживать и запускать всё это добро.
Selenium WebDriver – наиболее популярный пакет с открытым исходным кодом для автоматизации тестирования Web UI. Он позволяет тестам напрямую взаимодействовать со страницей в живом браузере. Однако его использование может сильно раздражать, потому что базовым взаимодействиям зачастую не хватает устойчивости, и это вызывает плавающие проблемы.
27 апреля команда FunTech Meetups провели первый митап по тестированию. Митап был полностью посвящён автоматизации, а спикеры из Mail.ru Group, Badoo, ivi.ru, Tinkoff.ru и FunCorp в своих докладах рассказывали, как и что они автоматизируют в своих компаниях. Предлагаем Вашему вниманию видео и слайды с этих выступлений.
Под катом видео и слайдкасты следующих докладов:
«Автотесты, объединяющие подходы, платформы и сердца», Михаил Чирков, ivi.ru
«Автотесты есть? А если найду?», Алексей Петров, FunCorp
«Непрерывная интеграция и автоматизация» Алексей Халайджи, Почта.Mail.ru
«Модульное тестирование как инструмент QA инженеров», Никита Кузнецов, Tinkoff.ru
«Параллельное покрытие автотестами и другие изящные способы ускорить доставку фич», Катерина Спринсян, Badoo
В данном видео из серии "Test-Suites" автоматизатор - Антонина Бжассо из "Лаборатория качества" на базе нескольких кейсов познакомит вас с такими инструментами как Twin, certmgr.exe, UI Spy и др. и расскажет о преимуществах и недостатках перечисленных утилит!
Автор: Энди Найт (Andy Knight)