философия тестирования

Не бывает у нас профессиональных болезней, кроме профессиональных достоинств, и не надо их в себе искать... :)

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

Тестер - человек, своей деятельностью уменьшающий количество неприятностей в жизни и улучшающий мир, как никто в разработке ПО!!!

Как вам такая философия тестирования
Dixi 

Ну вот. :-) Если вычеркнуть про "...все умрут..." то очень неплохо. ;-)
Понимаешь что ты подсознательно рушишь, зато веришь что на благо человечества, и нет никаких комплексов. :-)

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

Ну вот. :-) Если вычеркнуть про "...все умрут..." то очень неплохо. ;-)
Понимаешь что ты подсознательно рушишь, зато веришь что на благо человечества, и нет никаких комплексов. :-)

Замените "веришь" на "знаешь" и "рушишь" на "убираешь лишнее" - и будет то, что я имел в виду.
Микеланджело, создавая свои статуи, рушил? А ведь он фактически камни ломал. Лежали они себе на улице - никому не мешали, а он накинулся и ну кромсать их, понимаешь, молотком и зубилом...
Мы, конечно, не Микеланджелы, но тоже стараемся по мере сил

Ну вот. :-) Если вычеркнуть про "...все умрут..." то очень неплохо. ;-)
Понимаешь что ты подсознательно рушишь, зато веришь что на благо человечества, и нет никаких комплексов. :-)

Замените "веришь" на "знаешь" и "рушишь" на "убираешь лишнее" - и будет то, что я имел в виду.
Микеланджело, создавая свои статуи, рушил? А ведь он фактически камни ломал. Лежали они себе на улице - никому не мешали, а он накинулся и ну кромсать их, понимаешь, молотком и зубилом...
Мы, конечно, не Микеланджелы, но тоже стараемся по мере сил

К радости Микеланджело, да и нашей тоже, после того, как он кромсанул камень, в очередной раз, вся улица не разваливалась и не надо было ее заново отстраивать.

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

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

Тестирование - это не ломание программы. Это поиск (!) мест, где она сломана. Ну типа собаки и минное поле, как-то так.
Вот такая теория не похожа на правду? Насчет того, что понятие "я ломаю программу" похоже на усиление собственного статуса.

Тестирование - это не ломание программы. Это поиск (!) мест, где она сломана.

На следующем уровне этой интересной игры приходит понимание, что даже не в этом весь фокус :)

Тестирование - это не ломание программы. Это поиск (!) мест, где она сломана.

На следующем уровне этой интересной игры приходит понимание, что даже не в этом весь фокус :)

Мне тут стало интересно вот что - отношение к обьекту тестирования. Т.е. "сломать" программу - это ведь некоторая ассоциация с благородным хакерским трудом. Т.е. я сделал что-то - программа сломалась. Ну вроде самоопределения себя в рабочем процессе. Не знаю, как сказать четче, чтоб никого не обидеть:)

А в чем весь фокус, кстати?

А в чем весь фокус, кстати?

Совсем простенький пример.
До выпуска остается не так много времени. У вас есть выбор занести в базу десяток ошибок, которые гарантированно не будут правиться или потратить время на поиск сложной ошибки, которая может блокировать выпуск.
Ваши действия?

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

Совсем простенький пример.
До выпуска остается не так много времени. У вас есть выбор занести в базу десяток ошибок, которые гарантированно не будут правиться или потратить время на поиск сложной ошибки, которая может блокировать выпуск.
Ваши действия?

Заносятся в базу все найденные ошибки. Не важно будут ли они все исправлены...
Просто у каждой выставляется приоритет, а дальше уже сам процесс...
Очень часто возникает другая проблема: "исправлено в одно месте, вылезла в другом". И кто тут виноват?

Даже можно видоизменить вопрос:
Кто виноват и ЧТО делать?

Совсем простенький пример.
До выпуска остается не так много времени. У вас есть выбор занести в базу десяток ошибок, которые гарантированно не будут правиться или потратить время на поиск сложной ошибки, которая может блокировать выпуск.
Ваши действия?

Заносятся в базу все найденные ошибки. Не важно будут ли они все исправлены...
Просто у каждой выставляется приоритет, а дальше уже сам процесс...
Очень часто возникает другая проблема: "исправлено в одно месте, вылезла в другом". И кто тут виноват?

