Долой отмазки в тестировании

Запись выступления Натальи Руколь на семинаре Санкт-Петербургского сообщества тестировщиков.

Читать дальше

Запись выступления Натальи Руколь на семинаре Санкт-Петербургского сообщества.

Читать дальше

...Хотелось бы сказать спасибо, что поставили ссылку на наш сайт, а не скопировали...

...Хотелось бы сказать спасибо, что поставили ссылку на наш сайт, а не скопировали...

Благодарность принята, хотя я обычно решаю такие вопросы лично, тем более что размещение данного поста согласовано и с Ромой и с Наташей.

О-ё-ёй.
Спрашивается - зачем нужны эти ISO, CMMI.... Зачем мы изучам и сертифицируемся по ISTQB и т.п.
Все эти стандарты - они ведь не только ОБЯЗУЮТ нас чему-то, но и ЗАЩИЩАЮТ нас от подобных "беспределов".
Вот уж не думал, что кто-то требования международных стандартов назовёт "отмазками".

У меня лично хватило нервов прослушать только первую "Проблему" (хотя слайды просмотрел все). В реале я бы покинул семинар через 12 минут.

Но давайте посмотрим на примере первой проблемы - к чему приведут рекомендуемые решения.
Для начала давайте определимся с компанией и продуктом, в которой мы - тестировщики.
1. Концерн по производству колёс с главной конторой в РФ, которому потребовалась программа для налоговых платежей дочерней фирмы в Кот д'Ивуар. Мы - тестировщики в IT-Division (который и написал эту программу для внутреннего потребления) и ничего не знаем, ни про налоги, ни про законы этой страны, хотя прекрасно разбираемся во всех технологических процессах производства колёс.
2. Фирма Софта, получившая заказ от сторонней компании Локхид на софт-модуль управления прицельным бомбометанием для бомбардировщика ОКБ (очень крутой бомбардировщик). Мы - тестировщики в софт-компании и в армии служили в стройбате.
3. Фирма Софта, создавшая свою операционную систему "Форточки" для персональных компьютеров. Мы - тестировщики в этой компании, прекрасно знающие виндоуз от версии 2.0, Никс-системы, железо от VAX до карточки CGA.

Итак - 1.
Имеем готовую систему с интерфейсом на русском языке (для облегчения задачи), напичканную юридическими терминами и непонятными коэффициентами.
Предлагается: исследовать без требований, написать их самостоятельно и т.п.
Извините, но я вообще не понимаю бизнес-процессов, поэтому, что такое поле "тут был страшный термин" не знаю. Идём к аналитику (постановщику). Он нам начинает рассказывать про налоговую систему в КД. После этого мы садимся и сами пишем "требования". После этого, мы идём к аналитику и выясняем спорные моменты. Оказывается, что мы всё поняли не так, и цикл обучения повторяется. Через много месяцев отдел тестирования (или один из тестировщиков) приобрёл огромные знания по налоговому законодательству КД и написал требования.
Результат: К сожалению, дочерняя компания не смогла оплатить налоги в срок, и её в полном составе посадили в тюрьму.
Вопрос к Наталье: Вы действительно считаете, что обучить тестировщика знаниям аналитика, чтобы он затем написал требования - это нормальный подход?

Далее - 2
Аналогично - создаём своего аналитика, пишем требования и тестируем соответствие системы им же. И вот оказывается, что заказчик Локхид, РАССКАЗЫВАЯ свои требования аналитику, имел в виду совсем другое. В лучшем случае, в результате нашего тестирования окажется, что наша система соответствует НАШИМ ЖЕ требованиям. Но совершенно не соответствует требованиям заказчика.
Результат:Фирам Локхид отказалась платить за 4 года работы нашей компании, выпустившей никому не нужную фигню, и наша фирма, обременённая банковскими ссудами, "вылетает в трубу".
Вопрос к Наталье:Простите, пожалуйста, но какое отношение требования, написанные Вами имеют отношение к требованиям заказчика?

