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