В новом выпуске подкаста «Сушите вёсла» Android-разработчики позвали в гости ребят из QA. Обсудили, что это за дисциплина такая, чем она полезна бизнесу и как протестировать ракету, не спрашивая Илона Маска.
Разработчики Redmadrobot записывают душевные подкасты, где обсуждают разработку, аналитику, тестирование и другие стороны создания ИТ-продуктов. В этот раз на огонёк заглянул QA-отряд из Redmadrobot: тимлиды Алекс и Глеб, и их руководитель Саша. Получился честный разговор про жизнь QA в мире, где есть тестировщики и разработчики. Ниже ссылка на полную запись и ответы на самые горячие вопросы.
QA или Quality Assurance — это дисциплина, которая отвечает за качество продукта. Например, за качество мобильного приложения. Обычно она интегрирована во все этапы проекта. Специалисты QA подготавливают и внедряют стандарты разработки, проводят проверку качества, предотвращают ошибки, постоянно улучшают внутренние процессы. QA применяют не только в мобильной разработке, но и в web, в промышленности и во многих других сферах.
Глобально QС (Quality Control) или тестировщики — это часть QA.
Тестировщик изучает продукт, проводит исследования, отрабатывает возможные сценарии и ловит баги. Он предоставляет команде общую картину о продукте. QC не повышает качество, а даёт представление о том, что происходит в разработке.
QA же помогает команде наладить процессы, связанные с качеством. Он смотрит на всю картину целиком и делает так, чтобы ошибок было меньше.
QC про результат: найти баги. QA про процесс: отладить процессы разработки, чтобы багов не было.
Тестировщику не обязательно знать язык и технологию, но это может быть плюсом в работе.
Разработчик думает, как сделать хорошо. Тестировщик думает, как протестировать, чтобы найти, почему это плохо. Тут есть определенный конфликт интересов.
У нас есть гипотеза, что всё зависит от того, как далеко QA находится от разработчика. Когда они сидят рядом, то рассуждают и рефлексируют над задачей вместе. Это работает лучше, потому что уровень доверия выше. Находясь в разных отделах или компаниях сложно достичь такого взаимопонимания. Остаётся только злиться на репорты от незнакомых ребят.
Ещё такое бывает у специалистов в начале пути. У молодых QA и разработчиков немного опыта в командной работе, поэтому возникают трудности. Со временем появляется осознание, что вы — напарники, работаете над одним продуктом и вместе делаете его лучше.
Бывает по-разному, некоторые уходят в тестирование по любви. Например, наш Head of QA Саша ушёл из программирования, потому что ему больше нравится всё ломать. Можно ли «мигрировать» из одного вида тестирования в другой?
Если коротко, то да. Тестировщик везде тестировщик: он должен уметь создавать баги, понимать, как пишутся тесты и прочее. При желании можно разобраться в новом направлении за несколько недель.
Мы тестируем ПО и не связаны с космосом. Но можем предположить, как это может быть.
Как и в других тестах, тут мы имеем дело со списком характеристик объекта. Его материалы, износостойкость, температура нагрева или охлаждения, количество топлива на один полёт и ещё сотни пунктов. Если бы тестировщик захотел протестировать ракету, то стал бы вытворять с ней всякое: нагревал бы, охлаждал, отправлял на расстояние, на которое она не рассчитана, и прочее. Отработка подобных сценариев, исходящих из документации к объекту или из эмпирических познаний, способна выявить дефекты, от исправления которых зависит качество любого продукта.
Starter pack для всех, кто хочет ворваться в мир QA уже сегодня:
> Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах
> Тестирование программного обеспечения. Базовый курс
> Сертификация ISTQB
> Must Have для любого тестировщика
Если есть вопросы — пишите в комментариях, будем разбираться :)
Слушайте нас на удобной платформе
SoundCloud, Apple, Google Podcasts. Приходите обсуждать выпуск в Telegram-чат.
Разработчики Redmadrobot записывают душевные подкасты, где обсуждают разработку, аналитику, тестирование и другие стороны создания ИТ-продуктов. В этот раз на огонёк заглянул QA-отряд из Redmadrobot: тимлиды Алекс и Глеб, и их руководитель Саша. Получился честный разговор про жизнь QA в мире, где есть тестировщики и разработчики. Ниже ссылка на полную запись и ответы на самые горячие вопросы.
Что это вообще такое QA?
QA или Quality Assurance — это дисциплина, которая отвечает за качество продукта. Например, за качество мобильного приложения. Обычно она интегрирована во все этапы проекта. Специалисты QA подготавливают и внедряют стандарты разработки, проводят проверку качества, предотвращают ошибки, постоянно улучшают внутренние процессы. QA применяют не только в мобильной разработке, но и в web, в промышленности и во многих других сферах.
А в чём отличие от тестировщика?
Глобально QС (Quality Control) или тестировщики — это часть QA.
Тестировщик изучает продукт, проводит исследования, отрабатывает возможные сценарии и ловит баги. Он предоставляет команде общую картину о продукте. QC не повышает качество, а даёт представление о том, что происходит в разработке.
QA же помогает команде наладить процессы, связанные с качеством. Он смотрит на всю картину целиком и делает так, чтобы ошибок было меньше.
QC про результат: найти баги. QA про процесс: отладить процессы разработки, чтобы багов не было.
Должен ли тестировщик знать язык программирования, на котором написана программа?
Тестировщику не обязательно знать язык и технологию, но это может быть плюсом в работе.
Мне очень нравится исследовать баги и иногда меня заносило: я доходил до строчки кода, где баг воспроизводился. Это интересно, когда ты можешь дать чуть больше информации разработчику в «баг репорте». Но это совсем необязательно.
«Код написан х?о?р?о?ш?о?»: разработчик пишет код, а тестировщик ищет баги. Как не поругаться?
Разработчик думает, как сделать хорошо. Тестировщик думает, как протестировать, чтобы найти, почему это плохо. Тут есть определенный конфликт интересов.
У нас есть гипотеза, что всё зависит от того, как далеко QA находится от разработчика. Когда они сидят рядом, то рассуждают и рефлексируют над задачей вместе. Это работает лучше, потому что уровень доверия выше. Находясь в разных отделах или компаниях сложно достичь такого взаимопонимания. Остаётся только злиться на репорты от незнакомых ребят.
Ещё такое бывает у специалистов в начале пути. У молодых QA и разработчиков немного опыта в командной работе, поэтому возникают трудности. Со временем появляется осознание, что вы — напарники, работаете над одним продуктом и вместе делаете его лучше.
В QA идут неудавшиеся программисты?
Бывает по-разному, некоторые уходят в тестирование по любви. Например, наш Head of QA Саша ушёл из программирования, потому что ему больше нравится всё ломать. Можно ли «мигрировать» из одного вида тестирования в другой?
Если коротко, то да. Тестировщик везде тестировщик: он должен уметь создавать баги, понимать, как пишутся тесты и прочее. При желании можно разобраться в новом направлении за несколько недель.
А ракету-то как протестировать?
Мы тестируем ПО и не связаны с космосом. Но можем предположить, как это может быть.
Как и в других тестах, тут мы имеем дело со списком характеристик объекта. Его материалы, износостойкость, температура нагрева или охлаждения, количество топлива на один полёт и ещё сотни пунктов. Если бы тестировщик захотел протестировать ракету, то стал бы вытворять с ней всякое: нагревал бы, охлаждал, отправлял на расстояние, на которое она не рассчитана, и прочее. Отработка подобных сценариев, исходящих из документации к объекту или из эмпирических познаний, способна выявить дефекты, от исправления которых зависит качество любого продукта.
Полезные ссылки
Starter pack для всех, кто хочет ворваться в мир QA уже сегодня:
> Тестирование Дот Ком, или Пособие по жестокому обращению с багами в интернет-стартапах
> Тестирование программного обеспечения. Базовый курс
> Сертификация ISTQB
> Must Have для любого тестировщика
Если есть вопросы — пишите в комментариях, будем разбираться :)
Слушайте нас на удобной платформе
SoundCloud, Apple, Google Podcasts. Приходите обсуждать выпуск в Telegram-чат.
Комментарии (3)
Elanir
11.12.2019 20:00он должен уметь создавать баги
Вероятно, имеется в виду «баг репорты»?Faenor
12.12.2019 08:54Ну если тестировщик не создает багов — то это плохой тестировщик.
Баги есть всегда, вот выявлять большинство из них — в этом и есть работа тестировщика. Предотвращать их появление — это уже работа QA.
Главное уметь находить правильный сценарий воспроизведения, а баг репорты можно писать по шаблону, в этом, на мой взгляд, нет ничего сложного.
Boomburum
Надо было название «Код написан хорово», чтобы было непонятно, баг или фича )
Я не тестировщик и в пост зашёл отчасти случайно — также случайно, как однажды прочитал «Тестирование дот ком» и это правда классная книга, очень понятно написана и легко читается.