Разработчики red_mad_robot записывают душевные подкасты, где обсуждают разработку, аналитику, тестирование и другие стороны создания ИТ-продуктов.
В этот раз на огонёк заглянул QA-отряд red_mad_robot: тимлиды Алекс и Глеб и их руководитель Саша. Получился честный разговор про жизнь QA в мире, где есть тестировщики и разработчики. Ниже ссылка на полную запись и ответы на самые горячие вопросы.
Что это вообще такое — QA?
QA, или Quality Assurance, — это дисциплина, которая отвечает за качество продукта. Например, за качество мобильного приложения. Обычно она интегрирована во все этапы проекта. Специалисты QA подготавливают и внедряют стандарты разработки, проверяют качество, предотвращают ошибки, постоянно улучшают внутренние процессы. QA применяют не только в мобильной разработке, но и в вебе, в промышленности и во многих других сферах.
А в чём отличие от тестировщика?
Глобально QС (Quality Control), или тестировщики, — это часть QA.
Тестировщик изучает продукт, проводит исследования, отрабатывает возможные сценарии и ловит баги. Он предоставляет команде общую картину о продукте. QC не повышает качество, а даёт представление о том, что происходит в разработке.
QA же помогает команде наладить процессы, связанные с качеством. Он смотрит на всю картину целиком и делает так, чтобы ошибок было меньше.
QC про результат: найти баги. QA про процесс: отладить процессы разработки, чтобы багов не было.
Должен ли тестировщик знать язык программирования, на котором написана программа?
Тестировщику необязательно знать язык и технологию, но это может быть плюсом в работе.
Мне очень нравится исследовать баги, и иногда меня заносило: я доходил до строчки кода, где баг воспроизводился. Это интересно, когда ты можешь дать чуть больше информации разработчику в баг-репорте. Но это совсем необязательно.
«Код написан х̶о̶р̶о̶ш̶о̶»: разработчик пишет код, а тестировщик ищет баги. Как не поругаться?
Разработчик думает, как сделать хорошо. Тестировщик думает, как протестировать, чтобы найти, почему это плохо. Тут есть определенный конфликт интересов.
У нас есть гипотеза, что всё зависит от того, как далеко QA находится от разработчика. Когда они сидят рядом, то рассуждают и рефлексируют над задачей вместе. Это работает лучше, потому что уровень доверия выше. Находясь в разных отделах или компаниях, сложно достичь такого взаимопонимания. Остаётся только злиться на репорты от незнакомых ребят.
Ещё такое бывает у специалистов в начале пути. У молодых QA и разработчиков немного опыта в командной работе, поэтому возникают трудности. Со временем появляется осознание, что вы — напарники, работаете над одним продуктом и вместе делаете его лучше.
В QA идут неудавшиеся программисты?
Бывает по-разному, некоторые уходят в тестирование по любви. Например, наш Head of QA Саша ушёл из программирования, потому что ему больше нравится всё ломать.
Можно ли «мигрировать» из одного вида тестирования в другой?
Если коротко, то да. Тестировщик везде тестировщик: он должен уметь создавать баги, понимать, как пишутся тесты и прочее. При желании можно разобраться в новом направлении за несколько недель.
А ракету-то как протестировать?
Мы тестируем ПО и не связаны с космосом. Но можем предположить, как это может быть.
Как и в других тестах, тут мы имеем дело со списком характеристик объекта. Его материалы, износостойкость, температура нагрева или охлаждения, количество топлива на один полёт и ещё сотни пунктов.
Если бы тестировщик захотел протестировать ракету, то стал бы вытворять с ней всякое: нагревал бы, охлаждал, отправлял на расстояние, на которое она не рассчитана, и прочее. Отработка подобных сценариев, исходящих из документации к объекту или из эмпирических познаний, способна выявить дефекты, от исправления которых зависит качество любого продукта.
Полезные ссылки
Starter pack для всех, кто хочет ворваться в мир QA уже сегодня:
Слушайте нас на удобной платформе — SoundCloud, Apple, Google Podcasts. Приходите обсуждать выпуск в Telegram-чат.