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

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

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

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

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

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

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

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

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

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

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


Комментарии

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


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

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

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

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

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



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


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

    ОтветитьУдалить
  5. Никита, я знал, что ты напишешь хорошо.

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

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

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

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


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

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

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

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

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

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

Mock vs Stub

Когда мы начали изучать модульное тестирование, то одними из первых терминов, с которыми пришлось познакомиться, стали Mock и Stub.

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

Проверять работоспособность тестируемого объекта (system uder test - SUT) можно двумя способами: оценивая состояние объекта или его поведение.

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

Во-втором, мы проверяем набор и порядок действий (вызовов методов взаимодействующих объектов, других методов SUT), которое должен совершить метод SUT.

Собственно, если коротко, то в одном случае используется Stub, а в другом Mock. Это объекты, которые создаются и используются взамен реальных объектов, с которым взаимодействует SUT в процессе своей работы.

Теперь подробнее.

Gerard Meszaros использует термин Test Double (дублер), как обозначение для объекта, который зам…

План "Б" или как прикольно провести субботний день

Всем привет.
Вчера состоялась конференция "План Б". Организаторами выступили ребята из Яндекса, за что им большое спасибо. Судя по приблизительным подсчетам в мероприятии участвовало около 200 человек.

Основной темой конференции было планирование, планирование всего: проектов, разработки, тестирования, дизайнеров и даже организации музыкального фестиваля.
Сначала думал написать отчет в обычном своем стиле: кто и что говорил, но почитав твиттер по #pbconf понял, что просто потеряю время :) Поэтому кому оооочень интересно узнать подробности следуйте за птичкой и вы все узнаете (тэг #pbconf попал в top-30 твиттера)
Здесь приведу лишь те вещи, которые мне запали в мозг
Роман Чернин о продуктовой разработке: "нет заказчика, нет требований, нет сроков -> как принимать решения? ответ: заводим себе Product Manager-а"
Оля Павлова (@op): "бойтесь иллюзии точной формулировки" "заказчик - ребенок, выдаем ему игрушку как можно чаще" "не забываем, …

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

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

Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.