Четыре месяца назад мы запустили курс “Автоматизатор мобильных приложений” о том, как построить фреймворк тестирования мобильных приложений на Android и iOS с нуля без значительного опыта в мобильной автоматизации.
За это время мы провели курс 5 раз и накопили достаточно много отзывов от наших учеников. Мы просили их оценить курс, а также описать как позитивные, так и негативные моменты, с которыми им пришлось столкнуться.
На основании отзывов мы улучшиликурс и увеличили количество уроков почти вдвое.
С разрешения учеников мы публикуем отзывы* с комментариями тренера Арсения Батырова.
* Отзывы были даны участниками разных групп, большинство проблем, описанных в отзывах, были исправлены уже в следующем запуске.
В Интернете сейчас можно найти все, что угодно, но не вся информация одинаково полезна. Тестировщикам советуют писать тест-кейсы на каждую мелкую деталь, стараться автоматизировать все на свете, и использовать тестирование, как ступеньку на пути в профессию разработчика - явно не те рекомендации, которым стоит следовать.
В преддверии дня тестировщика мы решили не остаться в стороне и тоже дать вам несколько вредных советов, следовать которым нужно с точностью до наоборот:
В Твиттере широко обсуждалось, кто должен отвечать за создание кода автотестов. Судя по тому, что я читал, люди разбились на два лагеря:
Группа, выступающая за то, что разработчики должны отвечать за создание большей части (если не всего целиком) кода автоматизации. Их основной аргумент в том, что разработчики лучше знают, как программировать, больше знают о структуре кода и его внутренней кухне, и поэтому лучше всего разбираются, как подцепить к нему код автотестов (в отличие от слепых попыток сделать это через пользовательский интерфейс).
Группа, ратующая за то, что тест-автоматизация требует отдельных, занимающихся только этим, инженеров-автоматизаторов, особенно для тестов выше юнит-уровня. Аргументируют это они тем, что для создания и поддержки хороших автотестов нужны специфические навыки, простирающиеся дальше навыков разработки.
В конце позапрошлого года я опубликовал статью, посвященную примерно этой же тематике. Перечитывая ее, я все еще согласен с собственным же мнением (что, безусловно, хорошо). Но пока я размышлял об этом, читал об этом и обсуждал этот вопрос с другими, я выявил несколько тонких (и не только) нюансов – а это тема для отдельной статьи.
Первый день конференции представлен Днем мастер-классов, где каждый из участников сможет отработать практические навыки согласно выбранной тематике.
Этой осенью мастер-классы проведут Алексей Виноградов на тему: «Быстрый старт в Web UI автоматизацию», Роман Сорока покажет “Как улучшить контроль качества на проекте” и Антон Семенченко расскажет об “Архитектуре автоматизации тестирования”.
Второй день конференции, 6 октября, представлен Днем докладов.
3 потока, более 20 докладов.
Каждый из участников сможет выбрать интересующие его темы из предложенного многообразия потоков, передвигаясь от доклада к докладу.
Работа тест-менеджера предполагает участие во многих задачах команды: планировании тестов, изучении требований, декомпозиции продукта, составлении документации. Грамотный выбор приложений и плагинов к ним облегчит вашу жизнь.
Чек-листы
Какого-то особого формата у чек-листов нет, поэтому писать их можно даже в текстовых редакторах. Но можно воспользоваться и готовыми инструментами для создания проверочных списков:
Графический редактор, в котором можно быстро создавать различные типы контента: диаграммы, чек-листы, брендированные документы. Также есть инструмент для обработки фото.
Тест-автоматизация очень много для меня значит. Я выбрал эту специальность из множества доступных в поле разработки ПО. Когда я вижу, что она неверно применяется, или когда люди просто не понимают, что это такое – меня это бесит. У меня много вопросов к плохим процессам автоматизации, и сейчас вы узнаете об этом все!
Говорить «Это просто тест-сценарии»
Автоматизация тестирования – это не просто набор тест-сценариев. Это целый арсенал технологий, требующий дизайна, интеграции, и опыта. Разработка тест-автоматизации – это отдельная область. Когда вы говорите, что это всего лишь набор тест-сценариев – вы унижаете и оскорбляете ее. Это обесценивает те усилия, которых требует автоматизация, ведет к плохому масштабированию работы и отношениям «они против нас» между разработкой и QA.
Сама структура курса осталась прежней, так как была хорошо проработана исходно. Но некоторые задания поменялись. И добавились новые. Основное отличие — это то, что мы добавили Folks как выпускной экзамен для студентов.
Задание показало слабые места, что нужно дорабатывать и прорабатывать дальше. В том числе само задание. Где-то добавили информации, где-то видео в помощь записали и т.д.
Плохих отзывов оказалось очень мало, поэтому сосредоточились на них.
Подробный разбор отрицательных отзывов тренер Ольга Назина сделала в своем блоге.
В докладе автор рассматривает как используется QA в различных аспектах жизни. Рассказывает о его основных целях и задачах. Приводит примеры хороших и плохих подходов. Говорит о рисках.
Есть несколько статей об антипаттернах разработки ПО. Но большинство из них говорят о деталях на уровне кода и фокусируются на конкретной технологии или языке программирования.
В этой статье я хочу сделать шаг назад и перечислить высокоуровневые антипаттерны тестирования, общие для всех. Надеюсь, вы узнаете некоторые из них независимо от языка программирования.
Терминология
К сожалению, в тестировании пока не выработали общую терминологию. Если спросить сотню разработчиков, в чём разница между интеграционным, сквозным и компонентным тестом, то получите сто разных ответов. Для этой статьи ограничимся такой пирамидой тестов:
Код тестов должен разрабатываться согласно таким же высоким стандартам, как и код продукта, но про это зачастую забывают. Это серьезно меня беспокоит, и стоит значительных временных и финансовых затрат благодаря своим последствиям. У меня много вопросов к плохому коду автотестов, и сейчас вы узнаете про это все!
Копипаста
Дупликация кода – это его рак. Особенно он свирепствует в тест-автоматизации, потому что шаги тестов зачастую повторяются. Но это не причина дублировать код! Используйте лучшие практики при создании кода, или готовьтесь к тому, что я забракую ваш код на код-ревью!
Жесткое кодирование конфигурационных данных
Автотесты должны быть способны запускаться в любом окружении без проблем. Не кодируйте намертво ссылки, логины, пароли и другие специфичные для конфигурации штуки! Считывайте их как ввод или файлы конфигурации. Нет ничего более раздражающего, чем переключить окружения и обнаружить – сюрприз! – что тесты не запускаются, хотя все значения в нем верны.
Четыре месяца назад мы запустили курс “
В Интернете сейчас можно найти все, что угодно, но не вся информация одинаково полезна. Тестировщикам советуют писать тест-кейсы на каждую мелкую деталь, стараться автоматизировать все на свете, и использовать тестирование, как ступеньку на пути в профессию разработчика - явно не те рекомендации, которым стоит следовать. 
Автор: Баз Дийкстра (Bas Dijkstra)
Автор: Энди Найт (Andy Knight)
Больше года прошло после первого выпуска нашей 
Автор: Энди Найт (Andy Knight)
Вышел выпуск рассылки за конец августа, его содержание доступно по