5 мифов о тестировании

    image Недавно начала вести курсы по основам тестирования, и так получилось, что группа собралась из одних программистов. И каково же было мое удивление, когда люди, задействованные в разработке программного обеспечения, ничего не знают о тестировании. Умные ребята, продвинутые программисты, хорошо разбирающиеся в своей предметной области, ничего не знают о том, как тестировать ими же написанное программное обеспечение.
    Несмотря на то, что тестрование существует уже давно, это еще молодое развивающееся направление, про которое зачастую мало что знают, за пределами отдела тестирования. И тогда я задумалась, почему люди идут работать тестировщиками, или наоборот не идут. Движут ли ими какие-то предубеждения и мифы. Как-то на глаза попалась статья Майка Брауна (Mike Brown) про 5 мифов в тестировании, переводом которой хочу с вами поделиться
    :

    Занимаясь обработкой данных тестирования, я постоянно удивляюсь, сколь часто приходится сталкиваться со случаями непонимания. Можно выделить довольно много заблуждений, но я хотел бы рассказать о пяти наиболее распространенных мифах тестирования. Первые три, как мне кажется, превалируют в новостных статьях, тогда как два других распространены внутри профессионального сообщества.

    Ознакомьтесь и скажите, согласны вы со мной или нет.

    Миф первый: тестирование — это скучно.
    Нередко приходится слышать, что тестирование похоже на секс: если оно не доставляет удовольствия, то вы занимаетесь им неправильно. Миф о тестировании как о скучной и монотонной активности распространяется в средствах массовой информации, в которых тестировщики рассматриваются как рабочие у конвейера программной индустрии. На самом деле в тестировании приходится решать много новых и интересных задач ежедневно. Приведем цитату из Майкла Болтона, подводящую своеобразный итог сказанному выше:

    «В тестировании нами движет стремление к поиску новой информации. Тестирование — это процесс исследования, открытия, изучения нового и обучения. Когда мы настраиваем, запускаем и изучаем программный продукт, чтобы дать ему оценку или чтобы обнаружить какую-то неожиданную проблему, мы тестируем. Мы тестируем, пытаясь очертить границы и возможности продукта и дизайна. Мы тестируем, когда нами движет стремление ответить на вопросы, на которые нет ответа или на те вопросы, которые даже не были еще заданы.»

    Миф второй: тестирование — это просто.
    Часто говорят также, что тестирование программного обеспечения не может быть ТАК сложно, так как обычные пользователи постоянно находят ошибки в программах. На самом деле тестирование является очень сложным мастерством, овладеть которым среднему человеку не под силу. Вот что говорит Патрик Коупленд из Google о необходимых качествах тестировщика:

    «Это особый склад ума и особая страсть. На 100 проведенных мной собеседованиях для тестировщиков я прежде всего обращал внимание на: 1) наличие особой способности к поиску проблем и 2) страсть к тестированию, присутствующую в человеке наряду с этой способностью. Другими словами тестировщики любят свою работу и делают ее хорошо. Они отмечают, что при тестировании приходится решать проблемы, равные, а иногда даже и превосходящие по сложности те, что приходится решать при программировании. Тот, кто является тестировщиком от Бога и правильно относится к работе, никогда не останется без дела. Такие люди — на вес золота. „

    Миф третий: тестировщики всего лишь ищут ошибки.
    Тестировщики действительно занимаются поиском ошибок, но это далеко не единственная цель их деятельности. Очень хорошо высказывается об этом мифе автор, опубликовавший на сайте freesoftwaretesting.info статью под именем Ankur:

    Это слишком ограниченный взгляд на работу тестировщика, обесценивающий ее в глазах пользователей. Тестировщики — эксперты системы, приложения или продукта, который они тестируют. В отличие от разработчиков, которые ответственны лишь за определенную функцию или компонент, тестировщики несут ответственность за работу системы в целом. Тестировщики понимают значимость продукта, влияние окружения на его эффективность. Они знают, как использовать продукт с максимальной отдачей.

    Миф четвертый: машины заменят тестировщиков, и они станут ненужными.
    С развитием компьютерных технологий все более распространенным становится мнение, согласно которому тестирование программ людьми скоро вообще исчезнет. Но так как конечными пользователями компьютерных программ являются не роботы и не машины, а живые люди, важность осуществляемого людьми тестирования не уменьшится. Вот что пишет об этом автор книг по тестированию Джеймс Уиттейкер о важности ручного тестирования:

    С помощью автоматизации тестирования пытаются решить слишком много проблем. На автоматизацию пытаются взвалить слишком много — и поэтому она столь ненадежна и уязвима. Что-то можно хорошо сделать с помощью автоматизированной системы, но есть и то, что люди могут сделать лучше. Поэтому смешанный подход мне кажется более оправданным. За счет автоматизации я прежде всего хочу облегчить свой человеческий труд. Автоматизация нужна для анализа данных и выявления моделей. Но с помощью автоматизированных средств нельзя давать оценки и выносить суждения. К счастью, у людей это получается лучше.

    Миф пятый: тестировщики не ладят с разработчиками.
    Вполне понятно, почему этот миф так распространен. Об этом однажды написал гуру тестирования Джеймс Бах:

    Тот, кто выставляет свою работу на суд публики, должен быть готов к тому, что его будут обсуждать. Это очень неприятное ощущение. А тестировщики порой подливают масла в огонь поспешными заявлениями о наличии в программе тех или иных дефектов, выдавая за дефект качества то, что всего лишь не нравится персонально им.

    Не все знают, что многие тестировщики являются бывшими разработчиками (и наоборот), поэтому они вполне в состоянии понять друг друга и оценить стоящие друг перед другом задачи. Конечно, так бывает далеко не во всех компаниях, но на основании нашего опыта мы можем сказать, что слухи о непонимании между программистами и тестировщиками сильно преувеличены.

    Хочу добавить в список мифов: слышала такой миф от программистов, что тестировщики ищут баги только путем нажимания всех кнопок подряд, даже не задумываясь о входных и выходных параметрах. Еще есть целый ряд мифов об автоматизации программного обеспечения, например:
    • автоматизация позволяет сократить расходы;
    • автоматизация решает проблему с нехваткой ресурсов;
    • чем больше автотестов, тем лучше;
    Или самый распространенный миф о том, что тестирование улучшает качество программного продукта. Чтобы улучшать качество, нужно его создавать, а тестирование только проверяет качество. Да, конечно, тестировщики проверили качество программного обеспечения, нашли ошибки, показали отчет о тестировании, программисты исправили, качество повысилось. Но не тестировщики улучшают качество программного обеспечения.

    Что касается меня, я шла в тестирование, движимая каким-то предчувствием, что в тестировании есть куда развиваться, в тестировании никогда не будешь стоять на месте. Вот это развитие меня привлекало и привлекает по сей день. Хотя, конечно, я думала, что тестирование — это легко.

    А какие мифы о тестировании знаете вы?


    UPD. Большое спасибо за проявленный интерес к моей статье. Просуммирую пару мифов/антимифов/фактов от читателей Хабра:
    Автор: evans2094
    Миф:
    1. Разработчики и издатели прислушиваются к тестировщикам.
    2. Тестирование продукта начинается на этапе проектирования и продолжается в течении всего его жизненного цикла.
    Чем то разаработка и тестирование напоминает Мытье слона. Его нельзя помыть всего целиком и чистенько, пока одно ухо помоем — второе уже чемто заляпалось :) Можно конечно окатить целиком штормовым тестированием, но тогда дотошный клиент найдет какуюто дрянь по всей поверхности слона… а целиком в кислоте не вымочить — умрет ведь :)


    Автор: netmike
    Факт:
    Автоматизация программного обеспечения требует дополнительных инвестиций, хотя позволяет повысить качество продукта. По сути, автоматизация начинает приносить пользу только на продуктах, разработка и сопровождение которых достаточно длительны.


    Добавление от NatalyaRukol:
    Автоматизация оправдана только в случаях, когда основные затраты приходятся на клики (стабильный, работающий функционал, который уже понятно как тестировать и в котором не находится колоссальное количество ошибок)


    Автор: graninas
    Миф:
    я пишу на haskell и мне не приходится тестировать мой код, всё и так работает.


    petropavel отметил, что эти мифы универсальны и их можно применить к любой профессии:
    Миф первый: уборка помещений — это скучно.
    Миф об уборке помещений как о скучной и монотонной активности распространяется в средствах массовой информации, в которых уборщицы рассматриваются как чернорабочие офисной деятельности. На самом деле в уборке приходится решать много новых и интересных задач ежедневно. [прим. перев. например, жевательная резинка на стуле]

    Миф второй: уборка — это просто.
    Часто говорят также, что уборка не может быть ТАК сложна, так как обычные
    люди постоянно убирают в своих квартирах…

    Миф третий: уборщицы всего лишь подбирают мусор.
    Уборщицы действительно занимаются подбиранием мусора, но это далеко не единственная цель их деятельности…

    Миф четвертый: машины заменят уборщиц, и они станут ненужными.
    С развитием компьютерных технологий все более распространенным становится мнение, согласно которому уборка помещений людьми скоро вообще исчезнет…

    Миф пятый: уборщицы не ладят с офисными сотрудниками.
    Вполне понятно, почему этот миф так распространен… Не все знают, что многие уборщицы являются бывшими офисными сотрудниками…


    wicked_sten опроверг один из моих миф о том, что тестировщики не улучшают качество программного обеспечения, написав:

    Количество моих нововведений чуть меньше, чем заявок от кастомеров. Ну как-то так сложилось. Самые простые делают сразу, сложные — после еще пары просьб о том же.


    PS. Большое спасибо за перевод моему коллеге AndreiYemelianov
    ALEE Software
    38,70
    ПО стандартизации и управления качеством
    Поделиться публикацией

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

      +2
      А можно спрятать часть текста под «читать дальше»?
      Спасибо.
      • НЛО прилетело и опубликовало эту надпись здесь
          0
          В догонку: Можно также еще и шрифт обычный, а не жирный. Читать не особо комфортно ;)
            0
            Прошу извинить коллегу, которая в первый раз запостила статью на хабре и еще не довела оформительские навыки до совершенства.
              +5
              Прошу прощения, исправлюсь
              +3
              Автоматизация программного обеспечения требует дополнительных инвестиций, хотя позволяет повысить качество продукта. По сути, автоматизация начинает приносить пользу только на продуктах, разработка и сопровождение которых достаточно длительны.
                +1
                Длительных, да. А ещё обязательно достаточно стабильных. Я сейчас участвую на одном проекте, который разрабатывается уже более полутора лет, срок для окупаемости автотестов предостаточный. Но каждую неделю проводится обработка пожеланий пользователей, которая вызывает серьёзные изменения в продукте. В итоге автотесты с третьей космической скоростью устаревают, в продукте нет ничего старше 2-х месяцев.

                Весь НОВЫЙ функционал нужно тестировать вручную. Потому что при тестировании такого функционала 50% затрат уходит на анализ «как правильно» и «как тестировать», а 40% — на регистрацию дефектов. Автотесты позволяют сэкономить 10% на тыкание на кнопочки, но этого недостаточно.

                Получается, автоматизация оправдана только в случаях, когда основные затраты приходятся на клики (стабильный, работающий функционал, который уже понятно как тестировать и в котором не находится колоссальное количество ошибок).
                +2
                автоматизация позволяет сократить расходы;
                автоматизация решает проблему с нехваткой ресурсов;
                чем больше автотестов, тем лучше;

                Это — не мифы. Конечно, автоматизированное тестирование не заменит живых разработчиков. Но эти три фразы безусловно истинны в большинстве случаев.
                  0
                  s/живых разработчиков/живых тестеров/
                    0
                    Да все ок. Тестеры тоже разработчики, хотя, конечно, не программисты.
                      +2
                      А чем отличается программист от разработчика?
                        +2
                        programmer can be used to refer to a software developer
                          +3
                          В моем понятии у софта есть разработчики(те, кто его делает) и пользователи. Просто понятие разработчик более широкое, чем программист. Я тестировщик и я вношу посильный вклад в разработку ПО.

                          Поэтому ваш вопрос для меня звучит как «чем отличается каменщик от строителя».
                    +1
                    Подпишусь под каждым словом. Просто на личном опыте.
                      0
                      Но не тестировщики улучшают качество программного обеспечения.

                      А вот это откомменчу особенно.
                      Количество моих нововведений чуть меньше, чем заявок от кастомеров. Ну как-то так сложилось. Самые простые делают сразу, сложные — после еще пары просьб о том же.

                      Но в целом — коллега, целую руку :)
                        0
                        Да сделайте уже хабракат, наконец-то! Раздражает. Сколько раз листаю — разражает.
                          0
                          Спасибо. Так лучше.
                          +3
                          Хочу добавить в список мифов: слышала такой миф от программистов, что тестировщики ищут баги только путем нажимания всех кнопок подряд, даже не задумываясь о входных и выходных параметрах.

                          Monkey testing – это неотъемлемая часть проверок. Вы отдадите продукт пользователю, который, поверьте, будет тоже нажимать на все кнопки не задумываясь о входных и выходных данных. Задача разработчиков – сделать так, чтобы пользователь не мог навредить самому себе и чтобы ответ приложения был всегда корректным. Если я могу нажать на все кнопки и приложение выдает непонятную ошибку, разве это нормально? Конечно же, не стоит ограничиваться лишь обезьяним тестированием, и в будущем стоит его автоматизировать, но сейчас, подумайте, если кнопка не работает – то я не смогу завершить свой самый сложный и самый продуманный сценарий. Так почему бы не убедиться в готовности приложения, проводя вначале сессию обезьяньего тестирования?

                          автоматизация позволяет сократить расходы;


                          Тут вопрос в том, что вы подразумеваете под автоматизацией. Если я, как мануальный тестировщик, использую инструменты для генерации тестовых данных, скрипты автоматизированого деплоймента базы данных, компиляции приложения из исходников, анализаторы логов, автоматизированную выкачку и установку билда перед мои приходом на работу, то это не автоматизация тестирования?
                          Многие люди думают, что автоматизация тестирования — это тесты на Селениуме. Вот вам еще один миф :)

                          автоматизация решает проблему с нехваткой ресурсов;


                          Ресурсов или кадров?
                          Если ресурсов, то да, автоматизация тестирования не заменит мне винт на 500 Гб.
                          Если кадров — то каких именно? Если вам нужен человек, который перегоняет данные из ворда в ексель, то я бы мог попробывать написать для этого скрипт.

                          чем больше автотестов, тем лучше;

                          Два теста лучше чем один, три теста лучше чем два, двадцать тестов лучше чем девятнадцать.
                          Вы — несогласны?
                          После какого числа это станет мифом.

                            0
                            > Два теста лучше чем один, три теста лучше чем два, двадцать тестов лучше чем девятнадцать.
                            Вы — несогласны?

                            Я — не согласен. Точнее так. Существуют проекты и системы разработки для которых два теста лучше, чем один. Но существуют и другие. Не знаю точно, как там дела у вирусологов, но допускаю мысль, что тест сканирующего приложения у них всего один — с разными наборами данных для сканирования.
                              +1
                              1 Data Driven тест кейс, запущенный с разными данными – это 10 тест кейсов
                                0
                                * c 10 разными наборами данных
                              +3
                              Самый страшный миф на моей памяти: Разработчики и издатели прислушиваются к тестировщикам.
                              Очень часто также путают: Quality Assurance, Quality Control, Quality Check (в принципе все это процедулы входящие в процесс контроля качества, но частенько нам дают грызть готовый продукт, добавляя «Через неделю релиз — поищите косяки.» И ладно если ты один и тестишь калькулятор, а если это клиент-серверное приложение управления контентом и вас 15 человек?).
                              Хотелось бы чтобы это было реальностью, но это миф: Тестирование продукта начинается на этапе проектирования и продолжается в течении всего его жизненного цикла.
                              Чем то разаработка и тестирование напоминает Мытье слона. Его нельзя помыть всего целиком и чистенько, пока одно ухо помоем — второе уже чемто заляпалось :) Можно конечно окатить целиком штормовым тестированием, но тогда дотошный клиент найдет какуюто дрянь по всей поверхности слона… а целиком в кислоте не вымочить — умрет ведь :)
                              Вот такой вот сумбурный текст. За статью громадное спасибо. Вдруг вернусь к истокам.
                              +1
                              Mythbusters рулят :)
                                +27
                                А никто не заметил, что это на самом деле универсальные мифы? Можно применить к любой профессии, так же как «тебя недооценивают на работе. а ждет тебя, милок, дальняя дорога и казенный дом». Вот, например,

                                (disclaimer: это НЕ наезд на тестировщиков и не оспаривание мифов, а только замечания об общности их формулировок)

                                Миф первый: уборка помещений — это скучно.

                                Миф об уборке помещений как о скучной и монотонной активности распространяется в средствах массовой информации, в которых уборщицы рассматриваются как чернорабочие офисной деятельности. На самом деле в уборке приходится решать много новых и интересных задач ежедневно. [прим. перев. например, жевательная резинка на стуле]

                                Миф второй: уборка — это просто.

                                Часто говорят также, что уборка не может быть ТАК сложна, так как обычные
                                люди постоянно убирают в своих квартирах…

                                Миф третий: уборщицы всего лишь подбирают мусор.

                                Уборщицы действительно занимаются подбиранием мусора, но это далеко не единственная цель их деятельности…

                                Миф четвертый: машины заменят уборщиц, и они станут ненужными.

                                С развитием компьютерных технологий все более распространенным становится мнение, согласно которому уборка помещений людьми скоро вообще исчезнет…

                                Миф пятый: уборщицы не ладят с офисными сотрудниками.

                                Вполне понятно, почему этот миф так распространен… Не все знают, что многие уборщицы являются бывшими офисными сотрудниками…


                                А теперь можете перечитать статью, и она заиграет перед вами новыми красками…
                                  +2
                                  +1.

                                  Обобщение сыграло злейшую штуку.

                                  Плюс системности в рассуждениях переводимого автора нет.
                                  +2
                                  Факт первый: тестирование — это скучно.
                                  Не всё конечно, но примерно 3/4 всех тестеров это мануальщики тестирующие UI и его работу. Остальных да, эти факты не касаются.

                                  Факт второй: тестирование — это просто.
                                  Нет никакой особой склонности к тестированию. Лучше тругих тестируют люди потратившие на это больше времени (трудоголики) или обладающие лучшей квалификацией по определенным технологиям. Про проблемы сложнее чем у программистов это просто бред. Ну есть штучные специалисты по нагрузочному тестированию в сложных системах например но их реально единицы.

                                  Факт третий: тестировщики всего лишь ищут ошибки.
                                  Ответственность это к лидам и прочим манагерам. На больших продуктах у тестера ровно столько же влияния на дизайн решения, сколько у анонимуса в интернете. 99% времени тестировщики ищут ошибки.
                                    0
                                    Ещё покину один «миф»: я пишу на haskell и мне не приходится тестировать мой код, всё и так работает.
                                      +1
                                      Это полумиф. Безусловно, если Haskell-программа скомилилась, — значит, работает. Но она может работать не правильно. Ошибки логики там тоже можно допустить… Хотя сам дизайн языка и программ отсекает львиную долю ошибок, возможных в императивных языках. Так что тестировать все же придется, — на то есть GHCI и QuickCheck. Опять же, от регрессий язык полностью страхует…

                                      Вы-то, конечно же, это знаете, но чтобы другие чего про Haskell не думали.

                                      Кстати, в Лаборатории Касперского есть должность SDET — Software Design Engineer in Test. В моем отделе два SDET'а занимаются очень интересными и любопытными вещами (Load Testing, Performance Testing, другие автоматические тесты...). У них есть куча инженерной работы. Есть и инструменты красивые. И графики там тоже рисуются очень-очень. :) В общем, работа — интересная и не простая.
                                        +1
                                        > язык полностью страхует…
                                        НЕ страхует.
                                      +2
                                      Честно говоря статья мне и в оригинале не понравилась. В целом ниочем. Плюс выдранные из контекста высказывания тех или иных товарищей. По-моему такие мифы и придумывают авторы таких статей.

                                      Почитайте лучше упомянутого в статье Виттейкера,
                                      цикл 7 plagues of Software Testing, перевод jnechaeva
                                      И the future of software testing, коллективный перевод

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

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