Наконец - 3
Всё замечательно! Наша фирма сама решает какой функционал заложить в системе, как она должна работать и никто нам не указ. Как указала в лекции Наталья, мы хотим побыстрее выйти на рынок со своей ОС, опередив Виндоуз 2012 (Путин Эдишн).
Мы, не имеем никаких оформленных требований, не имеем даже списка игрушек, поставляемых вместе с ОС (не говоря уже про другие Тулы), сами быстренько пишем для себя же требования, и коробка с нашей замечательной ОС выходит на рынок.
Довольный покупатель (кстати,племянник работника администрации президента РФ), купив красивую коробку, достаёт из неё флэшку с инсталяцией ОС и тупо смотрит на неё (да-да, мы решили отказаться от всяких инсталляционных СиДи и поставляем продукт на ДискОнКи). Следующим шагом, покупатель пытается найти книжечку или, хотя бы какой-то файл с инструкцией, где было бы написано - что со всей этой "фигнёй" надо делать - как установить, как настроить, как запускать приложения, какие функции и тулы имеются и т.п.
А её (инструкции) - нет. Она ведь является вполне нормальным документом, описывающим функционал, а мы договорились, что такого документа у нас нет.
Результат:Рекламации, возврат товара, "потеря лица" компанией и т.д. = полный проигрыш в конкурентной борьбе за рынок.
Вопрос к Наталье:Не собираетесь ли Вы, в качестве хелпов и инструкций, снабжать покупателя теми "требованиями", которые Вы сами написали для своего тестирования?

=========

Ух... Устал.
Извините, Наталья, но уж очень Вы меня разозлили своими рекомендациями на семинаре.

Александр, вы главное не нервничайте :-) А что вы предлагаете в приведённой ситуации?

Требований нет, ситуация, как описана вами... Вы будете требовать требования и плевать в потолок до того славного дня, пока дочернюю компанию в тюрьму не посадят?

Александр --
Прелесть, а не примеры!
Вот мне это близко:

"Фирма Софта, получившая заказ от сторонней компании Локхид на софт-модуль управления прицельным бомбометанием для бомбардировщика ОКБ (очень крутой бомбардировщик). Мы - тестировщики в софт-компании и в армии служили в стройбате."

Самое главное --- чтоб НА ИСПЫТАНИЯ не вышли после одобрямся тестировщиков!!!!
А то КААААК шарахнут....

Дело в том, что Вы взяли КРИТИЧНЫЙ софт.
Все . Этим все сказано -- от винта с затеями свой аналитик пишет требования.

Полагаю -- аналогично с налогаи в Кот д'Ивуар, я так думаю. А именно -- ничего путнего не выйдет.
Вы просто возьмите примеры какие-нибудь...этакие попонятнее. Ну чтоб сразу ясно среднему человеку было - что ПО делать-то должно.
Ну... запись в поликлинику к врачам, например. ОК?

ПС.
Наталия весело и увлекательно рассказывает. И с аудиторией у нее прекрасный контакт. Так что зря не слушали.

Самое главное --- чтоб НА ИСПЫТАНИЯ не вышли после одобрямся тестировщиков!!!!
А то КААААК шарахнут....

Произошло испытание боеголовки от 20-ти до 100 килотонн.
- Как это от 20 до 100?
- Ну... думали, что 20, а она кааааак...

Дело в том, что Вы взяли КРИТИЧНЫЙ софт.
Все . Этим все сказано -- от винта с затеями свой аналитик пишет требования.

А разве Наталья делала оговорки про какой софт она рассказывает?
Даже некритичный софт, например, "Руководство по приготовлению вкусной и пздоровой пищи", протестированный по таким требованиям, будет содержать ошибки, которые чреваты, например, повышенной окупаемостью унитаза.

Наталия весело и увлекательно рассказывает. И с аудиторией у нее прекрасный контакт. Так что зря не слушали.

Ни в коем случае не про Наталью будет сказано, но самый лучший "контакт с аудиторией" я встречал в Тайланде на секс-шоу: человек 200 дышали в одном, заданном на сцене, ритме.
А уж какой "контакт" у Чумака был!!!
Проблема в том, что варианты решения, предлагаемые Натальей, скажу прямо - иногда вредны.

Александр, вы главное не нервничайте :-) А что вы предлагаете в приведённой ситуации?

Не нервничать у меня получится, если я буду несерьёзно относиться к материалу, а оценивать юмор и "экстерьер" Натальи (как предлагает уважаемая Фрося )

Что предлагаю я? Напишу "на коленке", без долгих раздумий.
1. Руководитель тестировщиков ОБЯЗАН следить - какие проекты даже не в процессе разработки, но в процессе планирования разработки находятся в его компании. И контролировать процесс, включая документацию.
По словам же Натальи, получается, что софт УЖЕ НАПИСАН, а мы, тестировщики, только проснулись.

