Сэнсэй Баранцев в стенах глобаллоджиевского G-Club развертывает идеи о требованиях, которые всегда существуют.
Да требования же всегда есть!
Говорит, что не понимает тестировщиков, которые говорят, что «требований нет». Требования есть всегда, иначе программисты не смогли бы написать софт. Если сам заказчик не знает, что и как должно быть, но программисты уже сделали, следовательно, требования находятся в сознании у программистов. Надо идти к ним и выяснять.
«Требования существуют всегда. Точка».
Если надо давить авторитетом, то мэйдзин Александр Александров говорит то же самое уже который год.
А вот когда «нет четких требований» — это понятно. Это нормально. Требования не сформулированы, это нормально.
Почему тестировщики требуют требования?
От страха, йоптыть 🙂
Страшно принимать технические решения, если нет их обоснования, которое одобрено кем-то из «старших».
Страшно ошибиться.
Страшно, в общем.
Лечить этот страх следует посредством ног. Босоногие гуру аюр-веды всегда советовали ходить к программистам и обсуждать причины и решения, которые были приняты.
Ходить вообще надо часто. Требования, которые фиксируются на бумагах — это соглашения, которые следует зафиксировать во избежание разночтений и разнопониманий, не более. Все остальное находится в сознании.
В сознаниях, если угодно.
Все остальное тоже оговаривается, но не фиксируется в документах. Если не участвуешь в тусовке, то и требования, и основания для изменений, и вообще причины принятия определенных решений проходят мимо твоего сознания.
Эффективность тестирования зависит напрямую от взаимосвязей в группе разработки, а не от качественно подготовленной документации.
То есть, всеми своими левыми руками я ратую за то, что надо создавать отдельные боевые группы «программист + тестировщик». Личностные отношения в таких группах сделают больше, чем аналитическая подготовка.
Аналитическая подготовка — это всеобщий план артиллерийского предварительного обстрела.
После обстрела все равно остаются живые неприятели, и все равно нужно бегать в штыковую атаку. В штыковой атаке все происходит ситуационно, не всегда согласовано с большим планом сражения. Тут как раз срабатывает уровень подготовки к бою каждого солдата в отдельности, и «Конвенция о женевских военнопленных» тут может не действовать…
Теперь вот что. Меня иногда искренне спрашивают, мол, чего это ты так говоришь, что Баранцев крут — «чего там особенного?»
Ну, особенного там то, что он умеет основательно раскладывать события, факты и суждения по логическим полочкам, ибо — математика, и систематизировать их.
Я так не умею. Я мыслю скорее ассоциативно, нежели строго логически.
Как правило, строгие аналитичность и логичность не дружат с ассоциативностью, бо это как раз не епархия строгости. Но в моем сознании все эти части очень хорошо дружат друг с другом.
В каком-то смысле это делает меня очень сильным в определенных отношениях, хотя и прогибает в других.
Но на основе его систематизации у меня получается очень хорошо систематизировать собственные суждения. Иногда мы пересекаемся в выводах, но чаще всего его выводы меня опережают и удивляют, бо я до этого не додумался или не додумал, или вообще ощущаю ситуацию в иной плоскости.
В записи Сэнсэй говорит о том, что невозможно гарантировать полное тестирование требований потому, что невозможно учесть все условия, в которых работает софт.
Затем объясняет, как эту проблему следует грамотно разруливать. Ибо невозможность изначально учесть все условия нас ничуть не расстраивает — все выясняется по ходу дела и дополняется на ходу.
PS Волновать работников Глобала лейблом SysIQ на рукаве моей футболки не пришлось — суббота, офис пустой.
PPS Старый G-Club был уютнее. Ощущался как более масштабный, что ли…
Согласна со всем написанным, кроме одной опасной штуки: «Если сам заказчик не знает, что и как должно быть, но программисты уже сделали, следовательно, требования находятся в сознании у программистов.»
Нееее!! Следовательно, в сознании у программистов есть ЧТО-ТО, но это ещё нельзя называть требованиями, потому чо не факт что оно кому-то требуется! И настоящий гуру найдёт-таки способ узнать у заказчика, правильно ли его поняли разработчики.
В презентациях Юлии Нечавой (http://testitquickly.com/tag/%D1%8E%D0%BB%D1%8F-%D0%BD%D0%B5%D1%87%D0%B0%D0%B5%D0%B2%D0%B0/) этот момент тоже хорошо раскрыт.
— работа тестировщика близка к работе аналитика
— с заказчиками _надо_ общаться и внутри команды _надо_ общаться (что тоже может делать тестировщик-аналитик)
Ну и, выяснение требований — не последний способ переговоров. В ходе уточнения, можно изложить свои варианты требований и последствия каждого из них. Решение, разумеется, за заказчиком, но уточнение зависимости времени разработки от требований и выбора их вариантов вносит больше взаимного понимания.
вскрыть мозг тому, кто знает — чуть ли не главная задача тестировщика.
даже если этот мозг находится черт -его-знает-где -надо найти и добыть информацию через черт-знает-кого посредством черт-его-знает-чего и черт-его-знает-как.
с маленькой оговоркой — если время потраченное на поиск окупит такие затраты.
в иных случаях интуит-тестирование,как я называю exploratory testing ( сэнсей А.Баранцев называет это тестирование методом свободного поиска, некоторые предпочитают называть это исследовательским тестированием) — рулит.
Нечаева говорила не совсем это, но смысл в принципе близок.
Алексей, а почему именно программист + тестровщик?
Может не только такая пара, но и аналитик + тестировщик, одни автор знает чего надо, передаст второму.
Или тогда уж тройку аналитик-прграммист-тестировщик?
Потому, что я никогда не работал в такой связке с аналитиками, а вот с программистами — постоянно.
Тестировщик зачастую роль аналитика выполняет. Знаете как это бывает в маленьких компаниях — не бывает отдельно аналитиков или отдельно программистов, все делают сразу по несколько дел.
в тройке аналитик-программист -тестировщик — как вы себе этот процесс представляете?
какие цели?
в парах — программист -тестировщик все понятно
и оправдывает себя в большинстве случаев.
Смотрите. Я не буду говорить про любые проекты, я лишь исхожу из своего текущего опыта и окружения. Опыт у меня несильно разнообразный: проект единственный. Мы действительно трудимся в связках программист — тестировщик. Более того порой это единственно возможный источник КАК ДОЛЖНО БЫТЬ. Это к вопросу об отсутствии документируемых требований. В результате носитель информации: программист и аналитик. Но программист за частую выдает желаемое за действительное и, если тестировщик полагается только на знания программиста, легко можно пропустить решение ошибочное.
Как Вы действуете в подобных ситуациях?
Почему вы делаете реплай ко всей записи, а не к определенным комментариям? 🙂
Действительно, есть такой риск, если посчитать, что я сознательно игнорирую аналитиков и предпочитаю им программистов как носителей знаний 🙂
Однако повторюсь, что аналитиков тут просто не рассматриваю по причине того, что они меня не окружают. Вот если бы аналитик был у меня в той же доступности, что и программист, я бы с ним общался не менее часто — никаких проблем пообщаться с аналитиком, если он ЕСТЬ.
Потому что там есть сообщение Рины, Ваше + Рины = делаю общий реплай :), т.е. реплай и к ней тоже
Понял.
Рина ошиблась.
Пусть реплаи будут тематическими 🙂
нененене
не надо нас реплаить)
это отдельные мнения)))
окончательно скажу, что может и есть смысл дергать и программиста и аналитика. и работать втроем.
у меня такой практики нет, потому что аналитиков на проекте вообще нет.
почему я свой комментарий и задала вопросом.))
Лады, отвечаю раздельно задним числом.
Аналитик — автор задачи. Он пособирал там требования, проникся духом заказчика. Бац, родил постановку. Постановку распилили на работы и запланировали исполнителю. исполнитель кодит-кодит. Закончил. Проверяющий будет тестировщик, он проверяет исполнение и принимает работу.Так видится МП, например. Пока у нас тестировщик неявный проверяющий (то бишь принимающий), он таки тестирует кучу всего. В ходе всего этого ему очень часто приходится общаться с программистом, но на стадии планирования, формирования тест дизайна, выработке критериев приемки — требуется аналитик. Как-то примерно так. Правда аналитики усиленно хотят от нас отбодаться, чтобы находится в своем чистом аналитическом астрале, чтобы ничего не мешало общаться с заказчиком …
По рукам
Рина, смотрите чуточку выше, на свой предыдущий пост :о)
вы меня запутали)
ну да не важно)
к статье Леши, и к самому тренингу Алексея — во чо нашла :
Кричал Кот Великану, мол, не верю,
Что примешь облик ты любого зверя!
Меня одним лишь только убедишь —
Немедля превратишься, если в мышь!
Развеять чтоб кошачие сомненья,
Стал мышкой Великан в одно мгновенье.
Но Кот поймать её, увы, не смог,
Поскольку та, взлетев под потолок,
Обгадила Кота какой-то кучей…
Как оказалось, мышь была летучей!
Мораль: Как говорится, в назиданье —
Корректней формулируйте заданья!
воооот)))
теперь все понятно)
спасибы за ответ)
Блестяще 🙂
+1 и расширение идеи.
Не обязательно программист точно знал, что он делал. («главное — скомпилировалось»)
Программист мог быть уверен, что он делает одно, а сделать другое. («о вреде комментариев»)
Не обязательно 3rd party components делают то, что думает архитектор (или они делают что-нибудь еще).
Черт, моя вера в святость и адекватность программистов шатается.
Уведомление: Radio QA: Выпуск 17: Хочу всё знать — 2. Крепкий орешек | QA — грамотно
Уведомление: Radio QA: Выпуск 17: Хочу всё знать — 2. Крепкий орешек — Можно Подумать