Сообщений в теме: 27

[kukolev]

Здравствуйте, уважаемые!

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

1. открыть Фрэйм
2. вызвать окно
3. нажать на кнопку в окне

Ошибка на шаге №3 - окно закрывается, т.к. курсор над Фрэймом

Собственно вопрос следующий - чей в данном случае промах - тестировщик, который не протестил окно, вызывая его поверх всех окон или разработчик окна, который даже и не знал о поведении Фрэйма?

ПО на платформе Win32

Рассудите, пожалуйста.

[Natalya Rukol]

Я уверена на 100% что в этой истории неправ тот, кто ищет виноватых. У вас командная работа, и вы вместе должны сделать клёвый софт. Чем больше внимания уделять поиску виноватых, тем меньше времени у вас останется на поиск решения "как больше не пропускать такие штуки".

[kukolev]

Уважаемая Natalya Rukol, у меня цель найти причину этого очевидного косяка в подходе, а не карать того или иного участника команды. Хочу понять - является ли очевидной необходимость подобной проверки или нет? Это недоработал тестировщик или недоработал программист? Или недоработал постановщик задач? В зависимости от ответов на эти вопросы я смогу повлиять на соответствующих участников команды и исключить подобные инциденты в будущем.

[kukolev]

... тем меньше времени у вас останется на поиск решения "как больше не пропускать такие штуки".

Я как раз и ищу это решение - за этим и пришел на форум.

[horhe]

Обидно, конечно, что такая ошибка пролезла, но для ответа на основной вопрос стоит поискать ответы на несколько дополнительных:
- сколько фреймов могут быть открытыми под окном?
- сколько ТИПОВ фреймов могут быть открытыми под вызваным окном? 5? 10? 20? 100?
- сколько фреймов могут быть открытыми под окном одновременно?
- степень взаимного влияния?
- чем этот самый проблемный фрейм уникален?
- кто об этом знал?
- каким временным ресурсом обладал тестировщик на проверку проблемной части функционала?
- какие проверки проводились? почему? почему нет?
- уровень компетенции сотрудника(-ов)?
- степень знакомства с проектом в целом?
- степень вовлечения в вопросы связанные с требованиями?

Должно подсказать в какую сторону думать. Согласен с Натальей, поиск и порицание "крайнего" конструктива не добавит.

[kukolev]

Обидно, конечно, что такая ошибка пролезла, но для ответа на основной вопрос стоит поискать ответы на несколько дополнительных:
- сколько фреймов могут быть открытыми под окном?
- сколько ТИПОВ фреймов могут быть открытыми под вызваным окном? 5? 10? 20? 100?
- сколько фреймов могут быть открытыми под окном одновременно?
- степень взаимного влияния?
- чем этот самый проблемный фрейм уникален?
- кто об этом знал?
- каким временным ресурсом обладал тестировщик на проверку проблемной части функционала?
- какие проверки проводились? почему? почему нет?
- уровень компетенции сотрудника(-ов)?
- степень знакомства с проектом в целом?
- степень вовлечения в вопросы связанные с требованиями?

Должно подсказать в какую сторону думать. Согласен с Натальей, поиск и порицание "крайнего" конструктива не добавит.

1. Порядка 70-ти фрэймов
2. Все те-же 70 типов
3. Одновременно - 1 фрэйм одного типа естественно
4. Степень взаимного влияния фрэймов друг на друга нулевая. На открытый фрэйм другие фрэймы в статичном состоянии не влияют
5. Такое поведение Фрэйма (перехват фокуса, что и приводило к ошибке) было известно некоторым разработчикам и описано в документации
6. Временной ресурс неограничен - для каждой новой функции мы готовы рассмотреть любой временной ресурс на тестирование, если это будет аргументировано
7. Проводилась проверка функционала на стартовом фрэйме, где все нормально. На проблемном фрэйме проверка не проводилась, т.к. тестировщик не считал это необходимым. В этом и состоит главный вопрос - принято ли у специалистов по тестированию понимать необходимость такой проверки и как следствие запрашивать ресурсы из п.6?
8. Опыт работы тестировщиков несколько лет. Есть опыт составления тестовой документации
9. Степень знакомства средняя - человек работает над проектом пол года. Опытный тестировщик - 1,5 года
10. Степень вовлечения низкая - делаем программный продукт для экологов организаций - бывает сложно поставить себя на место пользователя.

[pachkun]

5. Такое поведение Фрэйма (перехват фокуса, что и приводило к ошибке) было известно некоторым разработчикам и описано в документации

Скажите честно, документация ведь наверняка не подъемная для одного человека??
Мне кажется, вам надо не искать крайнего, а повысить степень информированности от некоторых до всех, включая тестировщиков.
Раз проблема известная, еще на этапе проектирования об этом надо было отдельно задуматься.

[horhe]

