четверг, 28 августа 2014 г.

Rapid Software Testing for Programmers

Недавно наткнулся на интересный тренинг, который проводит Джеймс Бах (James Bach) "Rapid software testing for programmers".

Там Джеймс пытается рассказать разработчикам, что тестирование - это не только и не столько юнит-тесты, TDD и тому подобные вещи. Насколько я понимаю, сам тренинг основан на другом тренинге, который проводит Джеймс - "Rapid Testing Framework"

Я бы с удовольствием сходил на нечто похожее здесь. Может программный комитет SQADays сможет как-нибудь организовать такое мероприятие? :)

А мы пока давайте посмотрим подробнее на цели, которые должны быть достигнуты после тренинга:

  • научится (а скорее попробовать научится) думать как тестировщик (разработчики действительно думают по-другому)
  • понять, что тестирование нельзя автоматизировать. Также как и разработку. Неожиданно, правда? :)
  • а вот фактические проверки автоматизировать можно. Опаньки - вот оно че, Семен Семеныч :)
  • узнать, почему представление тестирования как просто набора проверок - это плохо.
  • понять, в чем разница между тестировщиком и разработчиком, который сам тестирует свой код
  • "Perform exploratory test design, using focusing and defocusing heuristics" - вот тут я сдаюсь с переводом, боюсь в терминах напутать
  • понять что такое "тестируемость", почему это важно и как это внедрять (взращивать).
Со своей стороны могу заметить, что зачастую роль тестировщика глазами разработчика видится весьма упрощенно - это некто, кто проверяет. Ну и, в особо тяжелых случаях, тот кто отвечает за качество. То есть как раз то, что хочет выбить из разработчиков Бах.
Кто в таком положении дел виноват сказать сложно. Скорее всего, часть вины лежит и на тестировщиках, которых сами себя так видят. Интересно, что в книжке "Как тестируют в Google" на это тоже обращают внимание.

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

Пару лет назад я рассказывал про то, что такое тестировщик в моем представлении - радует, что это совпадает с вышеописанным.

Иногда, пока я про такое слышал только в отношении крупных компаний типа Google, Microsoft, появляется новая роль "разработчик в тестировании". Эти люди помогают писать тесты, помогают делать код тестируемым, разрабатывают утилиты для тестирования. Что то близкое я слышал и про команды тестирования в Яндексе или группу спецназа автоматического тестирования в Одноклассниках (Никита, привет :) ).

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

