Судный день QA

    Это перевод статьи Eli Lopian, основателя компании Typemock. Он же является исполнительным директором корпорации. Eli имеет более чем 17-летний опыт в сфере разработки. За это время он успел поработать в таких глобальных организациях как AMDOCS (NYSE:DOX) и Digital Equipment Corporation (DEC). В его обязанности входила оптимизация процесса разработки и внесение необходимых корректировок для поддержания его эффективности. Данная статья поясняет как unit-тесты повлияют на традиционный подход к тестированию в будущем, и какой эффект они имеют уже сейчас.

    image

    С начала Промышленной Революции, около 250 лет тому назад, машины активно стали замещать человеческий труд на заводах, фабриках и шахтах. С одной стороны это ведет к увеличению экономического роста, с другой – к увольнениям рабочих, чей труд был заменен. Часто люди после увольнения не в состоянии найти новое место работы или заняться переобучением. То, что сейчас происходит в области QA поразительно похоже на описанные выше процессы. Только взгляните на невероятный прирост количества компаний, занимающихся тестированием, как например Mercury Interactive, на протяжении девяностых годов прошлого века. Процесс тестирования и сами команды QA пришлись весьма кстати во времена интернет бума в девяностых. Тогда количество программ, выпускаемых на рынок, возрастало экспоненциально. Это привело к росту числа инструментов разработки и расширения штата тестировщиков. Однако, со временем неудержимый рост экономики стал постепенно спадать, бюджеты становились все скуднее, все более широким становилось применение Agile-методологий, само программное обеспечение становилось более широко распространённым и автоматизированное тестирование набирало обороты. Перед ручным тестированием встали те же проблемы, что были характерны для ручного труда на предприятиях во время Промышленной Революции. Многие QA инженеры стали переходить на новые должности, подразумевающие использование навыков программирования и разработки в повседневных задачах. Команды тестирования стали подвергаться изменениям, становиться многофункциональными. Границы между департаментами постепенно начали сходить на нет.

    Но давайте вернемся на несколько шагов назад и посмотрим, а как же было раньше. Подавляющее большинство компаний выбирали водопадную модель разработки с 1950-х годов. Такой подход позволял команде сначала полностью спроектировать дизайн, затем сконцентрироваться на коде, передать его тестировщикам и после – начать исправлять дефекты. Поскольку разработчики постоянно находятся под давлением, они начали полагаться больше на отдел QA. Это привело к замкнутому кругу. Нанимаются новые тестировщики, разработчики еще больше расслабляются и передают в QA более сырой код. В какой-то момент девелоперы вовсе перестали тестировать свой код.

    Это крайне негативно сказалось на эффективности работы и в конечном итоге вылилось в срыв сроков контракта. Конечный продукт не попадал к заказчику к запланированному моменту.

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

    Больше тестировщиков – больше проблем

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

    1. Пополнить бюджет – всегда можно добавить больше денег, тогда можно будет уложиться во время. Но следует учитывать, что тогда и возврат от инвестиций будет меньше. Всегда следует учитывать все риски. По итогам проведенного анализа, вы можете прийти к выводу, что дальнейшие инвестиции не целесообразны. Не самый лучший из вариантов.
    2. Отказаться от части функционала – ни разработчики, ни руководство не хотят поставлять клиенту программу, которая не делает того, чего от нее ожидают. Это также не выход.
    3. Оставить качество на низком уровне – в повседневной жизни мы часто встречаемся с теми или иными дефектами. Что касается программного обеспечения – качество продукта здесь играет первостепенную роль. Тем не менее, третий путь становится наиболее распространенным среди компаний.

    В результате мы получаем нарушение привычного порядка – с одной стороны разработчики либо заняты, либо ленятся довести свой код до оптимального уровня, с другой стороны – менеджмент урезает расходы на тестирование. Вот где могут помочь принципы Agile.

    Преимущества Agile

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

    После интернет бума и последующего отката в росте экономики, компании осознали необходимость выпуска высококачественного софта без высоких расходов на его производство. Но как урезать затраты на QA?

    К счастью, Agile методология предполагает тестирование своего собственного кода. Прохождение юнит-тестов говорит о том, что выбранный модуль работает и выполняет свою функцию. Конечно, это подразумевает тесную кооперацию всех отделов. Продакт менеджер определяет, каким должна быть программа, чтобы отвечать требованиям заказчика. Разработчики и тестировщики вместе работают над написанием спецификаций. Далее девелоперы пишут юнит-тесты для своих модулей. Корректно протестированый код – единственный способ доставить работающую программу, так сказать, ядро Agile процесса. Проведенное по стандартам, юнит-тестирование подтверждает, что код работает так, как задумывал программист. Отдел QA все еще осуществляет тестирование нестандартных ситуаций, в то время как разработчики постепенно начинают осознавать ответственность за качество своего кода. Одним из фундаментальным столпов методологии Agile является работающее ПО. А некоторые принципы приведенной методологии, такие как TDD (Test Driven Development) и юнит-тестирование выполняются девелоперами. Так в чем же суть юнит-тестов и почему их стоит использовать? Особенность юнит-тестирования в том, что оно выполняет проверку определенного участка кода. Когда каждый следит за своим модулем, эффективно и быстро правит найденные дефекты – стоимость всего проекта снижается. Без четко поставленного процесса юнит-тестирования крайне трудно оставаться в рамках Agile. Все эти бесконечные изменения требований, дизайна и самого кода в конечном итоге приводят к еще большему количеству дефектов, и без знания их специфики, разработка рискует закончится провалом.

    Юнит-тестирование – возможная причина смерти QA
    Повторим: юнит-тестирование есть процесс, направленный на проверку работоспособности вашего обособленного участка кода. Заканчивается он только тогда, когда есть уверенность, что данный кусочек гармонично впишется в общую картину системы. Доказано, что применяя юнит-тестирование можно добиться покрытия кода, равное 90 процентам, и, в отличие от ручного тестирования, юнит-тесты могут, со временем, эволюционировать для решения более сложных задач.

    Только не подумайте, что основная мысль статьи – юнит-тесты спасут мир. Они не являются панацеей. Однако, это наиболее подходящие кандидаты для тестирования кода, из-за их низкой стоимости. К тому же, конечный продукт получается более качественным и удается сократить сроки.

    Если вы применяете QA отделы, то процесс затягивается. Баги отправляются к разработчикам, затем их изменения идут обратно к тестировщикам. Применение же юнит-тестов минимизирует вероятность дефектов, как только разработчик закончил работу над своим модулем.

    Выводы

    Как можно судить из названия статьи – QA более нежизнеспособно, в традиционном понимании. Тем не менее, мы все еще можем видеть повсеместное применение QA. Вопрос в том, как долго это продлится? Лично я придерживаюсь мнения, что в скором времени задачи тестирования перейдут непосредственно к разработчикам и специалистам QA придется подстраиваться под новый порядок.

    Да, мы все еще будем видеть тестировщиков, но они скорее будут частью команды разработки, нежели отдельного департамента. Содержание QA в условиях применения Agile становится слишком дорогим, поэтому тестировщикам придется меняться.

    Я искренне считаю, что мы движемся на пути к светлому будущему, где разработчики будут писать более совершенный, качественный код. Дело остается за руководством корпораций. Перед ними есть пути снижения затрат и выпуска конкурентоспособных продуктов. Им остается их применить.

    Перевод статьи «The Day the QA Department Died», Eli Lopian.
    www.infoq.com/articles/day-qa-dept-died
    Luxoft
    think. create. accelerate.

    Comments 36

      0
      Мне кажется вывод QA более нежизнеспособно, в традиционном понимании, все-таки слишком пессимистичный. Да, примерно 90% проблем можно покрыть юнит, интеграционными, модульными и другими видами автоматизированных тестов, но все равно 10% проблем (и зачастую самых серьезных) можно обнаружить только при ручном тестировании. Да, возможно в крупных компаниях количества QA инженеров будет сокращаться и вместо десятка QA инженеров в проекте, будет участвовать 1-2, но все равно будет стадия традиционного ручного тестирования.
        0
        Согласна с Вами. Речь в статье идет о постепенном вымирании QA именно в традиционном понимании. Естественно, что инженеры-тестировщики все еще будут играть какую-то роль в процессе разработки, но я думаю, автор хотел сказать, что эта роль постепенно будет снижаться. И сам QA будет со временем меняться, интегрироваться с Dev
          +1
          Вот как раз отмирание традиционного QA (превращение QA инженеров в полуразработчиков/полутестировщиков) сомнительно, как и интеграция с Dev. Дело в том что смысл QA именно в возможности посмотреть на продукт со «стороны», а в тесной интеграции с Dev этого не будет, «глаз» замыливаеться и сложно судить беспристрастно.
        +1
        Если «задачи тестирования перейдут непосредственно к разработчикам», то кто те тестировщики, которые вместе с разработчиками работают над спецификациями, на основании которых пишутся автоматизированные тесты?

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

        Разработчик и тестировщик (равно как разработчик и аналитик) — это два перпендикулярных направления деятельности, с конфликтующими (в краткосрочной перспективе) интересами. Совмещать эти роли, особенно по отношению к собственному коду — очень тяжело.
          0
          Благодарю за интерес к статье и ценное замечание. Действительно, есть задачи, с которыми наиболее эффективно справятся обученные, высококвалифицированные тестировщики. Думаю, в статье имеется ввиду, что в ближайшее время будут сокращаться команды QA, и как правильно заметил, предыдущий комментатор – для решения таких нетривиальных задач в штате будет 2-3 человека. Что касается противоположных ролей разработчиков и тестировщиков (как и разработчиков и аналитиков) – совершенно верно, но что если со временем будут появлятся новые роли на проекте, и эти роли будут совмещать в себе несколько направлений развития? Как предположение.
            +1
            что если со временем будут появлятся новые роли на проекте, и эти роли будут совмещать в себе несколько направлений развития

            Я уже написал: нельзя совмещать роли с конфликтующими интересами. Человек не может постоянно менять приоритеты в голове.
              0
              Да, согласен. У разработчика задача сделать побыстрее, у QA сделать качественнее. Плюс, есть проблема в том что если ты сам разрабатываешь, сам тестируешь, сам создаешь unit test'ы, то с большой вероятностью можешь допустить одну и ту же ошибку во всех трех случаях, потому что глаз «замыливается», да и просто у программиста одни навыки, у тестировщика другие, физически невозможно (или почти невозможно) быть лучшим во всем, соответственно качество либо разработки, либо тестирования будет страдать.

              Например, я написал код на Java:

              void double getDivided(Integer i1,Integer i2) {
                return i1/i2;
              }
              


              Я тут не подумал, о делении о ноль, о том что i1 и i2 могут быть null, о том что при делении двух целочисленных величин произойдет округление. Какой шанс, что не подумав об этом в коде, я подумаю об этом когда буду писать unit test'ы или тестровать вручную? Да, что-то я смогу чисто случайно обнаружить, но QA сможет найти ошибки целенаправленно.
                0
                У разработчика задача сделать побыстрее, у QA сделать качественнее.

                Вот это как раз ошибочное представление. У разработчика задача реализовать требования (в срок, с минимальными усилиями и, что важно, следуя принятым в компании правилам по качеству кода), а у тестировщика задача — проверить, что система ведет себя согласно требованиям, а в местах, где она требованиями не покрыта — ведет себя «разумно». Оба отдают себе отчет в том, что оба могут ошибаться, поэтому их деятельность комплементарна (в каком-то смысле — как у автора и редактора).
                  0
                  Как когда то сказал мой лидер-тест — задача QA не избавить проект от багов, а сделать так, чтобы все баги были задокументированы.
                  Как то склоняюсь к этой мысли.
              0
              Не будут, нельзя беспристрастно судить то что сам разрабатывал сам. Плюс, очень большой соблазн, где-то сделать по быстрому, в расчете что это все равно никому не нужно.
            +8
            Статья любопытная, но во многом, мне кажется, желаемое в ней выдается за действительное.

            Во первый, не стоит путать теплое с мягким. QA (Quality Assurance) с QC (Quality Control). Прежде всего, и это очень важно, QA — это не команда тестирования. Это процесс, в который, среди прочего, включается тестирование ( оно же QC).

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

            Но разве это остановит (уничтожит?) тестирование как процесс? И тем более, разве это уничтожит процесс QA?
            Я думаю вряд ли.

            Код может быть покрыт сотней unit-тестов, но это еще не значит, что он выполняет нужную функцию.
            Вы можете рассмотреть каждый code-change в сотне code-review, но это не значит что ваша библиотека успешно интегрируется с библиотекой, написанной другой командой.

            Нужен ли QA на каждый проект по разработке веб-сайта компании ООО «Вектор»? Наверное — нет.
            Нужно ли QA платформы интернет-платежей? Я уверен — да!

            Необходимость (и умение проводить) performance, security, usability (и еще over 9000) видов тестирования никуда не уйдет. Кто бы вы думали это все будет делать?

            В конце концов, толку от вашего unit-теста, если кнопка на UI размеров в 1 пиксель и белого цвета на белом фоне, или ваш веб сервис уходит в глубокое размышление при попытке обработать два параллельных запроса с одинаковым id.

            Идея уволить всех QA всегда будет будоражить умы людей. Любой здравомыслящий руководитель хочет сделать то же самое с меньшим количеством людей.
            Но мне кажется что слухи о кончине QA значительно преувеличены.

              0
              отличный комментарий, по делу.
              хотел бы добавить, что количество неквалифицированных тестировщиков с годами неизбежно сократится, они станут не нужны (так же, как и любые специалисты, которые не приносят пользы). так что это не отрасль QA умирает, скорее, эволюционирует в лучшее, но меньшее. хороших разработчиков тоже найти далеко не просто
              +3
              Эли рассуждает так, словно между «тест-кейс» и «юнит-тест» разница всего лишь в том, что они выглядят по-разному, а результат один и тот же. Но это то самое слабое звено в рассуждениях, которое всё рушит.

              Юнит-тестирование (оно же процесс, направленный на проверку работоспособности обособленного участка кода) описано излишне абстрактно. Участок кода — это сколько? Это одна функция? Или это функциональная возможность, которая реализуется одним, или двумя, или шестью методами, которые работают по-отдельности?

              «Юнит-тестирование заканчивается только тогда, когда есть уверенность, что данный кусочек гармонично впишется в общую картину системы» — и что, если впишется? Красивый глаз достаточно гармонично вписывается в лицо урода — результат какой будет?

              Да, юнит-тестирование помогает добиться покрытия кода, равное 90 процентам. Да хоть 101% покрытия. А смысл в таком покрытии? :)

              И, в отличие от ручного тестирования, юнит-тесты могут, со временем, НЕ СМОГУТ эволюционировать для решения более сложных задач. Как гайка не эволюционирует в карбюратор.

              В общем, странный текст. Автор, вроде, не дурак. Полез смотреть, что это за компания, которую он представляет. А там американским по-белому написано: «Smart Unit Testing, Made Easy with Typemock. Typemock provides the best mocking framework for over 7 years, we were the first and are the leading framework. Agile and TDD development require unit testing, which in turn requires mocking».

              Прекрасно.

              А у меня бизнес по выращиванию лягушек. Рассказать вам о том, как прекрасны лягушки в обеденном супе? Верьте мне, о бармаглоты, что лягушки могут, со временем, эволюционировать для решения более сложных задач в кулинарии! (со страстью аккуратно рвя на себе галстук) Грядет тот день, когда помощники поваров по супам и соусам не будут нужны! Лягушки — будущее индустрии кастрюлек и половников! У меня бизнес! Давайте рассуждать о лягушках, пожалуйста!
                +1
                Я думаю, что понятие юнит-теста использовано некорректно. Это как если бы мы утверждали, что машина хорошо поедет, если все компоненты в отдельности качественно протестированы. Юнит-тесты — это необоходимое условие, но не достаточное. Я думаю, достаточным условием является глубокая автоматизация функциональных тестов и грамотная композиция интеграционных. Если вы хорошо автоматизируете — например, можете качественно сэмулировать паттерны пользовательской активности на основе уже накопленной статистики и сделать на основе этого выводы о качестве и регрессии функционала — вот это и есть современный QA. И это, понятно, совсем уже не ручная задача, а в некоторых местах даже не столько инженерная, сколько научная.
                  0
                  Сама идея юнит-тестов, которые пишет тот же человек, который пишет код, представляется порочной. Если ситуация, приводящая к ошибке, не предусмотрена программистом, то она и в коде не будет отработана, и в тестах тоже. И что толку, что этот код на 100% покрыт тестами? Мантра, не более.
                  Тестирование должно быть в первую очередь независимым. А автоматическим или ручным — это уже зависит от возможностей автоматизации.
                  Юнит-тесты могут помочь, но заменить полностью независимое тестирование ИМХО они не смогут.

                    0
                    А вы просто не понимаете смысла юнит-тестов, судя по вашей фразе. Их задача не в том, чтобы предусмотреть все ситуации, их задача в том, чтобы автоматизировать предусмотренные ситуации. Проще говоря, даже если юнит-тесты будут писаться на (а) полное покрытие требований и (б) полное покрытие багов, от них уже будет очень много пользы.
                      0
                      Юнит-тесты могут гарантировать соблюдение требований.
                      Но как можно написать тест на полное покрытие багов, если баг — это по определению непредусмотренная ситуация?
                        0
                        После обнаружения. Такой тест гарантирует, что баг (а) поправлен и (б) больше не повторяется.
                          0
                          А баг обнаруживать должен как раз специалист по тестированию, если конечно мы не хотим выдавать сырой продукт пользователю.
                          Отсюда я и делаю вывод, что автор статьи не прав. Юнит-тесты — это полезная вспомогательная технология, но независимое функциональное тестирование они не заменят.
                            0
                            Юнит-тесты действительно не заменят независимое тестирование, но ничего порочного в «идее юнит-тестов, которые пишет тот же человек, который пишет код» нет. Более того, практика TDD на этом основана (и там юнит-тесты — не вспомогательная, а основная технология).
                              0
                              Вам не нравится эпитет «порочная», хорошо, я его заменю на «ограниченная».

                              Если качественные юнит-тесты по моей оценке — это ИМХО удвоение времени кодирования, то TDD — это утроение времени. При том, что стоимость часа QA-инженера может быть в разы меньше, чем разработчика…

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

                              Это мои оценки, но очень интересно было бы пообщаться с теми, кто реально это использует.
                                0
                                Вам не нравится эпитет «порочная», хорошо, я его заменю на «ограниченная».

                                А вы знаете «неограниченные» тестовые практики? Я — нет.

                                Если качественные юнит-тесты по моей оценке — это ИМХО удвоение времени кодирования, то TDD — это утроение времени.

                                А откуда вы берете эту оценку?

                                Начнем с TDD. Почему TDD в полтора раза дороже написания кода + написания юнит-тестов, хотя TDD состоит из написания кода и написания тестов? Из-за рефакторинга? Так он все равно должен быть в разработке, поэтому это константная величина в затратах.

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

                                Банальный пример: вот у нас есть требование о том, что в таком-то поле на форме не должны вводиться такие-то слова (а все остальные — должны). Мы составляем список тестовых сценариев, включающий допустимые слова, недопустимые и, наконец, пограничные (т.е., которые формально содержат недопустимую последовательность, но по уму не должны отсеиваться). Предположим, в списке 25 слов. Сколько времени уйдет у тестировщика на прогон сценариев? А юнит-тестом они проверяются за доли секунды (и добавление каждого нового слова не ведет к заметному увеличению времени выполнения). И нет, не говорите мне про автоматизированное тестирование, потому что (а) это уже совсем другие требования к квалификации тестирования и (б) это все равно на два порядка медленнее, чем юнит-тест.

                                стоимость часа QA-инженера может быть в разы меньше, чем разработчика…

                                Вот это — порочная практика. Откуда такой разброс в стоимости часа? У них настолько разная квалификация? Их вклад в проект настолько различен?

                                Это оправдано для определенных задач, где высока цена ошибки и детально формализованы требования

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

                                Это мои оценки, но очень интересно было бы пообщаться с теми, кто реально это использует.

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

                                    Уменьшится. Потому что каждая выявленная ошибка увеличивает время тестирования и время разработки (потому что ее нужно починить, затем протестировать, что починена, затем протестировать регрессию).

                                    Сроки и стоимость разработки увеличатся.

                                    Удивительно, но в реальности наоборот.
                                    0
                                    В качестве разработчиков наиболее эффективно использовать людей уровня ведущих, а для тестирования можно взять вчерашних студентов или старшекурсников (особенно женского пола, женщины более дотошные и внимательные), отсюда и кратная разница в ЗП.
                                    В случае саомтестирования через юнит-тесты, тратится дорогое время ведущего разработчика, а в случае тестирования людьми — дешевое время, да еще и параллельно, то есть общий срок проекта сжимается.
                                      0
                                      для тестирования можно взять вчерашних студентов или старшекурсников

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

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

                                      Конечно, для нажимания на кнопки по сделанным ведущим QA инженером в можно нанять студентов, но и для рисования формочек HTML в редакторе, правки конфигов и xml можно тоже нанять студентов, но без грамотного опытного QA инженера тестирование так же развалиться, как разработка при команде студентов без грамотного опытного программиста.

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

                                        Я вообще пока не встречался с проектами, где было бы на высоком уровне тестирование организовано. Но эта тема меня очень интересует, поэтому я задаю вопросы, высказываю свое мнение, но не считаю что оно единственно верное, а наоборот, интересуюсь другими точками зрения, особенно подтвержденными практикой.
                                          0
                                          Подтвержденные практикой? Дешевые тестировщики это примерно как дешевые разработчики, могут сделать сотню issue ни о чем, могут не заметить такую багу, после которой продакшен сервер упадет.

                                          В результате, или качество будет фиговым, или несколько недель команда разработки будет страдать ерундой, пытаясь понять как пофиксить 100 issue в каждом написано «что-то где-то не работает». Не забывайте, задача QA не только сказать что что-то не работает, а максимально найти причину ошибки, так чтобы в идеале разработчик мог бы за пару минуть понять что и как фиксить.

                                          Хорошо написанные Unit-test очень важны чтобы разработчик всегда знал что он ничего не сломал. Плюс модульные и интеграцонные тесты, чтобы быть уверенным что все система не развалилась в результате рефакторинга. Намного дешевле написать тесты, чем тратить огромное время тыкаясь в проблемах вслепую. Плюс тесты позволяют легко найти проблему и по сути понять правильность дизайна и реализации, когда только начал реализацию (зачастую начав писать unit-test видишь что придумал какую-то фигню).

                                          Насчет QA, как я говорил правильное QA это которое создает свою документацию параллельно с работой бизнес аналитиков и проверят не только реализацию, но и бизнес требования. Это по опыту реализаций проектов с командой человек в 300-400 и соответствующей сложностью.
                                        0
                                        Если вы возьмете для тестирования неквалифицированных специалистов, они не смогут принимать аргументированные решения о проблемах, что приведет к дополнительным расходам времени как разработчиков, так и аналитиков. Более того, неквалифицированный тестировщик не сможет воспроизвести баг, пришедший с продуктива, или адекватно локализовать проблему, после чего ей придется заниматься разработчику, чье время вы пытались сэкономить. И это не говоря о ряде задач, которые неквалифицированные тестировщики просто не могут решать.

                                        Так что нет, в тестировании ровно то же самое, что и в любой другой области разработки ПО: наем квалифицированных специалистов выгоднее наема неквалифицированных.
                                          0
                                          в тестировании ровно то же самое, что и в любой другой области разработки ПО: наем квалифицированных специалистов выгоднее наема неквалифицированных

                                          Можно добавить, что так же как в любой другой области разработки ПО чаще всего есть работа и для неквалифицированных специалистов (тот самый бездумный ручной проход тестов), но примерно в таком же соотношении как и у девелоперов (обычно на десяток мидолов и синеров — 2-3 студента-предджуниора, которым дается та ручная работа, которую крайне сложно испортить).
                                            0
                                            Это тоже верно.
                                        0
                                        А большая у вас команда?
                                          0
                                          Пять разработчиков и двое тестировщиков.
                                          0
                                          А откуда вы берете эту оценку?

                                          Для большинства реальных задач (по крайней мере из моей прикладной области) написание качественных тестов представляется гораздо более трудоемким, чем кодирование самой задачи.
                                          Если для юнит-тестов мы можем написать код, прикинуть, какие тесты он должен проходить и написать их (то есть зная ответ, задаем вопросы),
                                          то для TDD к началу работы нужно иметь полные детальные спецификации на каждую процедуру, а кто их составит? Фактически это проектирование исходного кода до его кодирования. Обычно это делает программист в уме. Вот поэтому я считаю, что TDD еще дольше, чем unit-тесты.

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

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

                                            Заодно могу напомнить про (весьма объемные) прикладные области, где людям вообще тестировать нечего.

                                            для TDD к началу работы нужно иметь полные детальные спецификации на каждую процедуру

                                            Вы не грокнули TDD. Вот как раз для TDD не надо иметь полные детальные спецификации, потому что эти спецификации появляются в ходе написания тестов. А входными данными являются требования.
                                          0
                                          А, да, еще один пункт хотел написать, но забыл: есть на удивление большой пласт разработки, который «традиционные» QA-инженеры тестируют с, так скажем, некоторым трудом, а именно все machine-machine-решения — веб-сервисы, прокси, гейты, агенты и так далее. По факту, чтобы протестировать такое решение, нужно обладать хотя бы минимальными (а иногда — и не минимальными) навыками программирования.

                            Only users with full accounts can post comments. Log in, please.