Например, я, занимающийся надзором за тестированием у поставщиков ПО в наш банк, подключаюсь на этапе Request For Proposal.

2. Наводящий вопрос: программисты писали код - тоже "без требований"?
Тестирование можно (кривовато) проводить по RFD и пр. документам программистов.

3. Если программисты и тестировщики все умерли во время цунами, их документы сгорели и фирма набрала новых тестировщиков, то к тестированию MUST подключать ПОЛЬЗОВАТЕЛЯ-ЗАКАЗЧИКА, который будет сидеть рядом с профессиональным тестировщиком и они ВМЕСТЕ будут писать сценарии.

ЗЫ. Я вообще, честно говоря, не понимаю - как "интеграторы" сумеют подготовить среду для проведения тестов, если нет тех. описания системы.

Александр, мне почему-то кажется, что вы спорите ради спора. А смысл?

1) Если у нас высококритичный софт, то ситуации с отсутствием требований маловероятны.
2) Никто не говорит, что требования надо самим написать, закрывшись в тёмной комнате, и никого к ним не подпускать, смело заводя баги. Требования есть всегда, без них не был бы написан софт. Но они не всегда задокументированы, и не всегда одинаково понятны участникам процесса. Можно в таких ситуациях жаловаться на жизнь, а можно начать документирование самим, согласовывая требования со всеми участниками процесса, таким образом стимулируя последующее документирование требований на более ранних этапах.
3) Тестирование по RFD -- опасное решение. Согласованные с аналитиком требования гарантированно принесут больше пользы.
4) Вы говорите про необходимость подключения заказчика. Да, контакт с пользователем необходим, с этим я тоже не поспорю, вроде даже об этом отдельный слайдик был.

Вы спорите, как мне кажется, со следующим: "не давать аналитикам писать требованиям, не контактировать с заказчиками, писать самим полную ерунду, даже есть требования, и ставить компанию под неоправданные риски". С этим я тоже готова поспорить, с каждым из перечисленных пунктов! Только ничего из этого, как это ни странно, на семинаре не было - потому и не понятно, с чем вы спорите :)

Более того, никто не спорит, что требования должны писать аналитики. Супер! Но если их нет? Ну вот нет, и точка. Отдел тестирования создали месяц назад, хотя релиз скоро. Аналитики лоботрясы, лично с разработчиками всё обсуждают. Полномочий "надзора" у тестировщиков нет. Бывают такие случаи, и это данность. Можно сказать "непорядок!", почесать репу и свалить все проблемы на аналитиков. А можно им помочь, без надзора и избыточной самостоятельности, а выяснив спорные моменты, задокументировав требования и согласовав их с аналитиками и заказчиками.

Александр, мне почему-то кажется, что вы спорите ради спора. А смысл?

Зря Вы это сказали. Я ведь - зеркало в общении.
Мне, почему-то, кажется, что ваш семинар - развод лохов. Какой в нём смысл, кроме Вашего заработка?

1) Если у нас высококритичный софт, то ситуации с отсутствием требований маловероятны.

А дело не в критичности софта. А в знании тестировщиками тематики продукта. Вот вам некритичная подпрограмма (функция), ну скажем... вычисляющая свёрнутый тензор пространственно-временной кривизны в заданной точке пространства. Функция нужна для расчётов в космологических исследованиях.
Аналитик - доктор физ-мат наук, не написавший постановку. Программисты - умерли. Давайте проведём ролевую игру. Я попробую быть таким аналитиком (в юности мечтал защитить диссертацию).Вы - тестировщик.
Вперёд.

Требования есть всегда, без них не был бы написан софт. Но они не всегда задокументированы, и не всегда одинаково понятны участникам процесса.

Не совсем ясно "есть, но не задокументированы".
Если требования есть, вот ими и следует руководствоваться в тестировании. А не изобретать испорченный телефон и по нему тестировать.

Тестирование по RFD -- опасное решение. Согласованные с аналитиком требования гарантированно принесут больше пользы.

RFD, написанные не аналитиком и с ним несогласованные - не RFD, а - "вольное сочинение на тему".

