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

[Bars Master]

Простите, что поправила ошибки и знаки препинания в тексте.

Ничего страшного, я виноват, торопиться меньше надо.

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

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

[Vita]

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

Если у ребенка есть игрушка, которую нельзя сломать, то он воспользуется ею, чтобы сломать другие. Эта мысль звучала в вопросе передачи "Что, где, когда?", если не ошибается моя подруга.

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

Вы мало в жизни вещей сломали, а разобрали на детали? Было это полезно для Вас?

[jurteg]

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

[Clauster]

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

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

[LeshaL]

Загвоздка только в том, что тестировщики не "ломают" ПО. Они его получают уже "ломаным".

Плюс стопятьсот! Я даже думал отдельную заметку по этому поводу написать, если еще никто не сделал.

[jurteg]

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

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

В принципе мой пост как раз про это, я специально взял в кавычки слово "ломание".

[Фрося]

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

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

Не соглашусь со словами "ломаное ПО".
Тестировщики получают ПО, не готовое к поставке потребителю.
Как аналогия.
Есть такая работа - настройщик радиоэлектронной аппаратуры.
Он получает некий блок/ дивайс от сборщиков. Блок не ломаный - он просто не прошел всю технологическую цепочку.
Его надо настроить - что-то подвинтить, что-то подкрутить....
Когда настройщик все что положено сделает (а может и "завернет" блок), он передаст его в ОТК.
А ОТК - проведет проверки и скажет - есть! блок замечательный можно продавать!
Вот тестировщик и выполняет роль настройщика РЭ и ОТК в "одном флаконе".

Необходимый элемент технологической цепочки. Работающий не со "сломанным ПО" , а еще не готовым конечным продуктом.

[Clauster]

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

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

Не соглашусь со словами "ломаное ПО".
Тестировщики получают ПО, не готовое к поставке потребителю.
Как аналогия.
Есть такая работа - настройщик радиоэлектронной аппаратуры.
Он получает некий блок/ дивайс от сборщиков. Блок не ломаный - он просто не прошел всю технологическую цепочку.
Его надо настроить - что-то подвинтить, что-то подкрутить....
Когда настройщик все что положено сделает (а может и "завернет" блок), он передаст его в ОТК.
А ОТК - проведет проверки и скажет - есть! блок замечательный можно продавать!
Вот тестировщик и выполняет роль настройщика РЭ и ОТК в "одном флаконе".

Необходимый элемент технологической цепочки. Работающий не со "сломанным ПО" , а еще не готовым конечным продуктом.

Вы путаете теплое с мягким. Тестировщик не изменяет качество ПО. Ничего там не подкручивет и не подвинчивает.

[Clauster]

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

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

В принципе мой пост как раз про это, я специально взял в кавычки слово "ломание".

И как понимать ваши кавычки, когда слова деструктивный и ломание идут рядом?

[Фрося]

Вы путаете теплое с мягким. Тестировщик не изменяет качество ПО. Ничего там не подкручивет и не подвинчивает.

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

В т.ч. - и работник архива. И технический писатель. И тестировщик, естественно.

