В качестве второй части ретроспективных уроков исследования я бы хотел сконцентрироваться на теме, которая редко обсуждается. Однако, с моей точки зрения, жизненно необходимо расширить свои горизонты в этой области, чтобы улучшить свой исследовательский подход.
Зачастую, когда я спрашиваю студентов, как бы они тестировали приложение, я получаю ответы вроде "Я сравню продукт с документацией или спецификацией". Логичным образом я задаю следующий вопрос – что, если спецификации нет, или продукт еще не создан?
В этой части цикла мы поразмышляем об исследовании артефактов, приносящем пользу тестированию, и разберемся, как построить тест-стратегию, имея или не имея документации, а также о том, как найти в ней баги. Иными словами, мы научимся мыслить вне рамок документации.
Я большой фанат тестирования. Я пишу об этом в блог и почтовую рассылку, я обсуждаю это c другими разработчиками в свободное время, я зашел так далеко, что даже создал обучающий курс по тестированию в Go.
Но несмотря на всю мою любовь к тестированию, я не рекомендую его новичкам.
Звучит дико, правда? В этой статье я собираюсь пояснить свою точку зрения более детально, но весь смысл, в итоге, сводится к двум пунктам:
Начинающим не хватает знаний, чтобы писать что-либо кроме самых простых тестов. Это неизбежно приводит к следующему пункту…
Пытаться тренировать навыки, необходимые для написания реалистичных тестов, одновременно с обучением программированию крайне тяжело
Я понимаю, что это, в принципе, один пункт. В любом случае, я разбил его на два для того, чтобы было проще понять.
Знаю, многие из вас не согласятся со мной, но пожалуйста, прочитайте статью, и, если после прочтения вы останетесь при своем мнении, я буду рад обсудить это с вами. В конце концов, я здесь чтобы учиться
В современном мире Agile с его двухнедельными спринтами и частыми релизами тестированию сложно поспевать за всем. Зачастую мы полностью заняты тестированием юзер-стори текущего спринта и полагаемся на то, что автоматизация возьмет на себя регрессионное тестирование. Однако в тестировании есть ключевой компонент, про который часто забывают – это кросс-браузерное тестирование.
Привет! Меня зовут Миша, и я 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-кода, а также тем, кто хочет тестировать сложную бизнес-логику.
О чём пойдёт речь? Сначала я коротко расскажу о нашем процессе разработки и о том, как он влияет на нашу потребность в тестах и желание эти тесты писать. Затем мы пройдёмся снизу вверх по пирамиде автоматизации тестирования, обсудим используемые нами виды тестов, поговорим об инструментах внутри каждого из них и о том, какие проблемы мы решаем с их помощью. В конце рассмотрим, как поддерживать и запускать всё это добро.