Вы говорите про необходимость подключения заказчика. Да, контакт с пользователем необходим, с этим я тоже не поспорю, вроде даже об этом отдельный слайдик был.

Необходимость подключения заказчика к тестированию - основна. Вы с ней не спорите. Вы просто про неё не сказали ни слова при решении первой проблеммы.

потому и не понятно, с чем вы спорите

Вы предлагаете, в случая "неадекватности" аналитиков стать аналитиком самому. Это путь - крайне вредный.
Аналогично, предлагаю Вам ещё несколько аналогичных решений для проблемм (для будущих семинаров):
№2 "Разработчики срывают сроки" - самим написать часть кода.
№3 "Руководство не прислушивается" - заняться интригами и самим стать частью руководства.
№4 "Нехватка ресурсов" - скинуться отделом тестирования на эти ресурсы и приобрести их.
№ No number - "Среда (сервера, рабочие станции, доступ к и-нету) не стабильна" - самим стать техниками PC, системщиками и решать их задачи.

Александр, мне почему-то кажется, что вы спорите ради спора. А смысл?

Зря Вы это сказали. Я ведь - зеркало в общении.
Мне, почему-то, кажется, что ваш семинар - развод лохов. Какой в нём смысл, кроме Вашего заработка?

Семинар был бесплатный, поэтому вы зря это сказали :-) Ведь я - тоже зеркало ;)

А дело не в критичности софта. А в знании тестировщиками тематики продукта. Вот вам некритичная подпрограмма (функция), ну скажем... вычисляющая свёрнутый тензор пространственно-временной кривизны в заданной точке пространства. Функция нужна для расчётов в космологических исследованиях.
Аналитик - доктор физ-мат наук, не написавший постановку. Программисты - умерли. Давайте проведём ролевую игру. Я попробую быть таким аналитиком (в юности мечтал защитить диссертацию).Вы - тестировщик.
Вперёд.

Моё решение было озвучено: обсудить, узнать всё что возможно и задокументировать своё понимание. После чего - согласовать это понимание, если оно получит approve аналатика, признать его требованием. А теперь - повторю уже не первый раз свой вопрос. А что вы предлагаете делать? Не задокументировав свои мысли и не согласовав их в таком формате, вы гарантированно будете тестировать неправильно. Итак: ЧТО ДЕЛАТЬ?

Вы говорите про необходимость подключения заказчика. Да, контакт с пользователем необходим, с этим я тоже не поспорю, вроде даже об этом отдельный слайдик был.

Необходимость подключения заказчика к тестированию - основна. Вы с ней не спорите. Вы просто про неё не сказали ни слова при решении первой проблеммы.

Давайте не валить всё в одну кучу? Для этого и в презентации слайдов больше одного, чтобы разбирать вопросы по очереди и не сваливать в одну кучу разные темы.

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

Предлагайте свои решения, если они лучше моих - то это замечательно, мне тоже есть чему поучиться, и эта дискуссия приобретёт смысл.

Семинар был бесплатный, поэтому вы зря это сказали :-) Ведь я - тоже зеркало ;)

Т.е., даже этот смысл пропадает. И что же тогда остаётся? :-)

Моё решение было озвучено: обсудить, узнать всё что возможно и задокументировать своё понимание.

Помните из курса ISTQB что является Test Oracle?
О каком понимании в качестве Оракула может идти речь, если вы не знаете бизнес-процессов?
Или Вы настаиваете на том, что сможете получить необходимые знания посредством нескольких "лекций"?

А теперь - повторю уже не первый раз свой вопрос. А что вы предлагаете делать? Не задокументировав свои мысли и не согласовав их в таком формате, вы гарантированно будете тестировать неправильно. Итак: ЧТО ДЕЛАТЬ?

Вы зашли в цикл.:-) Вообще-то, я уже ответил на этот вопрос в своём сообщении 20.05.
В первом пункте ответил на вопрос - "Кто виноват": я, как ответственный за тестирование в компании.
Во втором и в третьем - на вопрос "Что делать?": использовать RFD (и подобные) и вовлечь в процесс тестирования пользователя. Вот это - легитимные Оракулы.

Давайте не валить всё в одну кучу? Для этого и в презентации слайдов больше одного, чтобы разбирать вопросы по очереди и не сваливать в одну кучу разные темы.

