Недавно наткнулся на интересный тренинг, который проводит Джеймс Бах (James Bach) "Rapid software testing for programmers".Там Джеймс пытается рассказать разработчикам, что тестирование - это не только и не столько юнит-тесты, TDD и тому подобные вещи. Насколько я понимаю, сам тренинг основан на другом тренинге, который проводит Джеймс - "Rapid Testing Framework"
Я бы с удовольствием сходил на нечто похожее здесь. Может программный комитет SQADays сможет как-нибудь организовать такое мероприятие? :)
А мы пока давайте посмотрим подробнее на цели, которые должны быть достигнуты после тренинга:
- научится (а скорее попробовать научится) думать как тестировщик (разработчики действительно думают по-другому)
- понять, что тестирование нельзя автоматизировать. Также как и разработку. Неожиданно, правда? :)
- а вот фактические проверки автоматизировать можно. Опаньки - вот оно че, Семен Семеныч :)
- узнать, почему представление тестирования как просто набора проверок - это плохо.
- понять, в чем разница между тестировщиком и разработчиком, который сам тестирует свой код
- "Perform exploratory test design, using focusing and defocusing heuristics" - вот тут я сдаюсь с переводом, боюсь в терминах напутать
- понять что такое "тестируемость", почему это важно и как это внедрять (взращивать).
Со своей стороны могу заметить, что зачастую роль тестировщика глазами разработчика видится весьма упрощенно - это некто, кто проверяет. Ну и, в особо тяжелых случаях, тот кто отвечает за качество. То есть как раз то, что хочет выбить из разработчиков Бах.
Кто в таком положении дел виноват сказать сложно. Скорее всего, часть вины лежит и на тестировщиках, которых сами себя так видят. Интересно, что в книжке "Как тестируют в Google" на это тоже обращают внимание.
Но заметьте, все больше товарищей (из последнего - клик раз и два) отмечает, что роль тестировщиков должна смещаться от проверок, к анализу требований, генерации спецификаций, сценариев и тому подобным вещам.
Пару лет назад я рассказывал про то, что такое тестировщик в моем представлении - радует, что это совпадает с вышеописанным.
Иногда, пока я про такое слышал только в отношении крупных компаний типа Google, Microsoft, появляется новая роль "разработчик в тестировании". Эти люди помогают писать тесты, помогают делать код тестируемым, разрабатывают утилиты для тестирования. Что то близкое я слышал и про команды тестирования в Яндексе или группу спецназа автоматического тестирования в Одноклассниках (Никита, привет :) ).
Пару лет назад я рассказывал про то, что такое тестировщик в моем представлении - радует, что это совпадает с вышеописанным.
Иногда, пока я про такое слышал только в отношении крупных компаний типа Google, Microsoft, появляется новая роль "разработчик в тестировании". Эти люди помогают писать тесты, помогают делать код тестируемым, разрабатывают утилиты для тестирования. Что то близкое я слышал и про команды тестирования в Яндексе или группу спецназа автоматического тестирования в Одноклассниках (Никита, привет :) ).
В небольших компаниях появление такой роли маловероятно: такие люди - разработчик в прокаченным навыком тестирования - редкость и дело даже не в их цене. Поэтому обычным разработчикам тоже надо учиться. Пока подобного тренинга у нас нет, можно почитать вот эту свеженькую книжку например. Вообще литературы масса - было бы желание изучать и меняться.
А кто-нибудь из читателей был на тренинге про Rapid Testing Framework?
А ты читал "Как тестируют в Google"?
ОтветитьУдалитьДочитываю. А что?
ОтветитьУдалитьДобрый день Максим, спасибо за пост и спасибо за ваш доклад в DataArt, я там был ;) Хочется поделиться собственным опытом и услышать какие-нибудь советы ))
ОтветитьУдалитьЯ программист, но мне очень интересны практики повышения качества продукта, поэтому в своей небольшой компании (около 100 человек), я разными способами проталкиваю идею перехода от "кликанья" к автоматизации рутины (написания тестов на проверки), а также test-driven разработку (надеюсь я ее правильно понимаю). Для этого делаю мини фреймворки, чтобы предоставить более понятный API для тестировщиков. Прежде чем приступать к реализации нового функционала, сначала думаю о том как его будут тестировать другие участники разработки. Также был опыт встраивания отдельной "подсистемы" в продакшн, для того чтобы бизнес-аналитики и тестировщики, могли тестировать функционал через UI.
Конечно есть проблемы.
1. В глазах тестировщиков читается "нафига мне это надо, мне надо просто проверить", ну или "классная штука, но я не умею (нехочуучиться?) писать код".
2. В глаза коллег программистов читается "тебе чего, больше нечем заняться" или "забей, всех багов не найдешь".
3. Надо как-то внушить коллегам идею что прежде чем разрабатывать функционал, надо сначала подумать как мы его будем тестировать. Сейчас приблизительно:
- аналитик: пускай думает служба тестирования
- программер: я пишу код, пусть его тестируют аналитики и служба тестирования
- служба тестирования: нафигачили тут, как это тестировать??? ну ладно, главное чтобы не падало...
- PM: о есть баги, ну с кем не бывает, мы выпустим N фиксов
- саппорт: OMG, новая версия....
Может быть у меня несколько наивные фантазии на тему "собрались аналитик, программер и тестировщик и договорились как фичу новую делать, чтобы качественно было"...
Тем не менее, с пунктом 1 я решил бороться методом проведения семинаров для тестировщиков, на которых я рассказываю об архитектуре наших решений, дизайне модулей, технических реализациях и возможных способах их тестирования. И о том как им будет хорошо, когда они будут настоящими QA. Уж не знаю что получится, первый состоится через пару недель.
На пункт два я стараюсь не обращать внимания, но ведь всегда приятно иметь единомышленников.
С пунктом три даже не знаю с чего начать, слишком много заинтересованных лиц.
Может у вас есть предложения как побороться с этими проблемами? И стоит ли вообще бороться, может лучше найти контору где это востребовано? :)
Спасибо.
Да, безусловно позитивные изменения происходят, Алене и мне удается проталкивать свои идеи и решения. Учитывая что у нас через полгода первый релиз нового продукта и его надо будет тестировать а тестировщики и так "зашиваются", начальство осознает что надо что-то менять.
ОтветитьУдалитьПро начальное воздействие от начальства, оно конечно есть, время от времени на планерках звучит "вот надо бы все таки начать писать тесты", но все заканчивается холиваром на тему, что тестировать и как тестировать: какие типы тестов выбрать, какой функционал тестировать, кто должен формировать тестовое окружение и примеры, сколько должно быть покрытие + обязательно находится человек, который найдет сценарий который нельзя протестировать и по его логике это значит что тестировать не надо вовсе... и все одобрительно кивают. Занавес.
По поводу семинаров для программеров, это идея конечно витает, но есть сложности. Одно дело "учить" тестировщиков, в основном девушки и парни, милые юные создания )), другое дело убеждать умудренных опытом программистов, которые в большинстве старше по возрасту, положению и технически более подкованы, что они все эти года работали не правильно. Это серьезный челендж, не уверен что готов к нему :)
Еще раз спасибо, книги очень кстати.
P.S. C#
А то я думаю, почему не было статьи на эту тему.... :)
ОтветитьУдалитьА тебе интересно? :) Я сомневался писать или нет. В инете полно обзоров уже было.
ОтветитьУдалитьХоливар происходит от незнания. Вообще до боли знакомая тема: никто не пишет тесты, но все знают как это делать "правильно"... Проходили :(
ОтветитьУдалитьНасчёт "бородатых" всезнающих программистов - могу только посочувствовать. Тоже больной вопрос, даже для меня :)
Значит остается заниматься самообразованием, пробовать на практике и стараться показывать все начальникам. Я думаю при таком подходе есть шанс: нудный дятел может задолбать небольшого слона :)
Ну и если в этоге не получится - хуже от этих знаний и умений точно не будет.
Ну я в интернете только тебя да Эдуарда читаю :) Так что пиши, если не лениво. Будем читать... тем более начальство новые задачи ставит... надо начинать разбираться в этой области :)
ОтветитьУдалить