В нашей команде есть традиция собираться и смотреть две ежегодные презентации Apple – WWDC (Worldwide Developers Conference) и Keynote, на котором показывают новый iPhone. Для нас эти события похожи на финал кубка мира по футболу, Евровидение или Superbowl, или даже празднование Нового Года. После WWDC обычно идет неделя воркшопов для разработчиков от инженеров команды Apple, на которых они более подробно рассказывают о новшествах своей платформы. Мы также не пропускаем эти мероприятия, потому что они дают нам возможность узнать о самых последних тенденциях и инструментах, которые помогут нам повысить качество нашей работы, а также подготовить наши продукты к обновлению операционки, а наши CI/CD сервера к сборке на новом SDK.
Умение работать в команде и эффективно коммуницировать с другими членами команды
Все в компании работают над развитием и процветанием продукта. Для эффективной работы постоянно придумываются, внедряются, переосмысливаются, оптимизируются и уничтожаются процессы – регламенты, позволяющие всем работать максимально продуктивно и слаженно. Процессы можно сравнить с производственной линией на фабрике – там из сырья спустя несколько манипуляций получается продукция, так и в IT-сфере – из идеи получается готовая фича, радующая пользователей. Процессы с изменением вводных (новые инструменты для работы, новые люди пришли, старые ушли, etc.) могут страдать, и каждый специалист может что-то сделать для их улучшения – иногда даже простой чат-бот, который присылает результаты прогона автотестов, экономит огромное количество человеко-часов всем участникам релиза.
Теперь рассмотрим более приземленные пункты, которым довольно просто обучиться – это та необходимая матчасть, которая облегчает работу тестировщикам в любом проекте.
Составление баг-репортов
Качественный баг-репорт должен состоять из нескольких базовых пунктов:
1. Заголовок
2. Окружение
3. Приоритет и серьезность
4. Шаги воспроизведения
5. Ожидаемое поведение
6. Фактическое поведение
7. Сопроводительные аттачи (скриншоты/скринкасты)
Пойдем по порядку.
Заголовок
Это первое, что видит любой пользователь таск-трекера. Заголовок должен быть написан так, что прочитав, становится понятно, в чем проблема. В идеале ваш заголовок должен как можно короче ответить на 3 вопроса: Что? Где? Когда?
Что? Пропадает кнопка входа.
Где? В форме регистрации – иногда вопрос Где? становится избыточным, и его можно опустить.
Когда? При нажатии на поле ввода пароля.
Нельзя расписывать заголовок более чем на одно среднее предложение, это только тормозит работу – и вашу, и того, кому придется читать заголовок. На планированиях и грумингах менеджеры вместе с разработчиками разбирают завалы задач, выбирая, что взять в работу в ближайшее время, а что может подождать. Никто не любит эти встречи (поверьте!), так что пишите заголовки настолько коротко и понятно, насколько можете.
Окружение
Сюда входит все, что помогает локализовать ваши условия воспроизведения бага. На каком девайсе вы поймали ошибку? Какая iOS у вас установлена? Какая версия приложения используется? Если баг сетевой, какую сеть вы использовали? Может влиять и оператор связи, поэтому, укажите его, если подозреваете, что в этом кроется причина ошибки. Распишите как можно подробнее, и разработчику не придется задавать вам вопросы поверх вашего баг-репорта.
К окружению мы также относим предусловия. В предусловиях описываются действия, которые нужно выполнить, и параметры, которые нужно применить перед выполнением шагов, позволяющих воспроизвести баг. Это описание не имеет какого-то четкого формата, просто придерживайтесь логического порядка. Многие пишут предусловия отдельным пунктом, но мы предпочитаем объединять их с окружением для упрощения.