Простите, но проблемме #1 у Вас посвящено 2 слайда. И во втором - перечень решений.Чётко. Конкретно. Но ложно. За первые два Property - спасибо. Просмотрите его сами, пожалуйста, ещё раз (На видео на 12-й минуте Вы уже переходите к следующей проблеме).

Это очень выгодная стратегия: вы можете критиковать, но ничего не предлагаете. Увольте, это бессмысленное времяпрепровождение, никому не приносящее пользу.
Предлагайте свои решения, если они лучше моих - то это замечательно, мне тоже есть чему поучиться, и эта дискуссия приобретёт смысл.

Это не просто стратегия. Это, извините, моя специальность. Называется: QC. Как часть QA.
Вы сейчас, извините, напоминаете обидчивого программиста, получившего кучу багов и требующего от тестировщика пути их исправления.
А учить - увольте. Я знаю свои слабые стороны и учить отказываюсь. Вот учиться - рад. Ради этого и стал смотреть Ваш семинар.Результат испугал.

Александр, я поняла вашу точку зрения и ни на грамм с ней не согласилась, тем не менее, вы можете продолжать думать, как хотите. А я пока что вполне успешно использую свой подход и с описанными вами теоретическими выкладками на практике не встречаюсь. А вот проблемы от ковыряний в носу и тыкания пальцем в аналитиков, которые не предоставили инфу, наблюдаю во множестве компаний.
У меня нет цели кого-то переубеждать: в чём резон? Как говорил Генри Форд, "вы можете считать, что что-то будет работать или не будет - в любом случае окажетесь правы". Если не допускаете возможность использования нового подхода, то он и не "пойдёт", схема "не пробовал, но против" работает безотказно.

А я пока что вполне успешно использую свой подход и с описанными вами теоретическими выкладками на практике не встречаюсь.

Странно слышать про то, что выкладки - мои.
Они, вообще-то - требования методологий. ISTQB и CMMI.
Но Вы, конечно, вольны создать свою методологию, противоречащую существующей, работать согласно этой технологии, рекламировать её на семинарах и писать статьи. Возможно, когда-нибудь она завоюет Мир.
Как говорил один человек, которого я считаю своим учителем: "Значит так оно и должно быть".

Как говорил Генри Форд...

Не у того авторитета Вы учитесь. Ой, не у того!

У меня нет цели кого-то переубеждать: в чём резон?

Резон? Убеждать и доказывать - единственный легитимный путь обучения/преподавания. Иначе вместо профессинального семинара получаем посиделки за пивом: "пацаны, а зацените прикол". Это, конечно, очень приятно и привлечёт большое количество участников.

ЗЫ. Спасибо за общение.

О чем спор-то?
Вроде начали о качестве семинара. Перешли к г-ну Форду.
1. Это - семинар. Заточенный на определенную аудиторию. Аудитория собирается и довольны.
Тут и обсуждать нечего. Слушатели голосуют кошельком.
2. У каждого свой опыт. В рамках этого опыта и оценивается/раскрывается проблема.
Есть ПО, работу которого можно оценить исходя из здравого смысла.
Пример - заказ и покупка кофточки пиджачка через инет. Тут любая барышня с Литлвана разъяснит - какие требования у нее к софту. И совершенно запросто и баги и требования на Литлване обсудит.

Есть ПО, которое требует специальных знаний. Примеры Александр привел.
Тут здравый смысл барышни литлвановской - от винта. Тут - знания, аналитика, работа с заказчиком. Тут без требований -- мимо. Сочинения тестировщика могут быть полезны, если тестировщик ДОКА и СПЕЦИАЛИСТ. Т.е. ну вот практически как аналитик может работать.

