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

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? 

Комментарии

  1. Екатерина Кудряшова9 сентября 2014 г., 07: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

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

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

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

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

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-летнего опыта собеседования С++-разработчиков, общение с тестировщиками (чаще были "-цы") было чем то экзотическим и забавным. Потом становилось все грустнее и грустнее, мимими закончилось. Началась печаль.