Т.е. вы отказались от поиска серьезной ошибки.
* Первые покупатели столкнулись с потерей данных;
* Продажа продукта прекращена;
* Продукт отправлен на доработку;
* Покупателям принисены извинения в денежном эквиваленте;
* 5% потенциальных покупателей ушли к конкуренту.

Предупреждая остальные вопросы и уточнения даю правильный ответ:
Зависит от обстоятельств. В первую очередь от того, к какой категорри относится продукт.[1]
К чемя я клоню. Иногда главным продуктом являются ошибки, иногда оценка качества продукта. Или применяя метафору: в зависимости от обстоятельств, главным может быть или число выкопанных мин, или разминированный проход, или табличка "проверено мин нет".

----------------------------------------------------------------------
[1] Скот Адамс предложил бы другой критерий выбора:
Зависит от обстоятельств. В первую очередь от того, за что лишают премий. За недостаточное число ошибок или за пропущенную ошибку в конечном продукте.

Совсем простенький пример.
До выпуска остается не так много времени. У вас есть выбор занести в базу десяток ошибок, которые гарантированно не будут правиться или потратить время на поиск сложной ошибки, которая может блокировать выпуск.
Ваши действия?

Заносятся в базу все найденные ошибки. Не важно будут ли они все исправлены...
Просто у каждой выставляется приоритет, а дальше уже сам процесс...
Очень часто возникает другая проблема: "исправлено в одно месте, вылезла в другом". И кто тут виноват?

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

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

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

Хорошие слова.
Но ошибки у нас заносятся сразу в базу, выставляется приоритет (и вся подобная информация: тип ошибки, принадлежность к компонету и т.д.). Занимает это от 1 до 5 мин (как описывать). Но обычно это занимает ~1 мин. В базу ошибок имеет доступ и заказчик, он может их просмотреть, и при необходимости внести найденную ошибку или оставить комментарий к уже заведенным. Но как показывает практика заказчик активен только на этапе обсуждения ТЗ. А далее только "в режиме просмотра" и некоторых(редких) комментариев, т.е. на конечных и пред конечных этапах, когда предоставляется ПО на их обозрение.

Как Вам такой подход?
ПО - Web сайты.

Очень часто возникает другая проблема: "исправлено в одно месте, вылезла в другом". И кто тут виноват?

Вы хотите сказать что не знаете ответа?

Очень часто возникает другая проблема: "исправлено в одно месте, вылезла в другом". И кто тут виноват?

Вы хотите сказать что не знаете ответа?

"По секрету" скажу: знаю!

Хорошие слова.
Но ошибки у нас заносятся сразу в базу, выставляется приоритет (и вся подобная информация: тип ошибки, принадлежность к компонету и т.д.). Занимает это от 1 до 5 мин (как описывать). Но обычно это занимает ~1 мин. В базу ошибок имеет доступ и заказчик, он может их просмотреть, и при необходимости внести найденную ошибку или оставить комментарий к уже заведенным. Но как показывает практика заказчик активен только на этапе обсуждения ТЗ. А далее только "в режиме просмотра" и некоторых(редких) комментариев, т.е. на конечных и пред конечных этапах, когда предоставляется ПО на их обозрение.

Как Вам такой подход?
ПО - Web сайты.

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

Очень часто возникает другая проблема: "исправлено в одно месте, вылезла в другом". И кто тут виноват?

Вы хотите сказать что не знаете ответа?

"По секрету" скажу: знаю!

Виноват тот, кто исправлял

... Вы будете выполнять все виды тестирования, но поверхностно, или выделите наиболее приоритетные и уделите им больше времени в ущерб малозначимым?

Все-таки упор делается в основном на функционал - самая проблемная область у нас. Но даже функциональные ошибки разделяются по приоритету.
Я бы сказал: четкое разделение ошибок и труда среди тестировщиков.

Но ошибки у нас заносятся сразу в базу, выставляется приоритет (и вся подобная информация: тип ошибки, принадлежность к компонету и т.д.). Занимает это от 1 до 5 мин (как описывать). Но обычно это занимает ~1 мин.

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

Вот о таком варианте речь и шла.