3. Тестироваться будет и то, и то ПО.
Где какие подходи сыграют? Ну тут и обсуждать нечего
(хихикает --- я систему налогообложения Кот-Д"ивуара могу месяцами изучать -- ни шиша путнего из моего тестирования при отсутствии требований не выйдет. И ничего смахивающего на реальные требования не напишу -- косяки одни будут!)

Фрося!
Я с вами полностью согласен (кроме "кошелька" - по настоянию Натальи).

И для тестирования продажи кофточек Вы с Натальей будете ВАЛИДНЫМИ ОРАКУЛАМИ (эээ... звучит несколько...в общем, ничего личного) - т.к. Вы и есть тот самый пользователь, про которого я и говорил.

И про аудиторию согласен.
Возможна она состоит - сплошь из специалистов CSA, CSBA и т.п. и одновременно профессионалов в области "предмета программы" (хотя в этом я глубоко сомневаюсь).

Но про это не сказано. А сказано: ОТМАЗКИ.

Дайте вмешаюсь что ли ненадолго..

Александр, а вот в этом случае Вы уверены, что сумеете убедить заказчика и посадить его рядом со своими людьми?

Если программисты и тестировщики все умерли во время цунами, их документы сгорели и фирма набрала новых тестировщиков, то к тестированию MUST подключать ПОЛЬЗОВАТЕЛЯ-ЗАКАЗЧИКА, который будет сидеть рядом с профессиональным тестировщиком и они ВМЕСТЕ будут писать сценарии.

Что он не посмотрит в ответ на такое предложение странным взглядом и не скажет, что мол все уже обсудили, ТЗ обговорено и что ты еще хочешь услышать?
Что пользователь и заказчик это один и тот же человек? Что заказчик захочет посылать своих пользователей к Вам, посидеть рядом?

Как можно узнать из курса увлекательнейшего предмета "Философия" (столь многими нелюбимого и считаемого пустой трепотней), любую теорию можно опровергнуть и нельзя подтвердить окончательно. Александр, большое спасибо за демонстрацию :) Я более чем уверен, что можно подобрать примеры, в которых практики, предлагаемые в CMMi, будут приносить больше убытков, чем пользы. Недаром авторы этой модели очень мудро говорят о рекомендациях, а не обязательных требованиях. Если уж зашла речь об ISTQB (это вообще организация, а не методология), то далеко не все поддерживают и принимают их сертификацию, насколько я знаю. Так что не того "авторитета" приводите в пример :)

А вообще, так яростно обрушившись на содержание семинара, Вы невольно сделали то, что называете недопустимым: начали критиковать (тестировать?) не ознакомившись с требованиями к продукту. Это ж надо было сказануть про заработок и развод лохов :) Так вот, тему задали мы: очень часто приходится видеть, как технические специалисты (тестировщики, программисты, тех. писатели) перекладывают ответственность с себя, говоря, что они ничего не могут сделать. И семинар был предназначен как раз для них, а не для начальников отделов и директоров. И им было рассказано, что можно сделать на их месте, месте рядового сотрудника, который не определяет политику и процессы компании, чтобы качество ПО стало лучше и обстановка в отделе или компании изменилась.

Ситуаций бывает очень много, очень забавно бывает видеть, когда люди проработавшие несколько лет в одной компании, доказывают другим людям, что те неправы и так не бывает, когда последние рассказывают случаи из своей практики. Очень здорово, что у Вас в компании все построено по методологиям (кстати, у CMMi уровень 5, наверное?), все специалисты сертифицированные эксперты (кстати, а тестировщики-автоматизаторы как же? или специалисты по тестированию безопасности? у ISTQB эти экзамены еще только готовятся), но так далеко не везде. И тестировщики люди достаточно умные, сами поймут, где можно применять рассказанное, а где нет. А если не поймут, так жизнь научит, делающие ошибаются, да, но и учатся на ошибках.

P.S. Отдельно я хочу поблагодарить Наталью за то, что она приехала и провела семинар для нас, несмотря на то, что планы изменились, и платный тренинг в тот день был отменен. Да-да, мы явно по-моему нигде об этом не говорили, но Наташа приехала в Питер на два дня раньше, чем ей было нужно, только для того, чтобы не подвести нас. Спасибо!

2 Vasiliy
Я уверен в том, что я смогу оценить риски и донести до своего начальства и до заказчика результаты и свою правоту на их языке.
И Вы сможете (если сейчас не умеете, то Вас можно научить).

2 retverd
Я тоже исходил из того, что семинар предназначен для тестировщиков: "Запись выступления Натальи Руколь на семинаре Санкт-Петербургского сообщества тестировщиков." И я, профессиональный тестировщик, являюсь легитимным оракулом для тестирования результатов.
Именно поэтому и был поражён рекомендацией мне - фактически написать новые требования самому (с помощью аналитика) и по ним проводить тестирование.

