Pull to refresh

Comments 36

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

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

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

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

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

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


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

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

Во первый, не стоит путать теплое с мягким. 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 значительно преувеличены.

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

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

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

Да, юнит-тестирование помогает добиться покрытия кода, равное 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».

Прекрасно.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вы не грокнули TDD. Вот как раз для TDD не надо иметь полные детальные спецификации, потому что эти спецификации появляются в ходе написания тестов. А входными данными являются требования.
А, да, еще один пункт хотел написать, но забыл: есть на удивление большой пласт разработки, который «традиционные» QA-инженеры тестируют с, так скажем, некоторым трудом, а именно все machine-machine-решения — веб-сервисы, прокси, гейты, агенты и так далее. По факту, чтобы протестировать такое решение, нужно обладать хотя бы минимальными (а иногда — и не минимальными) навыками программирования.
Only those users with full accounts are able to leave comments. Log in, please.