Не далее, как месяц назад коллеги прошли курс Наташи Руколь Школа Тест-Аналитика , о чем рассказали нам.
Судя по их отзывам, полезность - высокая. Планирую пройти сам.
Мое мнение на этот счет - школа укладывается в парадигму "надо думать заранее", так как требования как правило идут до разработки; а также в парадигму "кто если не мы", так как почти всей описанной у Наташи работой, на мой взгляд, должны заниматься аналитики.
И по стечению обстоятельств получилость так, что в это же время Юля @yuzaks устроила у нас локальную движуху под названием "Ревью аналитики".
Она была вообще про аналитиков и для аналитиков (и это правильно), но позвали одну команду тестеров в качестве то ли приглашенных звезд, то ли подмостовых троллей, то ли источников альтернативного мнения.
В чем суть, смысл и процесс?
Делаем раз - собираем штук 16 аналитиков и 3 тестировщиков. делим на команды. Выбираем аналитиков-жертв, просим несколько годных постановок (ТЗ, требований).
Делаем два - читаем книгу 15 главу книги Карла И. Вигерса Разработка требований к программному обеспечению. В 15 главе как раз - о тестировании требований.
Делаем три - адаптируем к нашим реалиям список вопросов из книги и раздаем командам. Вопросы - по блокам, ясность, проверяемость, трассируемость, оформление, качество внесения изменений и так далее.
Четыре - даем командам полторы недели времени, на почитать, посовещаться, договориться о ответах на вопросы и выслать все это организаторам.
И финальное шоу - собираем всех вместе, кидаемся дискутируем, обобщаем, делимся опытом, обсуждаем, планируем улучшения.
Мои ощущения от процесса:
С аналитиками, страшно, у всех уж очень умные лица.
Советов надавали уймищу огромную, и если их все выполнить, качество постановки возрастет неимоверно. Но время создания постановки тоже, неясен приоритет советов.
Мне кажется, что те, кто проводил ревью, немного забыли, что такие постановки читают все же люди в теме. И у них большой контекст. И не обязательно надо, чтоб он был в постановке.
Мне кажется, те, кто писал постановку забыли, что она нужна для того, чтоб ее читали. И читают ее с определенной целью. И цели - "перенести в вики информацию, которую я знаю о бизнесе" и "реализовать приложение для бизнес-процесса" предполагают разную структуру.
Во время обсуждения все же выяснилось, что и новички часто читают такие постановки, так что и контекст не помешал бы.
По итогам решили, что полезность - неимоверная, но с актуальностью будут проблемы. Все шоу длилось 2 недели, а особо ценный эффект оно приобретет, если будет применяться к постановкам в те редкие моменты, когда постановка уже написана, а код еще нет.
Обратно же, если сделать шоу регулярным и не столь малочисленны, то хуже тоже не будет.
Посмотрим, как дело пойдет дальше.
Кстати, понравилась цитата из книги:
Судя по их отзывам, полезность - высокая. Планирую пройти сам.
Мое мнение на этот счет - школа укладывается в парадигму "надо думать заранее", так как требования как правило идут до разработки; а также в парадигму "кто если не мы", так как почти всей описанной у Наташи работой, на мой взгляд, должны заниматься аналитики.
И по стечению обстоятельств получилость так, что в это же время Юля @yuzaks устроила у нас локальную движуху под названием "Ревью аналитики".
Она была вообще про аналитиков и для аналитиков (и это правильно), но позвали одну команду тестеров в качестве то ли приглашенных звезд, то ли подмостовых троллей, то ли источников альтернативного мнения.
В чем суть, смысл и процесс?
Делаем раз - собираем штук 16 аналитиков и 3 тестировщиков. делим на команды. Выбираем аналитиков-жертв, просим несколько годных постановок (ТЗ, требований).
Делаем два - читаем книгу 15 главу книги Карла И. Вигерса Разработка требований к программному обеспечению. В 15 главе как раз - о тестировании требований.
Делаем три - адаптируем к нашим реалиям список вопросов из книги и раздаем командам. Вопросы - по блокам, ясность, проверяемость, трассируемость, оформление, качество внесения изменений и так далее.
Четыре - даем командам полторы недели времени, на почитать, посовещаться, договориться о ответах на вопросы и выслать все это организаторам.
И финальное шоу - собираем всех вместе, кидаемся дискутируем, обобщаем, делимся опытом, обсуждаем, планируем улучшения.
Мои ощущения от процесса:
С аналитиками, страшно, у всех уж очень умные лица.
Советов надавали уймищу огромную, и если их все выполнить, качество постановки возрастет неимоверно. Но время создания постановки тоже, неясен приоритет советов.
Мне кажется, что те, кто проводил ревью, немного забыли, что такие постановки читают все же люди в теме. И у них большой контекст. И не обязательно надо, чтоб он был в постановке.
Мне кажется, те, кто писал постановку забыли, что она нужна для того, чтоб ее читали. И читают ее с определенной целью. И цели - "перенести в вики информацию, которую я знаю о бизнесе" и "реализовать приложение для бизнес-процесса" предполагают разную структуру.
Во время обсуждения все же выяснилось, что и новички часто читают такие постановки, так что и контекст не помешал бы.
По итогам решили, что полезность - неимоверная, но с актуальностью будут проблемы. Все шоу длилось 2 недели, а особо ценный эффект оно приобретет, если будет применяться к постановкам в те редкие моменты, когда постановка уже написана, а код еще нет.
Обратно же, если сделать шоу регулярным и не столь малочисленны, то хуже тоже не будет.
Посмотрим, как дело пойдет дальше.
Кстати, понравилась цитата из книги:
Ловушка
Остерегайтесь тестировщиков, которые утверждают, что не могут приступить к работе, пока требования еще формируются, и тех, которые утверждают, что для тестирования ПО им не нужны требования. Тестирование и требования связаны между собой синергетическими отношениями, поскольку они представляют дополняющие взгляды на систему.
Комментариев нет:
Отправить комментарий