Вот давайте рассмотрим "продвижение" требований:
1. У пользователя появились требования в процессе его деятельности. Имеем источик требований.
2. Пользователь вместе с аналитиком детализируют\уточняют эти требования. Имеем "наследование" от источика.
3. Аналитик конкретизирует требования и переводит их на технический язык - RFD, структуру БД и т.п.
Имеем "наследование".
4. Программист реализует "наследованные" требования.
5. Тестировщик тестирует реализацию на соответствие (и на основании) "наследованным" требованиям.

В результате имеем неразрывную цепочку, где соблюдаются причинно-следственные связи и наследование.

Наталья предлагает решения варианта, когда пропали требования из п. 2 при уже готовом продукте. Она предлагает создать параллельную ветку пункту 2. В результате, появляются требования, выпадающие из цепочки "наследования" ("реализатор" их в глаза не видел наши требования).
На что тестировщик будет ссылаться при открытии багов, имеющих отношение к бизнес-процессам? На свой документ требований?

PS. Я занимался тестированием в 4-х компаниях. И сталкивался с разными ситуациями. Так, например, в фирме Comverse (http://www.comverse.com/) мне довелось участвовать в тестировании множества мелких программ и юнитов (макросов) при переходе компании на новую версию MS Office.
Естественно, программы и юниты были написаны за годы до моего тестирования и никаких документов не осталось. Так что не стоит ни ставить под сомнение мой опыт в подобных ситуациях, ни пытаться меня запугать страшными случаями из жизни.
PPS. CMMI - Подразделение, в котором я рабтаю сейчас сертивицировано на 3 lvl.
PPPS.ISTQB. Эти звери ввели, во многом, свои термины, свои пути решения, свои приоритеты и т.д. В результате, получилась именно новая методика. Во многом она имеет заимствования и ссылки на другие стандарты, во многом - нова. Совершенно согласен с тем, что многие её не принимают - мне она тоже во многом не нравится. И я вовсе не настаиваю на её безоговорочном применении.Проблемма в том, что Наталья предложила решения противоречащие и известным мне методологиям и здравому смыслу. Если это не так - буду рад, если Вы (или кто-то другой) меня поправит. С радостью воспользуюсь.
PPPPS. Считается, что умные люди учатся на чужих ошибках (посещая, например, семинары). На своих ошибках учатся ... другие.

1. Ясный и понятный анонс семинара решит массу проблем -- и для какой аудитории, и о чем конкретно речь будет.
2. Если данный семинар про как выстроить линию поведения при отсутствии того-сего (Требований, бумаги и карандашей) чтобы "обстановка в отделе или компании изменилась", это одно. Это про психологию.
Тут про Требования - просто пример (можно было про отсутствие карандашей!), и разбирать технические решения ни на семинаре, ни сейчас - смыслу нет.
Если данный семинар про решение технических проблем, это другое.

Тогда -- однозначно в семинаре должно было быть озвучено:
- при тестировании ПО такого-то (кратенько - но четко!) я сделал(а) так-то. Получил то-то.

Собственно, все вопросы и сомнения по технической проблеме Александр очень хорошо раскрывает. Ест о чем поговорить.

3. Проведение семинаров и тренингов - это бизнес.
Проведение бесплатного семинара - это рекламная акция.
Нормальная, общепринятая по продвижению СВОЕГО продукта.

4. Ну и...(мечтательно)
Может все-таки когда нибудь речь будет поставлена профессионально?
Все-таки -- публичное выступление.
Причем - не разовое публичное выступление, а постоянный бизнес, основанный на ПУБЛИЧНЫХ ВЫСТУПЛЕНИЯХ.
И хочется слышать ЗВУЧАЩИЙ русский язык -- без эканья/мммеканья..оканья ... пауз.. с поставленным дыханием.


Вообще -- Наталия мне глубоко симпатична -- позитивом, энергией и креативностью.

Наталья предлагает решения варианта, когда пропали требования из п. 2 при уже готовом продукте. Она предлагает создать параллельную ветку пункту 2. В результате, появляются требования, выпадающие из цепочки "наследования" ("реализатор" их в глаза не видел наши требования).
На что тестировщик будет ссылаться при открытии багов, имеющих отношение к бизнес-процессам? На свой документ требований?

Александр, так Вы всё же расскажите, что Вы предложили бы делать в ситуации, "\когда пропали требования из п. 2 при уже готовом продукте".
Все понимают, что это не самая приятная ситуация. Но вопрос заключается в том -- что делать тому, кто в неё попал?