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

[natEn]

Всем привет!
Подскажите, ситуация простая: Пм считает, что мы должны выпускать программу без ошибок.
То есть тестеры находят ВСЕ ошибки.
Программисты их ВСЕ исправляют хоть за день до релиза
Бред полный, лечить человека нет желания, скажите, есть ли какие-нибудь известные исследования, статистика, на которую я могла бы сослаться, когда объясняю, что отдел тестирования не найдёт всех ошибок не потому что я тормоз - а потому что это невозможно? :)))

Спасибо!

[serega]

Слабый аргумент, но для такого ПМ может сработать

Предложите в ответ, чтобы программисты писали программы без ошибок

[Imbecile]

Да, самый яркий пример, в том смысле, что он финансово удачный с одной стороны, а сдругой стороны содержит ошибки, это выпуск операционных систем семейства Windows. Так что ставте в пример своему ПМ'у Билла Гейтса и продолжайте работать.

[Tanya_]

предложите вашему менеджменту пообщаться со специалистами в сфере тестирования или послушать трейнинг и понять, кто же на самом деле тестер и как это клёво исправить ошибку перед релизом и возможность получить ваще нерабочий продукт, может подействует

[Rost]

Всем привет!
Подскажите, ситуация простая: Пм считает, что мы должны выпускать программу без ошибок.
То есть тестеры находят ВСЕ ошибки.
Программисты их ВСЕ исправляют хоть за день до релиза  
Бред полный, лечить человека нет желания, скажите, есть ли какие-нибудь известные исследования, статистика, на которую я могла бы сослаться, когда объясняю, что отдел тестирования не найдёт всех ошибок не потому что я тормоз - а потому что это невозможно? :)))

Спасибо!

Соглашусь с serega и Imbecile - хорошие примеры для ПМ-а.
Но на мой взгляд проблема глубже. Во-первых это не Ваше дело лечить ПМ-ов.
У Вас есть руководитель над ПМ-ом. Вот соберите ПМ-а и его начальника. Там и скажите: 1. Требовать отсутствие ошибок в работе, которую выполняет человек - абсурд. Да действительно можно гарантировать, с маленькой погрешностью, отсутствие ошибок если Вы будете тестировать Ваш продукт очень долго и большим количеством людей(кто на это согласится?). 2. за день до релиза Вы не успеете провести регрессионное тестирование что дает риск выпустить вообще нестабильную версию. Вам надо как минимум "Н" дней до релиза. Если захотят делать как говорит ПМ - то это уже не Ваши проблемы. В конце концов ПМ отвечает за проект. Вы свою работу выполнили и предупредили. За день находите баги, а там пусть решают.

Мне кажется, что после того как Вы скажете что ПМ требует АБСОЛЮТНОГО отсутствия ошибок, дальше можно будет не продолжать. НО, если вдруг и ПМ-овский начальник тоже потребует ПОЛНОГО отсутствия ошибок - это клиника. Тогда это не в данный форум.

А сейчас просто напишите письмо своему ПМу и его начальнику с просьбой собраться и опишите два вопроса с Вашим мнением по этому поводу.

Удачи.

[Clauster]

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

[Clauster]

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

Спасибо!

http://www.caseclub....es/testprg.html
http://software-test...juchevyeVoprosy
+ google

[Yury]

ПМ считает, что мы должны выпускать программу без ошибок.
То есть тестеры находят ВСЕ ошибки.
Программисты их ВСЕ исправляют хоть за день до релиза

А почему бы не попробовать следущий подход?
-----------------------------------------------------------
Вы, например, можете сказать:
- Я могу гарантировать, что в программе осталось не более 1000 необнаруженных ошибое, если у меня есть одна неделя на тестирование
- Я могу гарантировать, что в программе осталось не более 100 необнаруженных ошибое, если у меня есть один месяц на тестирование
- Я могу гарантировать, что в программе осталось не более 10 необнаруженных ошибок, если у меня есть один год на тестирование
- Я могу гарантировать, что в программе осталось не более 1 необнаруженной ошибки, если у меня есть десять лет на тестирование
- Я могу гарантировать, что в программе не осталось ни одной необнаруженной ошибки, если у меня есть сто лет на тестирование.

Примечания:
Эти цифры условные - замените их на свои.
Откуда взять эти цифры - от фонаря.
Как объяснить эти цифры - "На основе моего опыта тестирования програмных продуктов с аналогичной архитектурой, аналогичной сложности, разработанных с иcпользованием аналогичного SDLC, .... "

Упрощённый вариант этого метода был использован ещё Ходжой Насреддином, когда он обязался выучить ишака говорить

[natEn]

Майерс написал в свое время программу с 10 строчками кода, у которой было более миллиарда миллиардов возможных ветвлений. Он её писал как раз для того, чтобы объяснить невозможность тестирования на 100%.

[I_G]

Практически любая книга по тестированию описывает невозможность протестировать программу на 100%. Но, простой пример на необходимое количество тестов наверняка поможет Вашему ПМ-у осознать свою абсурдность. И еще интересно - сколько он в отрасли времени работает, и сколько у него завершенных проектов?
Под рукой сейчас, к сожалению нет, но рекоммендую почитать "Тестирование программного обеспечения." Сэма Канера.

[Skomoroh.roker]

А вы не думали, что если до конца проекта далеко, то это может быть просто риторика с целью заставить тест-тим работать лучше, давать багов больше и на более ранних этапах ?

[Imbecile]

А вы не думали, что если до конца проекта далеко, то это может быть просто риторика с целью заставить тест-тим работать лучше, давать багов больше и на более ранних этапах ?

