К основному контенту

Нужны ли тестировщики, если разработчики пишут тесты?

Ура, вопрос из зала после статьи о разработчиках и тестах:

"Я вот все никак понять не могу. У тебя очень много всяких постов встречается про то, что тестировщики не особо то нужные люди... это вот как? В смысле, ты сам как считаешь - нужны они или не нужны? :) Никак твою точку зрения не могу понять".

Никита Макаров, комментируя предыдущий пост, очень хорошо написал:
"В цепочке "вася пишет говнокод, петя делает говнотест, находим баги, все при деле" все очень хорошо и складно, кроме сроков.Если вася начинает писать через (или с помощью) тестов хороший код, а петя не находит баги серьезные баги, то встает два вопроса : 1) зачем нам нужен такой петя ? 2) где взять такого петю который действительно будет полезен?"

Действительно, зачем нам нужен такой Петя? Такой Петя нам не нужен, потому что см.картинку.

Но нам очень нужны правильные тестировщики, хорошие . Мне такие попадались :)

Где их взять? Хороший вопрос, но пока похоже риторический...
Кроме капитанского "учить, искать" ничего на ум и не приходит.

Из интересного на эту тему (свеженькое после #xpdays):
Добавка по комментариям: вопрос "нужны ли тестировщики" возникает регулярно. На самом деле вопрос неоднозначный и требует рассмотрения в конкретных условиях: размер проекта (в т.ч. его возраст, широта предметной области), частота релизов, цена ошибки, какие процессы и тд. Но в общем и целом - нужны.

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

Вопрос скорее надо ставить как "зачем нам нужны тестировщики?", чем их наличие может помочь в достижении поставленной цели и что они должны делать.

"Making the product do something is not a test. Making the product do something, challenging it, observing it, evaluating it, with intention to learn something about it—and with special focus on risk, on discovering problems that matter, and on not being fooled... THAT's a test." (с) Michael Bolton

Что могут делать тестировщики, если разработчики сами занимаются автоматизацией тестирования:
- менторством и обучением разработчиков тестированию
- часто полезно иметь в команде человека, основная задача которого фокусировать команду на качестве
- они могут быть экспертами в продукте или бизнес-домене и больше заниматься аналитикой требований
- если у вас много UI, то скорее всего вы никуда не уйдете от необходимости проводить исследовательское тестирование
- мониторингом и анализом того, как продукт работает у пользователей

Alan Page дает свои варианты ответа на этот вопрос.


Комментарии

  1. А почему плохие программисты нам нужны? Тоже не нужны, и Васю тоже нах, раз говнокодит.


    Хотите хороших тестировщиков? У меня есть рецепт - платите им как хорошим программистам. И сами удивитесь, в каком количестве они начнут появляться.

    ОтветитьУдалить
  2. Леша, отличный комментарий - дает возможность ответа на каждую строчку :) Спасибо.
    1. Вопрос ставился "нужен - не нужен". Ответ "нужен". А дальше какой именно.
    2. К сожалению, а может и к счастью, по отношению к разработчику вопрос таким образом не ставится - не будет разработчика, не будет и кода.
    3. Правильнее говорить не о людях, а о роли "тестировщика": занимается ли человек только тестированием или чем то еще.
    4. Думаешь вопрос с деньгами решит проблему? Не получится ли так, что у нас появятся дорогие "кликеры"? Мне кажется, это должно решаться комплексно: профессиональная работа должна оплачиваться достойно. Просто повышение зп не повысит квалификацию, надо еще что то делать.
    Ну и добавил немного в пост пояснений.

    ОтветитьУдалить
  3. >>У меня есть рецепт - платите им как хорошим программистам.
    Даже конторы которые хорошо платят тестировщикам задают себе такие вопросы - а зачем ?

    ОтветитьУдалить
  4. Короткий ответ на вопрос - да, нужны.

    Потому что все что создают проектные команды - это коллективная ментальная модель. (см.первоисточник http://www.arkhipenkov.ru/resources/sw_project_management.pdf ,стр.11). Эту модель кто-то как-то должен валидировать и верифицировать.



    Цена ошибки, длительность цикла разработки, размер проекта,тип и особенности компании - играют роль, определяя количество тестировщиков и цветовую дифференциацию штанов между ними.


    В остальном - разработка программного обеспечения - это тоже самое производство. И как любой инженер на производстве в силах влиять на качество результата своей работы, так же и программист/аналитик/тестировщик в силах влиять.

    ОтветитьУдалить
  5. Даже мой рецепт не серебряная пуля. Вопросы задавать - это правильный подход.
    Вообще я сошлюсь на вебинар Дорофеева про кроссфункциональные команды, который в общих чертах моделирует то, что я имею ввиду. Для того, чтобы получился продукт нужно прокастить комбинашку из синих, зеленых и красных ман. Аналитик кастит синюю ману, программист - зеленую, тестировщик - красную и получается радость заказчика. Любой из них в принципе может кастить ману другого, но по невыгодному курсу, т.е. тестировщик может тоже код писать с "С++ за 21 день" на столе, но медленно и плохо.
    А те кто кастят коричневую ману не нужны нигде, ни в аналитике, ни в тесте, ни в программировании, потому что остальные должны прилагать усилия, чтобы перекрасить коричневое в правильный цвет.

    ОтветитьУдалить
  6. Для желающих: видимо этот доклад Макса имеется ввиду http://www.youtube.com/watch?v=Pe5M1izpb_0

    ОтветитьУдалить
  7. Вот тут http://ru.qahelp.net/question/nuzhny-li-testirovshhiki-esli-razrabotchiki-pishut-testy/ параллельное обсуждение обнаружилось

    ОтветитьУдалить
  8. Низкими ценами профессия позиционируется как "легкий старт, но и невысокий потолок", поэтому туда часто идут 1) те, кто доволен и невысоким заработком 2) те, кто считают тестирование - "первым шагом". В обоих случаях - не оптимальная реклама профессии.


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

    ОтветитьУдалить
  9. Развернутый и очень адекватный ответ на аналогичный моему вопрос http://about98percentdone.blogspot.ru/2014/12/thinking-about-no-test.html
    Жаль только что читать неудобно: белое по черному. Мне глаза выжигает :)

    ОтветитьУдалить
  10. :) и пинок мне и лучи смерти Disqus-у от автора предыдущего линка http://about98percentdone.blogspot.ru/2014/12/more-on-no-testers.html

    ОтветитьУдалить

