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

Получается, что так.
Расскажите ему про тест-дизайн, как строить тест-анализ.
Научите строить майнд-карты для тест-анализа. С майнд-картами что-то пропустить гораздо сложнее.

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

В качестве инструмента для майнд-карт советую XMind. Есть бесплатная версия и платная.

Вот здесь я слаб, признаюсь. Собственно и не тестировщик я по профессии - программист - с тест-дизайном знаком слабо.

Тестировщик помладше тоже пишут чек листы. В этом тоже много минусов - пишут они их похуже... со всеми вытекающими - пропусков еще больше.

У нас все так и работает.
Единственное, что есть нюанс.

...

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

Бывают еще случаи "Раньше баг не фиксировали, потому что в том билде его не было". Здесь, я так понимаю, нужно хранить предыдущие билды, что пока у нас не делается.

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

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

2. У вас в процессе есть такое понятие как регрессионные тесты? Если завтра релиз, а тут блокеры.

1. За это регламентировано отрывание ног депремирование или увольнение - все в курсе
2. На систематические тесты нет ресурсов. Хотя при внесении правки в модуль проверяется весь его функционал, а не только изменения. Беда в том, что после такой проверки и исправления все равно в конце кто нибудь находит ошибку

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

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

Коллеги, нужен ваш совет!

Есть острое желание организовать процесс тестирования примерно следующим образом:

1. Программист отдает задачу на тест
2. Тестировщик тестирует
3. Программист правит баги, снова отдает задачу
4. Тестировщик тестирует
... повторяются шаги 3-4
N. Тестировщик убедившись, что все баги исправлены и новые не выявлены закрывает задачу

Собственно вопросы - возможно ли добиться такой четкости с предсказуемым временем всего процесса?

Достижим ли шаг N? На данный момент распространена следующая ситуация: завтра релиз, все задачи закрыты, все хорошо... как вдруг - блокирующий баг в уже проверенном модуле! На вопрос "Почему раньше не выявили?" следует ответ "Не догадались проверить..."

Как изжить такую ситуацию?

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

kukolev, бабам - бусы и секреты кухни, а мужикам конкретный разговор:
1. какие ступени карьеры ты прошёл, прежде, чем стал "руковожу процессом разработки и тестирования"?
2. исходник с участком кода, где была ошибка обработки события наведения курсора на фрейм смотрел? или на этом уровне адекватно проводить анализ причин ошибки разработки не можешь?
3. какие тест-планы, кейсы, чек-листы, ... что из согласованного тобой не выполнил тестер? или под твоим руководством тестер не имеет конкретных заданий, работает в условиях неопределённости?
4. что это за непрофессиональный лепет ты используешь: "если пользователь проводил мышкой над Фрйэмом" вместо, например, "когда пользователь наводит курсор мыши на Фрйэм"?
5. такой, как ты есть, руководитель над разработчиками и тестерами, зачем ты им нужен? какой их ответ предполагаешь?
6. какая методология в управлении у тебя используется? сам-то продукт смотришь/проверяешь?
Не выяснив ответы на эти вопросы, не готов ответить "кто виноват?" разработчик или тестировщик!

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

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

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

Именно.
То, что программист допустил ошибку, а тестировщик ее не нашел обусловлено системой, а не личными качествами инженеров.

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

Коллеги, это противоречие, и эксперимент с бусинами вызывает сомнение. Более адекватный эксперимент - если рабочему разрешено сделать 10 вариантов лопаток и выбрать лучшую. Вот в этом случае можно будет говорить о стараниях рабочего (тестировщика), заработает идея с премированием / депремированием. Хороший работнгик будет стараться и будет приносить минимум красных бусинок. Хороший работник может вообще остаться после работы и делать лопатки до тех пор, пока там не будет НОЛЬ бусинок. Вопрос - у меня хороший тестировщик? должен ли он был выполнить данные проверки? Принят ли такой подход у тестировщиков, или я прошу невозможного?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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