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

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

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

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

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

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

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

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

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

    Спасибо.

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

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

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

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

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

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

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

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

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

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

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

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