QA для начинающих: как протестировать ракету или самолёт?

    В новом выпуске подкаста «Сушите вёсла» Android-разработчики позвали в гости ребят из QA. Обсудили, что это за дисциплина такая, чем она полезна бизнесу и как протестировать ракету, не спрашивая Илона Маска.



    Разработчики 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-чат.
    Redmadrobot
    №1 в разработке цифровых решений для бизнеса

    Комментарии 3

      +2
      Надо было название «Код написан хорово», чтобы было непонятно, баг или фича )

      Я не тестировщик и в пост зашёл отчасти случайно — также случайно, как однажды прочитал «Тестирование дот ком» и это правда классная книга, очень понятно написана и легко читается.
        0
        он должен уметь создавать баги

        Вероятно, имеется в виду «баг репорты»?
          0
          Ну если тестировщик не создает багов — то это плохой тестировщик.
          Баги есть всегда, вот выявлять большинство из них — в этом и есть работа тестировщика. Предотвращать их появление — это уже работа QA.
          Главное уметь находить правильный сценарий воспроизведения, а баг репорты можно писать по шаблону, в этом, на мой взгляд, нет ничего сложного.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое