Слово Канеру
Программисты рады помочь с тестируемостью приложения.
ольшинство программистов хотят, чтоб их программа хорошо тестировалась. Они пытаются сделать свою работу хорошо, знают, что могут совершать ошибки и ждут, что вы их найдете.
Для тестировщика тестируемость это то, что делает проще тестирование приложения. Для разговора с программистами, более точное определение тестируемости — прозрачность и контрол (Lesson 137). Это определение показывает природу функций, которые могут помочь. Зная это они могут предложить такие фичи, о которых вы бы и не подумали (или не попросили), но которые моги быть полезными. Какие фичи вы должны попросить? См. Lesson 137, там есть ряд примеров.
Многие тестировщики были разочарованы в попытках заполучить фичи для тестируемости от программистов. Мы считаем, что есть три ключевых момента, благодаря которым эти попытки могут достичь успеха.
Говори на их языке Полезно иметь возможность читать документацию и код. Мы могли бы создать запрос в терминах, которые они понимают. Если вы можете точно указать, какой интерфейс вы хотите, в какой части кода, они дадут вашему запросу ход. В действительности, вы будете приятно удивлены, обнаружив, что такие функции уже добавлены, чтоб помочь с отладкой других задач.
Просите заранее См. Lesson 138 Заранее начинайте автоматизацию.
Будьте реалистом Некоторые запросы тестируемости достаточно малы, чтобы быть запланированными вместе с другими задачами по разработке. Другие представляют собой новые фичи и должны быть запланированы в бюджете так же, как и любые другие. You'll have to champion these to management as well.
Большинство программистов любят программировать. Если ваши просьбы будут точными и разумными, у них есть шанс магически выполниться. Что программистам не нравится, так это пытаться читать мысли людей. Они не приветствуют неоднозначные просьбы.
Многие тестировщики говорят, что программисты отклоняют их просьбы с оправданиями «Это поставит под угрозу безопасность продукта», «Это уменьшит производительность». Это обоснованные опасения. Но мы считаем, что, как правило, эти фразы маскируют «мы не хотим думать над этим». В таком случае вам понадобится умение продавать свои идеи, чтоб помочь программистам понять, что в конечном счете это принесет пользу. Возможно, вам придется искать кого-то, кто имеет права или влияние сделать ваши задачи. Тем не менее, если вы знаете, что просите, просите вовремя, просите красиво, то мы думаем, что вашу просьбу конструктивно рассмотрят.
Мы видели много фич тестируемости, которые были очень выгодны для тестируемости продукта. Некоторые были созданы по просьбе одного из нас. Другие предложены командами тестировщиков и программистов. Они были сложны для создания, но стоили того. Мы призываем вас быть настойчивыми.
Показаны сообщения с ярлыком chapter 7. Показать все сообщения
Показаны сообщения с ярлыком chapter 7. Показать все сообщения
пятница, 24 августа 2012 г.
среда, 22 августа 2012 г.
Lesson 155
Ну, или как-то так - шесть правил Глеба Жеглова:
Слово Канеру
Программисты любят говорить о своей работе. Задавайте им вопросы.
Многие тестировщики говорят, что у них проблемы с получением информации от программистов. Мы же находим, что программисты, напротив, очень часто хотят говорить о своей работе.
Для начала, хороший способ — поговорить о проектной документации. Начните работу. Прочтите имеющиеся документы. Если есть возможность, посмотрите исходный код.
Документация программистов может вводить в заблуждение. Спросите их о разделах, которые вам кажутся важными, но которые вы не понимаете. Иногда для вопросов можно использовать электронную почту, но личное общение более эффективно, особенно, если возникнут новые вопросы. Если они согласны на встречу, готовьтесь, не тратьте их время впустую.
Если у них нет документации, то попросите нарисовать картину, диаграмму системы. У большинства программистов есть образ системы, с которым они работают, они будут рады им поделиться.
Вы могли бы найти их диаграммы на доске. Одним из методов является указание на случайную стрелку и вопрос: «Что случится, если это не сработает?». Это может выявить отсутствие обработки ошибок и наличие необоснованных предположений. Вопросы, подобные этому, заданные двум или большему количеству программистов, могут выявить интересные различия.
Почему нужно задавать эти вопросы? Чтоб узнать больше о создаваемой системе, чтоб знать, каким образом она может ломаться, чтоб узнать предположения людей, создающих эту систему. Не будьте для них проверяющим или надсмотрщиком, если они узнают, что это так, то перестанут сотрудничать.
Когда вы получите ответы, напишите заметки и поделитесь ими с программистами или другими тестировщиками. Программисты не любят отвечать на одни и те же вопросы от разных тестировщиков.
Знание языка программирования поможет вам. Если они программируют на C++ или Java вы должны иметь о нх представление. Если ваше ПО многопоточное, вы должны иметь представление о потоках.
Активное слушание само по себе полезно для вас. В разговоры каждый вносит свой вклад идеями, опытом, остроумием. Когда вы слушаете, вы сосредоточены на том, чтоб помочь человеку сказать то, что он хочет сказать. Это включает себя переформулировку в понятные термины, наводящие вопросы, позволяющие получить дополнительную информацию из контекста и сделать выводы.
Ваша работа как тестировщика думать о том, как именно продукт может не работать. Но как член команды вы должны понимать, что продукт только создается. Пусть программисты знают, что вы понимаете ценность их работы.
Не говорите программистам, что они должны предоставить определенную документацию, прежде чем вы сделаете свою работу. Если она у них есть, спросите. Если вам все же нужна информация — спросите самого программиста. Объясните, почему вам это нужно и как поможет вашей работе. Они не могут читать ваши мысли. (См. Gause и Weinberg 1989, Chapter 6; Michalko 1991, Chapter 14).
Слово Канеру
Программисты любят говорить о своей работе. Задавайте им вопросы.
Многие тестировщики говорят, что у них проблемы с получением информации от программистов. Мы же находим, что программисты, напротив, очень часто хотят говорить о своей работе.
Для начала, хороший способ — поговорить о проектной документации. Начните работу. Прочтите имеющиеся документы. Если есть возможность, посмотрите исходный код.
Документация программистов может вводить в заблуждение. Спросите их о разделах, которые вам кажутся важными, но которые вы не понимаете. Иногда для вопросов можно использовать электронную почту, но личное общение более эффективно, особенно, если возникнут новые вопросы. Если они согласны на встречу, готовьтесь, не тратьте их время впустую.
Если у них нет документации, то попросите нарисовать картину, диаграмму системы. У большинства программистов есть образ системы, с которым они работают, они будут рады им поделиться.
Вы могли бы найти их диаграммы на доске. Одним из методов является указание на случайную стрелку и вопрос: «Что случится, если это не сработает?». Это может выявить отсутствие обработки ошибок и наличие необоснованных предположений. Вопросы, подобные этому, заданные двум или большему количеству программистов, могут выявить интересные различия.
Почему нужно задавать эти вопросы? Чтоб узнать больше о создаваемой системе, чтоб знать, каким образом она может ломаться, чтоб узнать предположения людей, создающих эту систему. Не будьте для них проверяющим или надсмотрщиком, если они узнают, что это так, то перестанут сотрудничать.
Когда вы получите ответы, напишите заметки и поделитесь ими с программистами или другими тестировщиками. Программисты не любят отвечать на одни и те же вопросы от разных тестировщиков.
Знание языка программирования поможет вам. Если они программируют на C++ или Java вы должны иметь о нх представление. Если ваше ПО многопоточное, вы должны иметь представление о потоках.
Активное слушание само по себе полезно для вас. В разговоры каждый вносит свой вклад идеями, опытом, остроумием. Когда вы слушаете, вы сосредоточены на том, чтоб помочь человеку сказать то, что он хочет сказать. Это включает себя переформулировку в понятные термины, наводящие вопросы, позволяющие получить дополнительную информацию из контекста и сделать выводы.
Ваша работа как тестировщика думать о том, как именно продукт может не работать. Но как член команды вы должны понимать, что продукт только создается. Пусть программисты знают, что вы понимаете ценность их работы.
Не говорите программистам, что они должны предоставить определенную документацию, прежде чем вы сделаете свою работу. Если она у них есть, спросите. Если вам все же нужна информация — спросите самого программиста. Объясните, почему вам это нужно и как поможет вашей работе. Они не могут читать ваши мысли. (См. Gause и Weinberg 1989, Chapter 6; Michalko 1991, Chapter 14).
вторник, 21 августа 2012 г.
Lesson 154
Вы, ваши сервисники проводите учения - кто и что делает, если навернутся все сервера?
Или все и без учений ясно, интуитивно?
Слово Канеру
Фокусируйся на работе, а не на человеке
Если ты видишь багу, сообщай о баге. Не сообщай, что программист Джо накосячил. Может, так и было, но если ты будешь говорить об этом, то подорвешь свою эффективность.
Многие опытные тестировщики используют свои наблюдения за слабостями коллег и самой организации для того, чтоб сфокусировать усилия по поиску багов. Они видят беспорядок и прогнозируют ошибки исходя из него. Ваш успех в подобной деятельности может склонить вас к тому, что вы захотите сообщить о таких проблемах напрямую. Неправильно!
Как только вы это сделаете, программисты прекратят обмениваться с вами информацией и принимать участие в совещаниях. Это сделает вас неэффективным, также вы станете частью проблемы.
Не стоит недооценивать способность руководства замечать проблемы. Проблемы с людьми проще заметить, чем исправить. Remember that you are not the manager of the manager who is (seemingly and maybe actually) ignoring a problem employee. Обращая внимание на возможную некомпетентность программиста, вы ограничиваете свою способность справиться с проблемой. Или вы могли бы заставить менеджеров столкнуться с некомпетентностью программиста, которую они пытались не замечать. По прежнему плохая игра.
Некоторые тестировщики идут так далеко, что думают, что это их работа — наказывать программистов за ошибки, нарушение сроков. Угадайте, что произойдет с такими тестировщиками? Они становятся одноразовыми. Некоторые уходят сразу. Другие находятся рядом, в качестве плохих полицейских, пока для очередного большого залета не понадобится козел отпущения.
Если вы видите полную картину проблемы, которая, как вы боитесь, не решается, в частном порядке предоставьте доказательства менеджеру, пусть он с этим справляется. Вы сделали свою работу (Pettichord 2001c).
Или все и без учений ясно, интуитивно?
Слово Канеру
Фокусируйся на работе, а не на человеке
Если ты видишь багу, сообщай о баге. Не сообщай, что программист Джо накосячил. Может, так и было, но если ты будешь говорить об этом, то подорвешь свою эффективность.
Многие опытные тестировщики используют свои наблюдения за слабостями коллег и самой организации для того, чтоб сфокусировать усилия по поиску багов. Они видят беспорядок и прогнозируют ошибки исходя из него. Ваш успех в подобной деятельности может склонить вас к тому, что вы захотите сообщить о таких проблемах напрямую. Неправильно!
Как только вы это сделаете, программисты прекратят обмениваться с вами информацией и принимать участие в совещаниях. Это сделает вас неэффективным, также вы станете частью проблемы.
Не стоит недооценивать способность руководства замечать проблемы. Проблемы с людьми проще заметить, чем исправить. Remember that you are not the manager of the manager who is (seemingly and maybe actually) ignoring a problem employee. Обращая внимание на возможную некомпетентность программиста, вы ограничиваете свою способность справиться с проблемой. Или вы могли бы заставить менеджеров столкнуться с некомпетентностью программиста, которую они пытались не замечать. По прежнему плохая игра.
Некоторые тестировщики идут так далеко, что думают, что это их работа — наказывать программистов за ошибки, нарушение сроков. Угадайте, что произойдет с такими тестировщиками? Они становятся одноразовыми. Некоторые уходят сразу. Другие находятся рядом, в качестве плохих полицейских, пока для очередного большого залета не понадобится козел отпущения.
Если вы видите полную картину проблемы, которая, как вы боитесь, не решается, в частном порядке предоставьте доказательства менеджеру, пусть он с этим справляется. Вы сделали свою работу (Pettichord 2001c).
суббота, 18 августа 2012 г.
Lesson 153
Таки ура. Благодаря hetzner, группе поддержки внутренней инфраструктуры, неведомой магии и такой то матери мы переехали в германию. Знаете, как у орков из вахи, техника работает потому, что орки верят, что она должна работать.
Теперь фуллтест проходит за 80 минут, супротив 120-210 на других серверах, люди, бившиеся за минуты поймут.
Слово Канеру
Ваша честность и компетентность потребуют уважения
Вы адвокат клиентов. В конечном счете, ваша работа — сообщать о проблемах, с которыми могут столкнуться пользователи. Программисты и менеджеры могут не признавать эти проблемы. Если так, то вы принесете им неприятное известие. Вас могут не любить за это. Но если вы найдете надежную проблему и сообщите о ней аккуратно и вовремя, то вызовете уважение. Когда сообщаете о проблеме
Говорите о ней внятно То есть описывайте дефект шаг за шагом, без ненужных действий. Точно опишите симптомы. Сделайте отчет так, чтоб ему было легко следовать и несложно понять. Ваша работа будет оценена, так как вы с уважением отнеслись ко времени программиста (как читателя вашего сообщения об ошибке и того, кто опирается на ваш отчет).
Основывайтесь на фактически наблюдаемом поведении продукта. Часто вы используете ПО больше, чем кто-либо другой. Это делает вас экспертом по внешнему поведению программы. Но вы не являетесь экспертом по ее внутренностям. Обсуждайте то, что видите и не тратьте времени на догадки о причинах проблемы.
Если сбой не воспроизводится, продемонстрируй задачу, которую ты выполнял, когда произошел сбой Когда ты отправляешь сообщение о невоспроизводимой ошибке, лучшим впечатлением будет то, что вы провели тщательное расследование, лучшими инструментами и предоставили полную информацию. Плохое впечатление — вы сдались и бросили работу при первой трудности. Демонстрируйте уважение к работе программиста.
Сообщайте плохие новости напрямую Не ходите через головы людей, пока вы не дали им возможность отреагировать. Скажите, что вы собираетесь эскалировать проблему прежде, чем вы это сделаете.
Не претендуйте на знание вещей, которых вы не знаете. К примеру, если вы не знаете серьезность проблемы, не притворяйтесь, что знаете. Либо получите доказательства (от технической поддержки или маркетологов) или молчите, или говорите только то, что знаете.
Не преувеличивайте сообщения об ошибке Не сводите их к минимуму, не запугивайте, не скрывайте то, что видели. Не бойтесь сообщить о проблеме, если она есть, эскалируйте, если это необходимо. Заработайте репутацию человека, прямого, как стрела, и вы заслужите уважение.
Если вы честны, вы заслужите уважение Если вы потеряли честь, компетентность не будет иметь значения.
Теперь фуллтест проходит за 80 минут, супротив 120-210 на других серверах, люди, бившиеся за минуты поймут.
Слово Канеру
Ваша честность и компетентность потребуют уважения
Вы адвокат клиентов. В конечном счете, ваша работа — сообщать о проблемах, с которыми могут столкнуться пользователи. Программисты и менеджеры могут не признавать эти проблемы. Если так, то вы принесете им неприятное известие. Вас могут не любить за это. Но если вы найдете надежную проблему и сообщите о ней аккуратно и вовремя, то вызовете уважение. Когда сообщаете о проблеме
Говорите о ней внятно То есть описывайте дефект шаг за шагом, без ненужных действий. Точно опишите симптомы. Сделайте отчет так, чтоб ему было легко следовать и несложно понять. Ваша работа будет оценена, так как вы с уважением отнеслись ко времени программиста (как читателя вашего сообщения об ошибке и того, кто опирается на ваш отчет).
Основывайтесь на фактически наблюдаемом поведении продукта. Часто вы используете ПО больше, чем кто-либо другой. Это делает вас экспертом по внешнему поведению программы. Но вы не являетесь экспертом по ее внутренностям. Обсуждайте то, что видите и не тратьте времени на догадки о причинах проблемы.
Если сбой не воспроизводится, продемонстрируй задачу, которую ты выполнял, когда произошел сбой Когда ты отправляешь сообщение о невоспроизводимой ошибке, лучшим впечатлением будет то, что вы провели тщательное расследование, лучшими инструментами и предоставили полную информацию. Плохое впечатление — вы сдались и бросили работу при первой трудности. Демонстрируйте уважение к работе программиста.
Сообщайте плохие новости напрямую Не ходите через головы людей, пока вы не дали им возможность отреагировать. Скажите, что вы собираетесь эскалировать проблему прежде, чем вы это сделаете.
Не претендуйте на знание вещей, которых вы не знаете. К примеру, если вы не знаете серьезность проблемы, не притворяйтесь, что знаете. Либо получите доказательства (от технической поддержки или маркетологов) или молчите, или говорите только то, что знаете.
Не преувеличивайте сообщения об ошибке Не сводите их к минимуму, не запугивайте, не скрывайте то, что видели. Не бойтесь сообщить о проблеме, если она есть, эскалируйте, если это необходимо. Заработайте репутацию человека, прямого, как стрела, и вы заслужите уважение.
Если вы честны, вы заслужите уважение Если вы потеряли честь, компетентность не будет иметь значения.
пятница, 17 августа 2012 г.
Lesson 152
Слово Канеру
Предоставляйте сервис
Напрямую предложите программистам помощь. Это создаст доверие и докажет, что вы тот, с кем можно сотрудничать. Вот некоторые услуги, которые вы могли бы предложить:
- Тестирование сторонних компонент. Предоставьте результаты тестирования программистам, чтоб они могли решить, как эти компоненты могут использоваться в продукте.
- Тестируйте из личные билды и прототипы
- Настройте тестовую среду для программистов, чтоб использовать ее в своих тестах.
Просматривайте требования на предмет их тестируемости. Программисты имеют дело с неоднозначными требованиями. Они могут быть рады вашему участию.
Все, что вы делаете, предоставляйте как услугу. В этих примерах все очевидно. Они помогут вам завоевать доверие и показать свою компетентность.
Предоставляйте сервис
Напрямую предложите программистам помощь. Это создаст доверие и докажет, что вы тот, с кем можно сотрудничать. Вот некоторые услуги, которые вы могли бы предложить:
- Тестирование сторонних компонент. Предоставьте результаты тестирования программистам, чтоб они могли решить, как эти компоненты могут использоваться в продукте.
- Тестируйте из личные билды и прототипы
- Настройте тестовую среду для программистов, чтоб использовать ее в своих тестах.
Просматривайте требования на предмет их тестируемости. Программисты имеют дело с неоднозначными требованиями. Они могут быть рады вашему участию.
Все, что вы делаете, предоставляйте как услугу. В этих примерах все очевидно. Они помогут вам завоевать доверие и показать свою компетентность.
Lesson 150
Эпиграф:
- Нам с тобой не о чем говорить. Вот ты достоевского читал?
- Да.
- А я нет. И о чем нам говорить?
Из последнего прочитанного:
Дайте им умереть. Олди. Самая слабая книга серии кабирского цикла.
Последний герой. Пратчетт. Норм.
Ключевые процессы тестирования. Рекс Блэк. Незачот, хотя сканает.
На очереди
Snuff Пратчетта, жду эпика.
Теория ограничений Голдратта, Максим cartmendum о ней столько говорил
Dexter by Design Линдсей, ня.
А еще мы заказали пару неплохих книжек, жаль, на мунспике, ну, буду переводить, чо. Или падаванов попрошу.
How to Break Web Software: Functional and Security Testing of Web Applications and Web Services. Виттакера
A Practitioner's Guide to Software Test Design
Слово Канеру
Поймите, как думают программисты
Все трое из нас начинали свою работу как программисты перед специализацией в тестировании. Мы по-прежнему пишем код. Наш опыт помогает понимать программистов, когда мы работаем в качестве тестировщиков — мы работаем с программистами.
Программисты и тестировщики работают в разных условиях. Мы играем разные роли, мы по-разному думаем о своей работе. Ты можешь быть более эффективным, если примешь во внимание некоторые различия в видении и подходах.
Лучший способ узнать, как общаться с программистами — стать одним из них и работать с ними в течении некоторого времени. Вернитесь к тестированию после того, как вы написали код продукта, после того, как вы критиковали, осуждали, хвалили тестировщиков, пользователей, менеджеров с другими программистами. Ничего, что мы смогли бы сказать в этой главе не даст вам того понимания, которое вы могли бы получить из такого опыта.
Обобщения в этой главе применимы к некоторым людям больше, чем к другим. Мы призываем вас узнать людей, с которыми вы работаете, а не полагаться на эти наблюдения. Тем не менее, вы моги бы найти некоторые из этих заметок полезными:
Большинство программистов специализируются. Программисты часто фокусируются на какой-то подсистеме или модуле, depending on often-sketchy information about the other system elements that their code must interact with. С другой стороны, вы часто знаете систему в целом. Чтоб тестировать, вы должны понимать, как система работает целиком. Вы могли бы предоставить информацию о всей системе программистам, с которыми работаете.
Программисты фокусируются на их модели системы У них есть представление о том, как компоненты системы связаны между собой, какие компоненты надежны, как появляются ошибки. Они работают с ментальной моделью. Когда они говорят, что ошибка, о которой вы сообщили, невозможна, они не говорят, что они не могут ошибиться. Они говорят, что такого рода ошибки не соответствуют их модели и тому, во что они верят. Вы должны сосредоточиться на наблюдении и сборе доказательств. Это позволит им проверить свои модели. Храните логи и отчеты, фокусируйтесь на том, что вы действительно видели, пусть они находят ошибки в своих рассуждениях.
программирование — сложная деятельность Программисты используют большую часть своей энергии, пытаясь понять систему, которую они создают. Концентрация требует оберегать программистов от информации , которая кажется вам важной. Также концентрация делает программистов нетерпимыми к прерываниям.
Программистам приходится бороться со сложными ситуациями. Они имеют дело с неоднозначными и меняющимися требованиями, бажными инструментами и технологиями, работой, полной прерываний.
Многие программисты не любят рутинную работу и создают инструменты по автоматизации рутинных задач, с которыми они сталкиваются. Многие считают тестирование повторяющейся задачей, а следовательно, подлежащей автоматизации. Они могут предполагать, что с вами что-то не так, если вы не автоматизируете тесты. Не покупайтесь на это. Не пытайтесь автоматизировать тесты, просто, чтоб изменить отношение программистов. Есть более эффективные способы. Ваша честность и компетентность сами потребуют уважения (Lesson 153).
Для дальнейшего обсуждения см. статью Pettichord's (2000b) "Testers and Developers Think Differently."
- Нам с тобой не о чем говорить. Вот ты достоевского читал?
- Да.
- А я нет. И о чем нам говорить?
Из последнего прочитанного:
Дайте им умереть. Олди. Самая слабая книга серии кабирского цикла.
![]() |
| Альбом: home |
Последний герой. Пратчетт. Норм.
![]() |
| Альбом: home |
Ключевые процессы тестирования. Рекс Блэк. Незачот, хотя сканает.
![]() |
| Альбом: home |
На очереди
Snuff Пратчетта, жду эпика.
![]() |
| Альбом: home |
Теория ограничений Голдратта, Максим cartmendum о ней столько говорил
![]() |
| Альбом: home |
Dexter by Design Линдсей, ня.
![]() |
| Альбом: home |
А еще мы заказали пару неплохих книжек, жаль, на мунспике, ну, буду переводить, чо. Или падаванов попрошу.
How to Break Web Software: Functional and Security Testing of Web Applications and Web Services. Виттакера
![]() |
| Альбом: home |
A Practitioner's Guide to Software Test Design
![]() |
| Альбом: home |
Слово Канеру
Поймите, как думают программисты
Все трое из нас начинали свою работу как программисты перед специализацией в тестировании. Мы по-прежнему пишем код. Наш опыт помогает понимать программистов, когда мы работаем в качестве тестировщиков — мы работаем с программистами.
Программисты и тестировщики работают в разных условиях. Мы играем разные роли, мы по-разному думаем о своей работе. Ты можешь быть более эффективным, если примешь во внимание некоторые различия в видении и подходах.
Лучший способ узнать, как общаться с программистами — стать одним из них и работать с ними в течении некоторого времени. Вернитесь к тестированию после того, как вы написали код продукта, после того, как вы критиковали, осуждали, хвалили тестировщиков, пользователей, менеджеров с другими программистами. Ничего, что мы смогли бы сказать в этой главе не даст вам того понимания, которое вы могли бы получить из такого опыта.
Обобщения в этой главе применимы к некоторым людям больше, чем к другим. Мы призываем вас узнать людей, с которыми вы работаете, а не полагаться на эти наблюдения. Тем не менее, вы моги бы найти некоторые из этих заметок полезными:
Большинство программистов специализируются. Программисты часто фокусируются на какой-то подсистеме или модуле, depending on often-sketchy information about the other system elements that their code must interact with. С другой стороны, вы часто знаете систему в целом. Чтоб тестировать, вы должны понимать, как система работает целиком. Вы могли бы предоставить информацию о всей системе программистам, с которыми работаете.
Программисты фокусируются на их модели системы У них есть представление о том, как компоненты системы связаны между собой, какие компоненты надежны, как появляются ошибки. Они работают с ментальной моделью. Когда они говорят, что ошибка, о которой вы сообщили, невозможна, они не говорят, что они не могут ошибиться. Они говорят, что такого рода ошибки не соответствуют их модели и тому, во что они верят. Вы должны сосредоточиться на наблюдении и сборе доказательств. Это позволит им проверить свои модели. Храните логи и отчеты, фокусируйтесь на том, что вы действительно видели, пусть они находят ошибки в своих рассуждениях.
программирование — сложная деятельность Программисты используют большую часть своей энергии, пытаясь понять систему, которую они создают. Концентрация требует оберегать программистов от информации , которая кажется вам важной. Также концентрация делает программистов нетерпимыми к прерываниям.
Программистам приходится бороться со сложными ситуациями. Они имеют дело с неоднозначными и меняющимися требованиями, бажными инструментами и технологиями, работой, полной прерываний.
Многие программисты не любят рутинную работу и создают инструменты по автоматизации рутинных задач, с которыми они сталкиваются. Многие считают тестирование повторяющейся задачей, а следовательно, подлежащей автоматизации. Они могут предполагать, что с вами что-то не так, если вы не автоматизируете тесты. Не покупайтесь на это. Не пытайтесь автоматизировать тесты, просто, чтоб изменить отношение программистов. Есть более эффективные способы. Ваша честность и компетентность сами потребуют уважения (Lesson 153).
Для дальнейшего обсуждения см. статью Pettichord's (2000b) "Testers and Developers Think Differently."
Подписаться на:
Сообщения (Atom)