1. Порядка 70-ти фрэймов
2. Все те-же 70 типов
3. Одновременно - 1 фрэйм одного типа естественно
4. Степень взаимного влияния фрэймов друг на друга нулевая. На открытый фрэйм другие фрэймы в статичном состоянии не влияют
5. Такое поведение Фрэйма (перехват фокуса, что и приводило к ошибке) было известно некоторым разработчикам и описано в документации
6. Временной ресурс неограничен - для каждой новой функции мы готовы рассмотреть любой временной ресурс на тестирование, если это будет аргументировано
7. Проводилась проверка функционала на стартовом фрэйме, где все нормально. На проблемном фрэйме проверка не проводилась, т.к. тестировщик не считал это необходимым. В этом и состоит главный вопрос - принято ли у специалистов по тестированию понимать необходимость такой проверки и как следствие запрашивать ресурсы из п.6?
8. Опыт работы тестировщиков несколько лет. Есть опыт составления тестовой документации
9. Степень знакомства средняя - человек работает над проектом пол года. Опытный тестировщик - 1,5 года
10. Степень вовлечения низкая - делаем программный продукт для экологов организаций - бывает сложно поставить себя на место пользователя.

У нас тестировщики читают документацию (если она есть ), а разработчики не ленятся предупреждать о "подводных камнях".
Если у вас 70 уникальных фреймов, то вполне целесообразно было бы проверить все - уникальные всё-таки, и затраты времени тоже можно аргументировать. Еще важно разобраться тестировщик "не посчитал нужным" (значит должны быть какие-то аргументы в пользу подобного решения) или "не придал значения". И в том и в том случае с человеком нужно общаться выяснять, убеждать, учить, переучивать, тренировать... по контексту.

Не мое конечно дело, но зачем разработчик, зная о том, что некоторые фреймы перехватывают фокус и не то что не дают работать с нужным окном, а вообще могут его закрыть, реализовал возможность открывать это окно в принципе? Согласитесь по сути оно в этом случае, не только бесполезно, но и даже вредно...
Везде накосячили и при постановке задачи, и при анализе, и при реализации, и при проверке.

[kukolev]

5. Такое поведение Фрэйма (перехват фокуса, что и приводило к ошибке) было известно некоторым разработчикам и описано в документации

Скажите честно, документация ведь наверняка не подъемная для одного человека??
Мне кажется, вам надо не искать крайнего, а повысить степень информированности от некоторых до всех, включая тестировщиков.
Раз проблема известная, еще на этапе проектирования об этом надо было отдельно задуматься.

Да, неподъемная. Честное слово я не ищу крайнего, я пытаюсь разобраться:

1. Должен ли тестировщик это проверить?
2. Должны ли архитектор и разработчик учесть такую особенность при разработке?

Ответ на второй вопрос положительный - буду повышать осведомленность разработчиков о всей системе

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

[kukolev]

Не мое конечно дело, но зачем разработчик, зная о том, что некоторые фреймы перехватывают фокус и не то что не дают работать с нужным окном, а вообще могут его закрыть, реализовал возможность открывать это окно в принципе? Согласитесь по сути оно в этом случае, не только бесполезно, но и даже вредно...
Везде накосячили и при постановке задачи, и при анализе, и при реализации, и при проверке.

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

[pachkun]

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

Если он знает о такой особенности, конечно должен.
А если не знает, и тем более я так понимаю это не первый такой фрейм для него, то это на удачу (это мое мнение).

повышать осведомленность разработчиков о всей системе

А тестировщики так и останутся не у дел ?:)

P.S. Поймите в любом деле важна коммуникация, наличие уникальных знаний это плохо.

[horhe]

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

Нет, невозможно вы не требуете. И разработчик, и тестировщик, как только узнали о том, что в деле замешаны фреймы должны были подумать "Хм... будут фреймы. А какие они у нас там бывают? Какие нас сюрпризы ждут?" и полезть читать подъемные доки по интересующей части,а не неподъемную документацию по всему проекту. И осведомленность растет, и шанс допустить, а потом пропустить ошибку уменьшается. Чем не профит?

[SALar]

Это недоработал тестировщик или недоработал программист? Или недоработал постановщик задач? В зависимости от ответов на эти вопросы я смогу повлиять на соответствующих участников команды и исключить подобные инциденты в будущем.

Это недоработал менеджер. Вы точно можете на него повлиять? Тогда влияйте.

[kukolev]

Это недоработал менеджер. Вы точно можете на него повлиять? Тогда влияйте.

Отлично, могу и хочу повлиять на менеджера. Вопрос - в чем он не доработал? Не объяснил тестировщику, что его работа проверять функционал исходя в том числе в том окружении, в котором этот функционал работает? Не объяснил программисту, что разрабатывая ПО нужно ориентироваться на это самое окружение? Как считаете, если менеджер это уже объяснял неоднократно, а ситуация повторяется, о чем это может говорить?

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

