Иногда среди нас возникают споры, что такое тестирование, и каким лексиконом пользоваться, говоря о разных его аспектах. Лично я не особо заморачиваюсь с этими вопросами, но есть одна штука, которая, по моему опыту, истинна: по своей сути любое тестирование – это исследовательское тестирование. Нельзя найти ничего интересного в продукте, не исследуя его.
Это верно вне зависимости от того, каким видом тестирования вы занимаетесь. Размышляя о тестировании, требующем глубоких технических навыков, мы полагаем, что оно не особенно требует исследования, но лично я так не думаю. К примеру, я много тестирую 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 и др. и расскажет о преимуществах и недостатках перечисленных утилит!
Чуть больше года назад мы (Арсений Батыров и Виталий Котов) запустили сайт learnqa с курсами по ручному и автоматизированному тестированию мобильных приложений.
В течение всего следующего года мы улучшали эти курсы, работали с учениками и писали новый материал. За год мы обучили около тысячи человек, а количество курсов на сайте выросло до 9. Теперь на learnqa можно узнать о git и bash, adb и chrome dev tools, а автоматизация мобильных доступна даже начинающим.
В день рождения принято дарить подарки - но дарить их будем мы, чтобы наши курсы стали доступны всем желающим. Давайте посмотрим, что мы вам приготовили.
13 июня стартуют наши “большие” курсы - о ручном и автоматизированном тестировании мобильных приложений. К этой дате мы подготовили специальное предложение “Мобильная прокачка”: одним набором можно купить 4 наших курса, которые помогут развиться в мобильном тестировании:
Они помогут вам начать тестировать мобильные приложения на серьезном уровне, расширят кругозор и добавят новых возможностей для трудоустройства.
Их можно будет купить по уникальной цене - всего в 20 000 рублей вместо 26 000. Фактически, вы получаете 4 курса по цене двух. Время на их прохождение складывается, поэтому вы сможете пройти их в удобном для вас темпе.
Через неделю, 20 июня мы запускаем 5 наших курсов из серии “Инструменты тестировщика”.
Каждый из них знакомит слушателей с одним из базовых навыков, необходимых современному специалисту по тестированию. В этих курсах - минимальное количество теории, но много практики и домашних работ.
До 20 июня все эти курсы можно купить с большой скидкой. К тому же мы увеличили время на их прохождение - и теперь вместо двух недель у вас будет месяц. В течение месяца вы вполне сможете пройти даже все 5 курсов.
После неожиданного успеха цикла статей о ретроспективных уроках автоматизации мне показалось, что нужно уделить больше времени областям, в которых у меня достаточно опыта, и к которым я неравнодушен. Это исследовательское тестирование – или, как я буду называть это далее, просто исследование.
Зачем это нужно? Мне кажется, что я посылаю некоторым людям смешанные сигналы – мне пришлось отклонить ряд запросов на консультации по автоматизации, потому что люди решили, что я эксперт в этой сфере. Мне очень льстит быть так высоко оцененным, но положа руку на сердце, я не могу претендовать на эту честь. Я любитель-самоучка, у которого достаточно смелости на то, чтобы иметь мнение, и есть блог, где этим мнением можно поделиться. Что касается уровня моих навыков, я считаю, что они находятся на необходимом минимуме. В любом случае, я не разделяю взгляд на автоматизацию, сконцентрированный на инструментарии, и полагаю, что большая часть проблем, связанных с автотестами, в том, что люди недостаточно хорошо понимают тестирование. Ретроспективные уроки автоматизации отклонились от моей первоначальной цели – создания отсутствующего звена между тестированием и автоматизацией, слишком отойдя к технической стороне автотестов. Если основной задачей цикла была демонстрация, что имеет смысл автоматизировать для помощи тестированию, необходим еще один цикл, показывающий, что наиболее важно с точки зрения тестировщика, и что автоматизаторы должны знать о целях и сути экспертного тестирования.
Я решил, что этот цикл будет называться "Ретроспективные уроки исследовательского тестирования". Он также будет полезен тем, кого интересует исследовательская часть тестирования, и кто устал от просьб строго следовать сценариям, хотя толка от этого немного.
Можно ли автоматизировать всё, что угодно? Потом всех тестировщиков уволим, конечно. Зачем они теперь нужны, «ручного» тестирования не осталось. Правильно ведь?
Это рассказ о будущем тестирования с точки зрения DevOps. Здесь будут конкретные цифры и чисто практические выводы, как так получается, что у хороших специалистов всегда есть работа. (Или нет работы! Глядите на фотографию Шекспира и бойтесь, сейчас будет решаться ваша судьба).
В основе материала — расшифровка доклада Баруха jbaruch Садогурского, Developer Advocate в компании JFrog. Текстовая версия и видео доклада — под катом.
На конференциях, митапах и в социальных сетях тестировщики систематически сообщают мне, что они должны "дать добро" на продукт или деплой перед тем, как продукт выпущен в продакшен, или уйдет на ревью к клиенту. Тестировщики заявляют, что после того, как они проделали какую-то работу по тестированию, они должны "одобрить" или "отклонить" продукт. Вот типичный дословный отчет от одного из них:
"В моем нынешнем контексте, несмотря на мои обоснованные возражения, на меня смотрят как на привратника, и я нахожусь на такой позиции в рабочем процессе, которая буквальным образом предоставляет мне зеленую кнопку "одобрения" и красную кнопку "отклонения". Я должен выбрать нужную кнопку после "проведения контроля качества" рабочего продукта. Отдельным бонусом идет список противоречивых требований заказчика и/или набросок с кучей примечаний (зачастую противоречащих устным запросам, которые нигде не фиксировались)".
Автор: Энди Найт (Andy Knight)
