Lesson 155
Ну, или как-то так - шесть правил Глеба Жеглова:
Слово Канеру
Программисты любят говорить о своей работе. Задавайте им вопросы.
Многие тестировщики говорят, что у них проблемы с получением информации от программистов. Мы же находим, что программисты, напротив, очень часто хотят говорить о своей работе.
Для начала, хороший способ - поговорить о проектной документации. Начните работу. Прочтите имеющиеся документы. Если есть возможность, посмотрите исходный код.
Документация программистов может вводить в заблуждение. Спросите их о разделах, которые вам кажутся важными, но которые вы не понимаете. Иногда для вопросов можно использовать электронную почту, но личное общение более эффективно, особенно, если возникнут новые вопросы. Если они согласны на встречу, готовьтесь, не тратьте их время впустую.
Если у них нет документации, то попросите нарисовать картину, диаграмму системы. У большинства программистов есть образ системы, с которым они работают, они будут рады им поделиться.
Вы могли бы найти их диаграммы на доске. Одним из методов является указание на случайную стрелку и вопрос: «Что случится, если это не сработает?». Это может выявить отсутствие обработки ошибок и наличие необоснованных предположений. Вопросы, подобные этому, заданные двум или большему количеству программистов, могут выявить интересные различия.
Почему нужно задавать эти вопросы? Чтоб узнать больше о создаваемой системе, чтоб знать, каким образом она может ломаться, чтоб узнать предположения людей, создающих эту систему. Не будьте для них проверяющим или надсмотрщиком, если они узнают, что это так, то перестанут сотрудничать.
Когда вы получите ответы, напишите заметки и поделитесь ими с программистами или другими тестировщиками. Программисты не любят отвечать на одни и те же вопросы от разных тестировщиков.
Знание языка программирования поможет вам. Если они программируют на C++ или Java вы должны иметь о нх представление. Если ваше ПО многопоточное, вы должны иметь представление о потоках.
Активное слушание само по себе полезно для вас. В разговоры каждый вносит свой вклад идеями, опытом, остроумием. Когда вы слушаете, вы сосредоточены на том, чтоб помочь человеку сказать то, что он хочет сказать. Это включает себя переформулировку в понятные термины, наводящие вопросы, позволяющие получить дополнительную информацию из контекста и сделать выводы.
Ваша работа как тестировщика думать о том, как именно продукт может не работать. Но как член команды вы должны понимать, что продукт только создается. Пусть программисты знают, что вы понимаете ценность их работы.
Не говорите программистам, что они должны предоставить определенную документацию, прежде чем вы сделаете свою работу. Если она у них есть, спросите. Если вам все же нужна информация - спросите самого программиста. Объясните, почему вам это нужно и как поможет вашей работе. Они не могут читать ваши мысли. (См. Gause и Weinberg 1989, Chapter 6; Michalko 1991, Chapter 14).
Click to viewСлово Канеру
Программисты любят говорить о своей работе. Задавайте им вопросы.
Многие тестировщики говорят, что у них проблемы с получением информации от программистов. Мы же находим, что программисты, напротив, очень часто хотят говорить о своей работе.
Для начала, хороший способ - поговорить о проектной документации. Начните работу. Прочтите имеющиеся документы. Если есть возможность, посмотрите исходный код.
Документация программистов может вводить в заблуждение. Спросите их о разделах, которые вам кажутся важными, но которые вы не понимаете. Иногда для вопросов можно использовать электронную почту, но личное общение более эффективно, особенно, если возникнут новые вопросы. Если они согласны на встречу, готовьтесь, не тратьте их время впустую.
Если у них нет документации, то попросите нарисовать картину, диаграмму системы. У большинства программистов есть образ системы, с которым они работают, они будут рады им поделиться.
Вы могли бы найти их диаграммы на доске. Одним из методов является указание на случайную стрелку и вопрос: «Что случится, если это не сработает?». Это может выявить отсутствие обработки ошибок и наличие необоснованных предположений. Вопросы, подобные этому, заданные двум или большему количеству программистов, могут выявить интересные различия.
Почему нужно задавать эти вопросы? Чтоб узнать больше о создаваемой системе, чтоб знать, каким образом она может ломаться, чтоб узнать предположения людей, создающих эту систему. Не будьте для них проверяющим или надсмотрщиком, если они узнают, что это так, то перестанут сотрудничать.
Когда вы получите ответы, напишите заметки и поделитесь ими с программистами или другими тестировщиками. Программисты не любят отвечать на одни и те же вопросы от разных тестировщиков.
Знание языка программирования поможет вам. Если они программируют на C++ или Java вы должны иметь о нх представление. Если ваше ПО многопоточное, вы должны иметь представление о потоках.
Активное слушание само по себе полезно для вас. В разговоры каждый вносит свой вклад идеями, опытом, остроумием. Когда вы слушаете, вы сосредоточены на том, чтоб помочь человеку сказать то, что он хочет сказать. Это включает себя переформулировку в понятные термины, наводящие вопросы, позволяющие получить дополнительную информацию из контекста и сделать выводы.
Ваша работа как тестировщика думать о том, как именно продукт может не работать. Но как член команды вы должны понимать, что продукт только создается. Пусть программисты знают, что вы понимаете ценность их работы.
Не говорите программистам, что они должны предоставить определенную документацию, прежде чем вы сделаете свою работу. Если она у них есть, спросите. Если вам все же нужна информация - спросите самого программиста. Объясните, почему вам это нужно и как поможет вашей работе. Они не могут читать ваши мысли. (См. Gause и Weinberg 1989, Chapter 6; Michalko 1991, Chapter 14).