Отправить комментарий

Популярные сообщения из этого блога

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub. Ниже попробуем порассуждать в чем их сходство и различие, как и для чего они применяются. Проверять работоспособность тестируемого объекта (system under test - SUT) можно двумя способами: оценивая состояние объекта или его поведение. В первом случае проверка правильности работы метода SUT заключается в оценке состояния самого SUT, а также взаимодействующих объектов, после вызова этого метода. Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT. Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы. Теперь подробнее. Gerard Meszaros использует термин Test Double (дублер), как обозначение для объе

Заметки на коленке - 3. Что еще делать, если ваши тесты уже "зеленые"?

"Lately I find I'm working on automated tests that return non-binary results. Tests that neither pass nor fail" by  @noahsussman Отличная мысль, которую я ретвитил еще в 2016. Но давайте вместе подумаем, что за этим может скрываться? ( кстати, не знаю, что при этом думал Noah ) Ваши тесты прошли и прошли "успешно". Все хорошо или все же есть, куда еще посмотреть? Дальше то, что использовал я лично и то, что еще можно прикрутить дополнительно. Естественно все шаги ниже должны быть автоматизированны. 1. Контролируйте время выполнения тестов. Если набор проверок не меняется (а такое часто бывает, к сожалению), то рост времени выполнения может говорить о проблемах в продакшен коде (чаще всего) или проблемах с окружением. 2. Контроль за количеством выполняемых тестов. "Все зеленое" не значит, что сегодня выполняли те же Х тестов, что и вчера. Смешно(нет), но случается такое, что какие-то проверки "исчезают" из запуска из-за того, что у кого-то &qu

Полезные ресурсы для молодых (и не только) тестировщиков

сперто(с) Уже 3 месяца провожу собеседования тестировщиков (март 2016). Поначалу они просто  веселили - после 15-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем-то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.