QA для начинающих: как протестировать ракету или самолёт
В новом выпуске подкаста «Сушите вёсла» Android-разработчики позвали в гости ребят из QA. Обсудили, что это за дисциплина такая, чем она полезна бизнесу и как протестировать ракету, не спрашивая Илона Маска.
Разработчики Redmadrobot записывают душевные подкасты, где обсуждают разработку, аналитику, тестирование и другие стороны создания ИТ-продуктов. В этот раз на огонёк заглянул QA-отряд из Redmadrobot: тимлиды Алекс и Глеб и их руководитель Саша. Получился честный разговор про жизнь 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-чат.
Тестировщик думает, как протестировать, чтобы найти, почему это плохоТестировщик ищет пути, при которых состояние или поведение системы становится не таким, каким ожидается. Иногда просто проверяет, каким будет состояние или поведение системы в таких-то ситуациях, потому что ожиданий особых нет и значит нужно получить знания на будущее.
Но тестировщик не ищет, почему что-то пошло не так. Его задача — описать, что к этому привело как можно более кратно и ясно. Можно, конечно, потратить время и разобраться, что же послужило причиной. Но это будет тормозить сам процесс контроля качества.
Остаётся только злиться на репорты от незнакомых ребятПпц. Это кто такой неженка? Не важно, знакомый тебе зарепортил или не знакомый. У тебя репорт есть, это уже в миллион раз лучше, чем ничего. В конце-концов, задай дополнительные вопросы.
ему больше нравится всё ломатьСломать — ума не надо. Редко кому нужно ломать. Тестиовщик ищет пути, которые могут привести к разлому. Потому что одно дело поднять себе права и вписать мусор и совсем другое дело обнаружить сценарий, при котором продукт сам запишет мусор в базу и после этого не поднимется
Если бы тестировщик захотел протестировать ракету, то стал бы вытворять с ней всякое:Тестировщик бы ознакомился с техническими требованиям и проверил бы соответствие им. То есть создавал условия, описанные в требованиях и проверял бы, всё ли остаётся в порядке. А что касается "отправлять на расстояние, на которое она не рассчитана", то это тоже про требованиях. Сказано в требованиях, что при такой-то дальности должны быть такие-то результаты и не описано, что должно быть сверх этого — тогда можно отправить, чтобы просто указать в репорте, что будет если. Но на релиз это не влияет особо. А если в требованиях сказано, что она должна летать строго столько, то сама возможность отправки сверх этих значений должна быть невозможна. И это проверяется не на ракете, а на ПО. То есть никто не отправлял бы ракету саму в этом случае.
Подкаст не слушал, потому что подкасты говно и не нужны. Один толковый текст лучше миллиона подкастов, видеообзоров, выступлений со сцены и прочей ненужной чепухи для бездельников.
Не принимайте близко к сердцу. Тут же краткий пересказ, в подкасте всё по делу. Конечно, если всё-таки готовы)
"он должен уметь создавать баги" - ага, именно создавать баги, может всё таки воспроизводить? Корректно описывать?
"Если бы тестировщик захотел протестировать ракету, то стал бы вытворять с ней всякое: нагревал бы, охлаждал, отправлял на расстояние, на которое она не рассчитана, и прочее. Отработка подобных сценариев, исходящих из документации к объекту или из эмпирических познаний, способна выявить дефекты, от исправления которых зависит качество любого продукта." - ага, именно так, сначала запусти ракету и потверди что она запускается, а уже потом нагревай, охлаждай и т.д. Потому что сначала проверяют работает ли КАК ДОЛЖНО, а уже потом проверяют какая реакция на неожиданные сценарии. И тестировщики не ищут баги.
Комментарий недоступен
Наверное, опечатка, а вообще в теории тестирования есть такой подход для оценки качества тестирования – внесение в систему искусственных багов, чтобы потом просмотреть находятся они или нет в текущем процессе тестирования.
Очень полезно для начинающих, огромное спасибо! P.S. не слушайте отстойные коменты, троли пишут, это как эпидемия сейчас
Спасибо)