А кто-нибудь из читателей был на тренинге про Rapid Testing Framework? 

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

  1. Екатерина Кудряшова9 сентября 2014 г., 7:11

    А ты читал "Как тестируют в Google"?

    ОтветитьУдалить
  2. Дмитрий Ильин9 сентября 2014 г., 13:16

    Добрый день Максим, спасибо за пост и спасибо за ваш доклад в DataArt, я там был ;) Хочется поделиться собственным опытом и услышать какие-нибудь советы ))
    Я программист, но мне очень интересны практики повышения качества продукта, поэтому в своей небольшой компании (около 100 человек), я разными способами проталкиваю идею перехода от "кликанья" к автоматизации рутины (написания тестов на проверки), а также test-driven разработку (надеюсь я ее правильно понимаю). Для этого делаю мини фреймворки, чтобы предоставить более понятный API для тестировщиков. Прежде чем приступать к реализации нового функционала, сначала думаю о том как его будут тестировать другие участники разработки. Также был опыт встраивания отдельной "подсистемы" в продакшн, для того чтобы бизнес-аналитики и тестировщики, могли тестировать функционал через UI.
    Конечно есть проблемы.

    1. В глазах тестировщиков читается "нафига мне это надо, мне надо просто проверить", ну или "классная штука, но я не умею (нехочуучиться?) писать код".

    2. В глаза коллег программистов читается "тебе чего, больше нечем заняться" или "забей, всех багов не найдешь".

    3. Надо как-то внушить коллегам идею что прежде чем разрабатывать функционал, надо сначала подумать как мы его будем тестировать. Сейчас приблизительно:

    - аналитик: пускай думает служба тестирования
    - программер: я пишу код, пусть его тестируют аналитики и служба тестирования
    - служба тестирования: нафигачили тут, как это тестировать??? ну ладно, главное чтобы не падало...
    - PM: о есть баги, ну с кем не бывает, мы выпустим N фиксов
    - саппорт: OMG, новая версия....

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

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

    Может у вас есть предложения как побороться с этими проблемами? И стоит ли вообще бороться, может лучше найти контору где это востребовано? :)

    Спасибо.

    ОтветитьУдалить
  3. Отличный комментарий, Дмитрий! Судя по всему, с момента нашего последнего общения почти 3 года назад тут http://maxshulga-ru.blogspot.ru/2012/02/dataart-it-talk-spb-2.html#comments , у вас все же произошли позитивные изменения :)

    Я тоже часто сталкиваюсь с перечисленными проблемами, и по своей работе, и по опыту коллег.
    По поводу п.1 - вы придумали, по моему, наилучший способ. Это именно то, что нужно. Мы тоже такое делаем, и в виде, назовем это так, семинаров и в виде личного общения. Чем раньше тестировщик узнает о том, что именно ему придется проверять, тем меньше разработчику потом переделывать - это ФАКТ. И многие тестировщики только приветствуют это. Я рассказывал про этот подход на тестерских посиделках http://sqagroup.spb.ru/announces/test-management-meeting-15/ - вызвало бурное одобрение. Скорее всего и у вас найдутся такие правильные товарищи. И тестировщики будут пинать разработчиков других команд требуя проводить подобные мероприятия.

    П.2 - тут мне, как техлиду, немного проще. Набор тестов на функционал (неважно каких по типу) выставлен как Definition of Done для разработчиков и это является критерием отбора разработчиков в команду. К сожалению, тут я повторю свой коммент из поста про доклад, без начального "воздействия" (или непротиводействия) от начальства ничего не получится. Дальше проще - когда первый раз разработчик находит багу в коде через тесты - это как подсаживание на иглу, дальше сложно их не писать. Могу сказать, что за полугодовую работу прошлого релиза мы в багтрекере имеем около сотни багов (без тестов их раза в 4 больше), большая часть которых - это именно те, что и должны прилетать от тестировщиков - баги на "ненаписанный" функционал. То, что заявлено как рабочее (через тесты) - работает. К сожалению, пока через это не пройдешь лично - никакие увещания не помогут. Это просто показатель профессионализма. Вам можно попробовать выискивать примеры того, как ваши тесты помогли найти багу, расширить функционал без поломок и рассказывать про это на тех же самых семинарах, только для разработчиков. Попробуйте - может получится. + см. про п.3

    П.3 Обычно сложно объяснять то, что кажется Вам очевидным :) Попробуйте привлечь опыт гуру "правильные пацаны делают все правильно". Это можно взять из книг, докладов и статей. Например "The Clean Coder", "The Pragmatic Programmer, From Journeyman To Master", "Совершенный код". Это для коллег-разработчиков. Для общения с коллегами из смежных областей расширяйте кругозор книгами. По product management начать можно с "Inspired: How To Create Products Customers Love" http://maxshulga-ru.blogspot.ru/2012/01/inspired-how-to-create-products.html). По тестированию много и книг, и статей (можно у меня по тегу "тестирование" тоже почитать). Без этого вам будет сложно говорить убедительно - ссылки на опыт известных товарищей могут Вам тут помочь.

    А фантазии ваши правильные - не останавливайтесь.
    "может лучше найти контору где это востребовано" - иногда это тоже вариант. А вы на каком языке пишете? ;)

    ОтветитьУдалить
  4. Дмитрий Ильин9 сентября 2014 г., 16:12

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

    Еще раз спасибо, книги очень кстати.
    P.S. C#

    ОтветитьУдалить
  5. Екатерина Кудряшова9 сентября 2014 г., 16:51

    А то я думаю, почему не было статьи на эту тему.... :)

    ОтветитьУдалить
  6. А тебе интересно? :) Я сомневался писать или нет. В инете полно обзоров уже было.

    ОтветитьУдалить
  7. Холивар происходит от незнания. Вообще до боли знакомая тема: никто не пишет тесты, но все знают как это делать "правильно"... Проходили :(
    Насчёт "бородатых" всезнающих программистов - могу только посочувствовать. Тоже больной вопрос, даже для меня :)
    Значит остается заниматься самообразованием, пробовать на практике и стараться показывать все начальникам. Я думаю при таком подходе есть шанс: нудный дятел может задолбать небольшого слона :)
    Ну и если в этоге не получится - хуже от этих знаний и умений точно не будет.

    ОтветитьУдалить
  8. Екатерина Кудряшова9 сентября 2014 г., 23:42

    Ну я в интернете только тебя да Эдуарда читаю :) Так что пиши, если не лениво. Будем читать... тем более начальство новые задачи ставит... надо начинать разбираться в этой области :)

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