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

[Coyote]

Многие, многие тренинги, книжки по тестированию начинаются с описания критического мышления. (по-моему изначально майерсу приписывают, хотя могу ошибаться).

Сегодня, в процессе создания тестовых данных,не совсем стандартным путем, наткнулась на ошибку. (Функция есть, половину переменных меняет, половину в текущей реализации поменять не может).

Завожу дефект, со спокойной совестью продолжаю тестирование.

И тут начинается:
"а в какой документации написано, что должно работать именно так. " (аналитик) /*я искала, не нашла */
"а зачем ты вообще к этому прицепилась, работает же как-то на продакшене" (бизнес-заказчик)

Благо у меня есть руководители, на которых я могу сложить отвественность за такие вещи :)

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


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

Но что же делать, когда уже все плохо?

В маленьких компаниях, для небольших продуктов можно изменить процесс разработки / тестирования, а что делать когда в процесс вовлечено около 1000 человек (а количество компонентов могут только админы посчитать).

А вы сохраняете критическое мышление или соглашаетесь с тем, что система хоть как-то работает и лучше не трогать больше, а то мы её никогда не стабилизируем. ?

[Clauster]

Критическое мышление надо развивать, а учиться сохранять надо фокус, на наиболее важных в данном контексте вещах.

[Vita]

А вы сохраняете критическое мышление или соглашаетесь с тем, что система хоть как-то работает и лучше не трогать больше, а то мы её никогда не стабилизируем. ?

Да, сохраняю критическое мышление. Стабилизация - понятие немного относительное в ключе обновлений новых версий.

Критическое мышление надо развивать, а учиться сохранять надо фокус, на наиболее важных в данном контексте вещах.

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

[notProgrammer]

Многие, многие тренинги, книжки по тестированию начинаются с описания критического мышления. (по-моему изначально майерсу приписывают, хотя могу ошибаться).

Сегодня, в процессе создания тестовых данных,не совсем стандартным путем, наткнулась на ошибку. (Функция есть, половину переменных меняет, половину в текущей реализации поменять не может).

Завожу дефект, со спокойной совестью продолжаю тестирование.

И тут начинается:
"а в какой документации написано, что должно работать именно так. " (аналитик) /*я искала, не нашла */
"а зачем ты вообще к этому прицепилась, работает же как-то на продакшене" (бизнес-заказчик)

Coyote, если есть документация, где описано КАК должно быть - тут спорить сложно...