Начало здесь: Грабля №1: Программисты не любят внезапных прерываний.
Грабля №2: Программисты не любят «глупых» вопросов
Я пишу слово «глупых» в кавычках, потому что тут уместнее было бы написать «ленивых». Бывают ленивые вареники, но я не уверена правильно ли так говорить о вопросах. Но мы сейчас к этому подойдем.
Вы знаете, что такое меритократия? Если не знаете - не страшно. Большинство программистов тоже не знает, но они все без исключения этому следуют. Грубо и обобщенно говоря, это аристократия, основанная на способностях (некоторые меритократы могут захотеть меня опровернуть, но я не стану вступать в дисскуссию). Как и в любом профессиональном сообществе, авторитет и уважение в IT основаны не на должностях, - не на том, что вы тест-менеджер, а коллега – рядовой кодер, - а на интеллекте, знаниях, умениях. Умные люди не любят дураков и лентяев. Именно поэтому в IT терпеть не могут:
А) глупых, элементарных вопросов, ответ на которые вы легко можете найти сами
Где найти? А вот, например:
- в Интернете (любимый поисковик вам в помощь)
- в руководстве пользователя
- в книжке на полке у вас над головой
- у коллеги тестировщика
- в другом легкодоступном источнике
Если вы приходите к программисту спросить, что такое IP протокол, или чем открыть файл с расширением chm, или, боже упаси, говорите ему «зачем искать, ведь можно спросить тебя», вы тем самым демонстрируете, что
а) вы лентяй;
б) вы не уважаете своего коллегу, считая, что двадцать минут его времени (ответ вам + возврат в поток), значат меньше, чем две-три минуты ваших (набрать запрос в поисковике и открыть нужную страницу).
Б) необоснованного перекладывания на других решения трудоемкой задачи
«Мне нужно выбрать инструмент для автоматизации. Что ты посоветуешь?». Прежде чем такое делать подумайте, есть ли хоть одна причина у вашего коллеги бросать все свои дела и заниматься вашей проблемой, при том, что вы сами не удосужились сделать хоть что-то для ее решения?
Что делать? Очевидно, прежде чем задавать вопрос программисту, постараться найти ответ самостоятельно. Где - смотрим п. А. Если вы потратили на поиск больше 15-20 минут и ответа не нашли, тогда уже имеет смысл обращаться к разработчику. При этом вы подойдете не с пустым стеклянным взглядом, а скажете: «Петя, у меня вопрос: …. Я поискал там-то и там-то, а также сделал то и это, но ответа не нашел, может ты подскажешь?».
Приложив хотя бы минимум усилий для самостоятельного поиска решения, вы:
а) во многих случаях тут же найдете ответ и идти на поклон не понадобится;
б) покажете, что вы прикладываете усилия, а не ждете, пока вам поднесут решение на блюдечке.
Будьте также готовы к тому, что вы не получите прямого ответа, а получите ссылку, где об этом можно прочесть. Тогда пользуемся ссылкой и опять стараемся разобраться самостоятельно. Если не удалось и в этот раз, процедуру вопроса с описанием своих усилий повторяем.
Исключения: Существуют ситуации, когда правило незадавания «глупых» вопросов не работает. В таких случаях тестировщик не просто может, но обязан задавать вопросы, даже если они кажутся глупыми. Вот эти ситуации:
Исключение 1: Когда вы не знаете, как должна работать функция. Если вы испытываете хотя бы тень сомнения насчет ожидаемого поведения функции, никогда, ни при каких обстоятельствах не отвечайте сами себе на свой вопрос. Это чревато тем, что вы фичи примете за баги, а баги пропустите, считая их фичами.
Никто не усомнится, что падение ПО в момент запуска – это дефект. Но если функция поиска находит совпадения с учетом регистра, а без учета регистра не находит, - это ошибка или особенность работы? Спросите!
Исключение 2: Когда вы уже в процессе беседы. Если вы уже беседуете с программистом в реальном времени (устно или в чате) и у вас по ходу его объяснений возникают глупые, как вам кажется, вопросы - обязательно задайте их. Вы завладели его вниманием, так выжимайте из него всю информацию, пока есть возможность. Проясните все, что вам не ясно. Спрашивайте не стесняясь, в конце концов, вы же не можете бросить растревоженного коллегу посреди разговора, пойти погуглить, а затем вернуться, как ни в чем не бывало? Если же вы свои вопросы затаите и не сможете потом с ними разобраться, вам придется опять возвращаться к этой теме, отвлекаться самим, отвлекать программиста и повторять всю процедуру «допроса» заново.
Исключение 3: Когда затраты времени программиста намного меньше ваших.
Это касается не столько вопросов, сколько просьб. Допустим, вам нужно написать простенький запрос, чтобы каждый билд получать из БД список полей определенной таблицы. Но вы никогда еще не работали с SQL. Вы можете потратить несколько часов или дней и самостоятельно разобраться в SQL и в структуре вашей БД. Но в таких случаях лучше попросить о помощи программиста, курирующего БД, который настрочит вам этот запрос за пять минут.
Это исключение актуально в тех случаях, когда вам нужна помощь программиста для более эффективной организации тестирования. Писать заглушку функции самим или просить программиста? Неделю самим настраивать тестовый стенд под линукс или попросить о помощи программиста-линуксоида? Подумайте.
Почему тестировщик может претендовать на время программиста?
Потому что вы оба работаете в одном проекте и у вас общая цель - успешно сделать и сдать проект. Это часть нормальной командной работы. Программист помогает вам, когда это идет на пользу проекту и не наносит ущерба его работе. Например, настроить стенд или написать заглушку. Вы помогаете программисту, когда это идет на пользу проекту и не наносит ущерба вашей работе. Например, он приносит пересобранное приложение и просит проверить вне очереди, действительно ли он исправил дефект.
Продолжение следует...
Комментариев нет:
Отправить комментарий