[samurai08]

Это недоработал менеджер. Вы точно можете на него повлиять? Тогда влияйте.

Отлично, могу и хочу повлиять на менеджера. Вопрос - в чем он не доработал? Не объяснил тестировщику, что его работа проверять функционал исходя в том числе в том окружении, в котором этот функционал работает? Не объяснил программисту, что разрабатывая ПО нужно ориентироваться на это самое окружение? Как считаете, если менеджер это уже объяснял неоднократно, а ситуация повторяется, о чем это может говорить?

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

Судя по тому, что прочитал, уважемый топикстартер пытается понять, можно ли при помощи только менеджмента решить проблемы с багами, которые возникают при условиях, которые априори неизвестны.
На мой взгляд, это типичная проблема управления рисками тестирования на проекте.
В данном случае, это риск возникновения заранее неизвестных условий. Его можно уменьшить путем повышения компетентности команды: тестировщикам разобраться в предметной области (понять, как работают фреймы в деталях, выясноить как они работают в разных условиях и что влияет на их поведение),а также устроить мозговой штурм тестового сценарий с целью выяснить пропущенные детали.
Далее, если таких рисков много, то возможно, стоит подумать о том, чтобы минимизировать возможные потери от таких рисков.
Например, взять больше времени для тестирования или обдумать возможность отката версии или релизить только для одного заказчика.

[neman]

Везде накосячили и при постановке задачи, и при анализе, и при реализации, и при проверке.

..как это обычно при попадании баги на продакшен и бывает.

[SALar]

Это недоработал менеджер. Вы точно можете на него повлиять? Тогда влияйте.

Отлично, могу и хочу повлиять на менеджера. Вопрос - в чем он не доработал? Не объяснил тестировщику, что его работа проверять функционал исходя в том числе в том окружении, в котором этот функционал работает? Не объяснил программисту, что разрабатывая ПО нужно ориентироваться на это самое окружение? Как считаете, если менеджер это уже объяснял неоднократно, а ситуация повторяется, о чем это может говорить?

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

Я полагаю, что ваш случай попадает под ситуацию, рассматриваемую в эксперименте "красные бусы". Вероятность этого достаточно высока. Деминг говорит о вероятности в 94%. Если это наиболее вероятная гипотеза, пусть на мой взгляд, то давайте я попробую рассмотреть ситуацию именно с этой точки зрения? Возможно моя гипотеза некорректна. Мы в любом случае попробуем поставить фальсифицирующий эксперимемент.
На мой взгляд, это разумный поиск истины, согласны?

> Не объяснил тестировщику, что его работа проверять функционал исходя в том числе в том окружении, в котором этот функционал работает? Не объяснил программисту, что разрабатывая ПО нужно ориентироваться на это самое окружение?
Если моя гипотеза верна, то это бесполезные, а скорее даже вредные действия. Так по крайней мере говорит величайший менеджер двадцатого столетия. Я ему доверяю. Впрочем, я не исключаю вариант, что я неверно его интерпретировал. Все таки я самоучка и семинары Деминга не посещал. К сожалению.

> Как считаете, если менеджер это уже объяснял неоднократно, а ситуация повторяется, о чем это может говорить?
Ровно о том, что ситуация попадает под ситуацию "красных бус". К сожалению, это положительное свидетельство. Критерий Поппера мы пока не прошли. Так что это по прежнему гипотеза. Но вероятность ее правильности увеличилась.

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

PS. Если ищете более простое решение (которое вам возможно и посоветуют), то это без меня. И хорошо бы вы не налетели на действие второй теоремы. Это больно. Очень больно.

PSS. "94% дефектов обусловлены проблемами в управлении" (с) Деминг

[SALar]

Можно произвести "останов линии". Глобально это проблему не решит, но вы будете на пути к усовершенствованию. Только не уверен я, что это приемлемый для вас вариант.

[SALar]

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

Я был не самым плохим тестировщиком. 0.03% прошедших в продакшен дефектов - это ведь неплохой результат для команды? (Это заслуга не только моя, но и окружавших меня коллег.)
Да, я параноик. Я использую принцип Хауза: "Все врут". Программисты, постановщики, заказчики, менеджеры. И вовсе не со зла. Фильм "Я и другие" показывает некоторые источники неверной информации. Я всегда провожу независимый анализ.

[kukolev]

Уважаемый SALar, по части красных бус не соглашусь с вами, думаю здесь уместна следующая аналогия - главный контроллер регулярно получает от двух других значения по 1-2 бусины, что является нормой. Вот только на деле контроллеры регулярно недосчитывают несколько бусин - реально их по 5-6. Неужели нельзя научить контроллеров лучше считать бусины? Тогда мы по крайней мере будем знать их реальное количество и не отправлять плохие лопатки заказчику. Лучше вообще ничего не отправить, чем отправить откровенный брак, разве не так?