(впадает в занудство и лезет в шкап за ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем" и собирается процитировать из п.10 Процесс обеспечения качества ПО, подумав - решает что цитировать оттуда слишком много придется, да и вообще - несколько не в рамках темы......... )

Так что - никакой путаницы!

[Clauster]

Вы путаете теплое с мягким. Тестировщик не изменяет качество ПО. Ничего там не подкручивет и не подвинчивает.

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

В т.ч. - и работник архива. И технический писатель. И тестировщик, естественно.

(впадает в занудство и лезет в шкап за ГОСТ Р 51904-2002 "Программное обеспечение встроенных систем" и собирается процитировать из п.10 Процесс обеспечения качества ПО, подумав - решает что цитировать оттуда слишком много придется, да и вообще - несколько не в рамках темы......... )

Так что - никакой путаницы!

Я не хочу впадать в дискуссию, но не я ввел в теме термин ломать, я его поддержал в контексте, чтобы было понятно.
По поводу аналогий - видимо не совсем удачная, если мне не удалось сразу понять. Почему блок не ломаный? А если проводок переломанный, дорожка не протравилась на плате, элемент какой-нибудь бракованный, кондёр забыли припаять и т.д.?
И опять таки тестировщик не в состоянии принять решения можно ли продавать продукт или нет. По крайней мере не должен его принимать. Радиоэлектронный блок - типовой конвейерный продукт. С ПО посложнее будет.
По поводу упомянутого ГОСТа - для меня он не является хоть сколько-нибудь нормативным актом, соответствено так же, не является авторитетным источником.

[Фрося]

Я не хочу впадать в дискуссию, но не я ввел в теме термин ломать, я его поддержал в контексте, чтобы было понятно.
По поводу аналогий - видимо не совсем удачная, если мне не удалось сразу понять. Почему блок не ломаный? А если проводок переломанный, дорожка не протравилась на плате, элемент какой-нибудь бракованный, кондёр забыли припаять и т.д.?
И опять таки тестировщик не в состоянии принять решения можно ли продавать продукт или нет. По крайней мере не должен его принимать. Радиоэлектронный блок - типовой конвейерный продукт. С ПО посложнее будет.
По поводу упомянутого ГОСТа - для меня он не является хоть сколько-нибудь нормативным актом, соответствено так же, не является авторитетным источником.

Хм.. Именно что - не ломанный. Не прошедший полный технологический цикл.
Сама посылка - что к тестировщику попадает нечто ломаное, на мой взгляд не верна.

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

[Clauster]

Я не хочу впадать в дискуссию, но не я ввел в теме термин ломать, я его поддержал в контексте, чтобы было понятно.
По поводу аналогий - видимо не совсем удачная, если мне не удалось сразу понять. Почему блок не ломаный? А если проводок переломанный, дорожка не протравилась на плате, элемент какой-нибудь бракованный, кондёр забыли припаять и т.д.?
И опять таки тестировщик не в состоянии принять решения можно ли продавать продукт или нет. По крайней мере не должен его принимать. Радиоэлектронный блок - типовой конвейерный продукт. С ПО посложнее будет.
По поводу упомянутого ГОСТа - для меня он не является хоть сколько-нибудь нормативным актом, соответствено так же, не является авторитетным источником.

Хм.. Именно что - не ломанный. Не прошедший полный технологический цикл.
Сама посылка - что к тестировщику попадает нечто ломаное, на мой взгляд не верна.
- и т.д. и т.п.

Более конкретный пример: разработчик вносит изменения в код, при этом в других местах полностью ломается функциональность ( возможно даже вплоть до того, что происходит обвал системы с потерей данных, невозможностью восстановления и т.д.) Причем, прохождение вашего технологического цикла не позволяет выявить эту ошибку. Можете взять для более конкретного примера скандал с антенной iPhone 4. Или с педалью тормоза у Toyota. Думаете, эти продукты не прошли полный технологический цикл, особенно в Toyota?

И чтоб два раза не вставать, перевод главы из книжки Lessons Learned in Software Testing
За сим откланиваюсь.

[Фрося]

Более конкретный пример: разработчик вносит изменения в код, при этом в других местах полностью ломается функциональность ( возможно даже вплоть до того, что происходит обвал системы с потерей данных, невозможностью восстановления и т.д.) Причем, прохождение вашего технологического цикла не позволяет выявить эту ошибку. Можете взять для более конкретного примера скандал с антенной iPhone 4. Или с педалью тормоза у Toyota. Думаете, эти продукты не прошли полный технологический цикл, особенно в Toyota?

И чтоб два раза не вставать, перевод главы из книжки Lessons Learned in Software Testing
За сим откланиваюсь.

В ответ на ссылку - посмотрите IEEE Guide to the Software Engineering Body of Knowledge(1) - SWEBOK®, 2004.
Можно тут на русском глянуть http://swebok.sorlik...re_quality.html .

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

Соблюдение технологического цикла позволит избежать появление ошибок. Нарушения - приводут к появлению ошибок.

[Clauster]

В ответ на ссылку - посмотрите IEEE Guide to the Software Engineering Body of Knowledge(1) - SWEBOK®, 2004.
Можно тут на русском глянуть http://swebok.sorlik...re_quality.html .

Очередной стандарт? А что именно там является ответом и на что? Я вопроса не задавал, и не собирался переубеждать вас, уважаемый представитель quality school. Я считаю, что следование стандартам и шаблонам очень сильно ограничивает, мешает раскрыть свой потенциал. А потом, к ним просто-напросто привыкаешь и уже начинаешь мыслить шаблонно и стереотипно.

Соблюдение технологического цикла позволит избежать появление ошибок. Нарушения - приводут к появлению ошибок.

Ах вот как у вас все просто. Т.е. если человек опечатался, это нарушение технологического цикла?

[Куатор]

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

[aleksirin]

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

Лично я считаю, что тестировщик должен быть прежде всего любознательным исследователем и(или) ответственным испытателем, а уж потом можно и деструктором.