Lesson 69
Хором повторяем мантру: У нас самый замечательный офис и все остальные офисы завидуют нам!
Не, ну серьезно. Особенно радует pivpav утренними шаржами с возможностью их дополнить и улучшить.
Пруфпик:
Альбом: office
Слово Канеру:
Сообщайте о ошибках проектирования.
ПО создает ценность для людей. Это задача ПО. Программа - часть системы, включающей оборудование, другие программы и людей. ПО имеет меньшую ценность, если оно сложно в использовании, запутано, несовместимо с другими программами или завязано на узкий диапазон железа. Может быть, вы единственный член команды разработки, кто смог увидеть и оценить ошибки проектирования и то, как они повлияют на работу системы. Если вы не зарепортите эти проблемы, то кто?
Некоторые люди (включая некоторых консультантов по тестированию) утверждают, что тестировщики не должны сообщать о дефектах проектирования, так как дизайн продукта должен быть согласован в начале проекта и у тестировщиков нет экспертизы для его оценки. Мы считаем эту точку зрения ошибочной по двум причинам.
О запоздалой критике проектирования Даже если продукт был полностью спроектирован заранее (что маловероятно в реальных условиях реального мира), люди не полностью видят систему до тех пор, пока она не будет создана. Это вполне нормально для людей - понимать, что система неверно спроектирована, только после начала работы с ней. О проблемах нужно сообщать, когда они обнаружены, и многие из них не будут найдены до тех пор, пока система не будет почти закончена.
О проблемах с экспертизой Действительно, тестировщики отличаются по своей способности понимать и оценивать вопросы проектирования. С другой стороны тестировщики это те люди, которые сопровождают система через все этапы до продажи ПО или его запуска в производство. Exercise some caution if you don't have relevant expertise. Например, перед критикой пользовательского интерфейса, стоит почитать документацию системы и пообщаться с другими людьми, которые знают о проектировании больше вас. Но если вы уверены, что проблема есть - занесите ее в багтрекер.
Группа тестирования может стать более компетентной в оценке проблем проектирования, нанимая людей с разнообразным опытом. Тестировщик с экспертизой в домене (глубокие знания о том, как будет использоваться продукт) может сосредоточиться на тестировании и обработке вопросов, которые беспокоят адекватных пользователей. Это лишь одна из областей, экспертиза в которой может улучшить вашу группу. Если один из тестировщиков имеет опыт проектирования баз данных, другой - сетевой безопасности и так далее, то группа в целом позиционируется, как делающая полезные оценки различных аспектов работы продукта.
Примечания
- Именно поэтому мы видим большой интерес к таким современным подходам, как XP и RUP (более общее - итеративный, адаптивный, эволюционный, гибкий подходы ). Эти подходы принимают как данность то, что изменения требований к продукту появятся и стремятся минимизировать риски этих изменений. См. например Beck 1999, Kruchten 2000, and http://www.agilealliance.org.
- Apple, Microsoft, Sun и многие другие публиковали руководящие принципы разработки пользовательского интерфейса.
- Не всегда возможно сформировать правильный набор людей в контрольной группе в срок. Возможно, вам придется работать со сторонними консультантами или провести обучение персонала или для выполнения некоторых видов оценок.
Там внутри я так и не перевел одно предложение, реквестирую подсказки.
Не, ну серьезно. Особенно радует pivpav утренними шаржами с возможностью их дополнить и улучшить.
Пруфпик:
Альбом: office
Слово Канеру:
Сообщайте о ошибках проектирования.
ПО создает ценность для людей. Это задача ПО. Программа - часть системы, включающей оборудование, другие программы и людей. ПО имеет меньшую ценность, если оно сложно в использовании, запутано, несовместимо с другими программами или завязано на узкий диапазон железа. Может быть, вы единственный член команды разработки, кто смог увидеть и оценить ошибки проектирования и то, как они повлияют на работу системы. Если вы не зарепортите эти проблемы, то кто?
Некоторые люди (включая некоторых консультантов по тестированию) утверждают, что тестировщики не должны сообщать о дефектах проектирования, так как дизайн продукта должен быть согласован в начале проекта и у тестировщиков нет экспертизы для его оценки. Мы считаем эту точку зрения ошибочной по двум причинам.
О запоздалой критике проектирования Даже если продукт был полностью спроектирован заранее (что маловероятно в реальных условиях реального мира), люди не полностью видят систему до тех пор, пока она не будет создана. Это вполне нормально для людей - понимать, что система неверно спроектирована, только после начала работы с ней. О проблемах нужно сообщать, когда они обнаружены, и многие из них не будут найдены до тех пор, пока система не будет почти закончена.
О проблемах с экспертизой Действительно, тестировщики отличаются по своей способности понимать и оценивать вопросы проектирования. С другой стороны тестировщики это те люди, которые сопровождают система через все этапы до продажи ПО или его запуска в производство. Exercise some caution if you don't have relevant expertise. Например, перед критикой пользовательского интерфейса, стоит почитать документацию системы и пообщаться с другими людьми, которые знают о проектировании больше вас. Но если вы уверены, что проблема есть - занесите ее в багтрекер.
Группа тестирования может стать более компетентной в оценке проблем проектирования, нанимая людей с разнообразным опытом. Тестировщик с экспертизой в домене (глубокие знания о том, как будет использоваться продукт) может сосредоточиться на тестировании и обработке вопросов, которые беспокоят адекватных пользователей. Это лишь одна из областей, экспертиза в которой может улучшить вашу группу. Если один из тестировщиков имеет опыт проектирования баз данных, другой - сетевой безопасности и так далее, то группа в целом позиционируется, как делающая полезные оценки различных аспектов работы продукта.
Примечания
- Именно поэтому мы видим большой интерес к таким современным подходам, как XP и RUP (более общее - итеративный, адаптивный, эволюционный, гибкий подходы ). Эти подходы принимают как данность то, что изменения требований к продукту появятся и стремятся минимизировать риски этих изменений. См. например Beck 1999, Kruchten 2000, and http://www.agilealliance.org.
- Apple, Microsoft, Sun и многие другие публиковали руководящие принципы разработки пользовательского интерфейса.
- Не всегда возможно сформировать правильный набор людей в контрольной группе в срок. Возможно, вам придется работать со сторонними консультантами или провести обучение персонала или для выполнения некоторых видов оценок.
Там внутри я так и не перевел одно предложение, реквестирую подсказки.