Как сохранить критическое мышление
#1
Отправлено 04 октября 2013 - 14:24
Сегодня, в процессе создания тестовых данных,не совсем стандартным путем, наткнулась на ошибку. (Функция есть, половину переменных меняет, половину в текущей реализации поменять не может).
Завожу дефект, со спокойной совестью продолжаю тестирование.
И тут начинается:
"а в какой документации написано, что должно работать именно так. " (аналитик) /*я искала, не нашла */
"а зачем ты вообще к этому прицепилась, работает же как-то на продакшене" (бизнес-заказчик)
Благо у меня есть руководители, на которых я могу сложить отвественность за такие вещи :)
Собственно сабж. Как сохранить критическое мышление, когда все везде работает "кое-как"? Когда уже просто не хочется видеть ошибки, потому что о "качественных системах" речи уже не идет, речь идет о системах, которые хоть как-то работают.
Тут, конечно, опять можно бросить камень в QA и заявить, что ваша задача спланировать разработку таким образом, чтобы продукт был тестируем, легко правились ошибки, непроблемно заливались новые функциональности... (в общем все то, о чем пишут умные американцы).
Но что же делать, когда уже все плохо?
В маленьких компаниях, для небольших продуктов можно изменить процесс разработки / тестирования, а что делать когда в процесс вовлечено около 1000 человек (а количество компонентов могут только админы посчитать).
А вы сохраняете критическое мышление или соглашаетесь с тем, что система хоть как-то работает и лучше не трогать больше, а то мы её никогда не стабилизируем. ?
С упованьем и крепкой дубиной,
Понижением акций грозили притом,
И пленяли улыбкой невинной.
#3
Отправлено 06 октября 2013 - 11:10
Да, сохраняю критическое мышление. Стабилизация - понятие немного относительное в ключе обновлений новых версий.А вы сохраняете критическое мышление или соглашаетесь с тем, что система хоть как-то работает и лучше не трогать больше, а то мы её никогда не стабилизируем. ?
Хорошо сказано. Получается расставлять приоритеты по ошибкам и доработкам программного обеспечения, зная техническое задание, понимая технологически проект, зная важные замечания и просьбы пользователей за период жизни проекта, важные цепочки информационных потоков и барьерные (логические контроли), регламент, анализируя накопленную базу знаний в системе управления дефектами. Относиться как к правилу и регистрировать все замечания, с приложением необходимой доказательной базы, дискутировать, корректно обсуждать с причастными специалистами наблюдения и сомнения. В большом, многолетнем проекте можно занимать четкую и ответственную свою позицию, работать, делать все на своем уровне зависящее по зоне ответственности и по зоне влияния. Что-то зависит и от авторитета тестировщика, нарабатываемого временем и на этом доверии, работоспособности, работе над собой, в том числе и основывается слаженная работа в проекте.Критическое мышление надо развивать, а учиться сохранять надо фокус, на наиболее важных в данном контексте вещах.
С уважением, Vita
... you can learn from that too
#4
Отправлено 15 октября 2013 - 09:27
Coyote, если есть документация, где описано КАК должно быть - тут спорить сложно...Многие, многие тренинги, книжки по тестированию начинаются с описания критического мышления. (по-моему изначально майерсу приписывают, хотя могу ошибаться).
Сегодня, в процессе создания тестовых данных,не совсем стандартным путем, наткнулась на ошибку. (Функция есть, половину переменных меняет, половину в текущей реализации поменять не может).
Завожу дефект, со спокойной совестью продолжаю тестирование.
И тут начинается:
"а в какой документации написано, что должно работать именно так. " (аналитик) /*я искала, не нашла */
"а зачем ты вообще к этому прицепилась, работает же как-то на продакшене" (бизнес-заказчик)
- Программист.
У тестировщика всегда чётное количество синяков: если он наступил на грабли - обязан воспроизвести ошибку.
(bash.org)
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных