среда, 6 июля 2011 г.

Ценность тестировщика: показать и рассказать.

Задумалась недавно над вопросом: а несет ли тестирование ценность и как рассказать об этом заказчику? Не секрет, что во многих фирмах тестировщиков нет именно потому, что "они только по кнопкам бездумно клацают, деньги на них тратишь, а реальной прибыли - никакой!"
И, как частенько происходит, на глаза попалась статья в тему: в блоге Джонатана Кохля (Jonathan Kohl) наткнулась на его старенькую, но все еще актуальную статью "How do I create value with my testing". Читается она очень легко, вряд ли есть смысл переводить полностью. Но есть одна идея, которая мне в свое время очень понравилась :)))



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

Воодушевленная такой новостью я написала генеральному директору. И выяснилось, что он о процессе тестирования не знает вообще ничего! Ну, что-то там делается, что-то тестируется, а как, зачем?... И это (отмечу!) в фирме, где мысль о необходимости тестирования вынашивалась месяцами, потом столько же проводились собеседования, выбор "того самого тестировщика". Т.е. тестирование не было взято с потолка или просто потому, что "так круто и во всех крутых компаниях есть тестеры".

И тогда я, как в самых плохих анекдотах, предложила ему "поговорить об этом". В процессе говорения выяснилось многое. Например, начальству непонятно, зачем проводить какое-то тестирования, если в его процессе не находятся баги. Резонный вопрос: "А если бы нашлись?" И действительно приходилось доказывать необходимость проверки, например, исходного кода ("А зачем, ведь у нас есть код-ревью?"), или SQL-инъекций ("Зачем, ведь мы при кодинге используем все нужные меры предосторожности!").

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

6 комментариев:

  1. Я на близкую тему говорил на первой встрече московского клуба: http://testing-club.ru/2010/10/slide_mstc_1/

    ОтветитьУдалить
  2. Аналогичная проблема. Была. Пользу осознавали не все.

    Провел лекцию, собрав заинтересованных. Рассказал что и зачем делаем.

    Лейтмотив - тестировщики быстро(!) предоставляют информацию программистам, менеджерам и остальным о текущем состоянии продукта.

    В этом контексте - наличие или отсутствие найденных багов роли не играет.

    Помните, я говорил, что я не занимаюсь поиском ошибок? 1 баг в месяц на 2 человек это не поиск ошибок :)

    Я ежедневно предоставляю информацию о том, что огромный объем функционала - работает как надо.

    ОтветитьУдалить
  3. 2Алексей,
    да, я смотрела это видео когда-то, во многом согласилась, в чем-то не очень. С утверждением о том, что работа сделана хорошо, если после нее чувствуешь удовлетворение, - согласна на все 101% )))) Если после тестирования это ощущение не пришло - прямо спать спокойно не могу )))


    2Волонтер:
    А как именно Вы предоставляете эту информацию ежедневно? Какая-то стандартная форма? Или произвольное отчетоизъявление? ))

    ОтветитьУдалить
  4. Мы полгода - год назад перешли с еженедельных релизов на ежедневные. Релизу соответствует набор
    - реализованых фич
    - неисправленных багов(может быть пустым)
    - запись "сегодня АТ дефектов (не) обнаружило" (список, если есть).

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

    ОтветитьУдалить
  5. Ведется в багтрекере+вики.

    ОтветитьУдалить
  6. Спасибо.
    С такими ежедневными отчетами действительно проще.

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