Что это за менеджер, который занимается риторикой, а не управлением? Если же у него такой подход к управлению, то он мне абсолютно не нравится, по той простой причине, что в конце проекта, когда баги всё равно останутся (а они останутся), скажут что тестировщики не выполнили, поставленной ещё в начале проекта, задачи.

[serega]

А вы не думали, что если до конца проекта далеко, то это может быть просто риторика с целью заставить тест-тим работать лучше, давать багов больше и на более ранних этапах ?

Вариант
Из серии, чем вы тут занимаетесь (я вижу как вы работете) и т. п....

Сильнодействующее средство на неокрепшие умы

[Rost]

А вы не думали, что если до конца проекта далеко, то это может быть просто риторика с целью заставить тест-тим работать лучше, давать багов больше и на более ранних этапах ?

Вариант
Из серии, чем вы тут занимаетесь (я вижу как вы работете) и т. п....

Сильнодействующее средство на неокрепшие умы

Не... Вот если бы он говорил, "Чем вы тут занимаетесь, где то, где это? Я вам устрою мастер класс. У меня так не работают. Ану собрались растуда вашу туда..." Это одно. Заряжает.
А говорить абсурдные вещи, при этом заставляя людей понимать насколько человек неадекватный + это дает всем право не обращать на него внимания, потому что его никто не будет воспринимать всерьез.

[Skomoroh.roker]

   Не...  Вот если бы он говорил, "Чем вы тут занимаетесь, где то, где это? Я вам устрою мастер класс. У меня так не работают. Ану собрались растуда вашу туда..." Это одно.  Заряжает. 
А говорить абсурдные вещи, при этом заставляя людей понимать насколько человек неадекватный + это дает всем право не обращать на него внимания, потому что его никто не будет воспринимать всерьез.

Первое мог бы сказать хороший манагер команде сравнительно опытных тестеров.. по крайней мере ответственно относящихся к проекту.
А плохой манагер неопытным тестерам (или обычным тестерам, но .. такой вот манагер), чтобы эту ответственность за преокт создать - вполне и второе ИМХО.

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

[Imbecile]

То есть, если тестеры неопытные, то им можно подсунуть плохого менеджера? И они не имеют права возражать этому только потому, что они сами неопытные?

[Skomoroh.roker]

То есть, если тестеры неопытные, то им можно подсунуть плохого менеджера? И они не имеют права возражать этому только потому, что они сами неопытные?

Хм.... а кто , собственно говорит, что "можно" или "не имеют" ?
Речь о "такое возможно", т.к. информацией о команде или манагере мы для достоверных выводов не располагаем.

[I_G]

Вот и ссылка на статью Counting Tests of Adobe's Full Screen Navigation Options , где приводится простенький пример диалога с 4-мя чекбоксами и одним полем ввода, который влечет 34,358,689,808 возможных тестов.

[Rost]

Вот и ссылка на статью Counting Tests of Adobe's Full Screen Navigation Options  , где приводится простенький пример диалога с 4-мя чекбоксами и одним полем ввода, который влечет 34,358,689,808 возможных тестов.

По моему, мусье I_G ответил на вопрос топика.

[van]

natEn,

Сначала кратко напишу относительно исправления "ВСЕХ" ошибок в последний день перед релизом.

На этот случай аргументация простая:
1. У кого - то из классиков тестирования встречал вполне обоснованные и доказанные данные относительно того, сколько новых ошибок порождает каждое исправление (Там приводилась зависимость от количества строчек кода, сложности программы и т.п.). Поверьте мне, цифры более чем убедительные :) К сожалению, точно не могу вспомнить, где я это читал...

2. А поскольку ошибки исправляются в последний день, то времени на вторичное тестирование не остается :)

Вывод: после каждой правки необходимо вторичное тестирование!

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

2. Так же советую поискать в инете классический пример (классический в рамках уроков по тестированию) графа (моделирующего работу телефонной станции), состоящего из 10 узлов и 14 направленных связей.

Как вы понимаете, существует множеству путей, по которым можно пройти из точки А (вход в граф) до точки В (выход), учитывая различные циклы и возвраты.

На первый взгляд получается очень не сложна программка, НО:
- при ограничении количества возвратов через B 20 разами, количество путей в программе составит около 5(в степени 1) + 5(2) + ... + 5(19) + 5(20) = 10(в степени 14) = 100 триллионов.

- потребуется около миллиарда лет на тестирование всех возможных путей (если кто-либо взялся за написание, исполнение и проверку теста с частотой один за 5 минут).

3. Но все это лишь попытки убедить ПМа. И не является решением проблемы.
Для того, чтобы все - таки попытаться найти решение с менеджером проекта и попытаться максимально качественно (как с Вашей точки зрения, так и с точки зрения ПМ) протестировать программу, необходимо разобраться с тем, что же ПМ подразумевает под "ВСЕ".

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

- самый правильный способ, на мой взгляд, это в качестве "ВСЕХ" определить ряд критериев завершения тестирования и стремиться именно к ним. В качестве таких критериев могут быть:
- временное ограничение (т.е. тестируем, пока есть время и находим столько багов, сколько возможно за отведенное время);
- покрытие требований тестами (каждое требование должно проверятся как минимум одиним тест - кейсом и все тест - кейсы должны быть выполнены);
- покрытие всех строчек кода тестами;
- покрытие всех ветвей тестами;
- какие виды тестирования необходимо провести;
- ошибки с каким статусом можно не исправлять;
- программа должна быть принята заказчиком;
- и т.п.

Дерзайте!