суббота, 1 июня 2013 г.

Разработчики и тестирование



Говорить с разработчиками о тестировании - задача не из легких. Мне, как тестировщику, изначально приходится подстраиваться под них в разговоре. Ведь чтобы показать человеку обратную сторону медали, нужно изначально понять ход его мыслей и только после этого раскрывать свои идеи. Это сложно только изначально, со временем учишься переключаться быстрее.

Но так же не раз возникало много интересных ситуаций, когда разработчик осведомлен в разы лучше тестировщика о том, как и что, стоит тестировать. На своей практике я даже встречал разработчика, который учил тестировщика составлять отчет о дефекте (как оказалось, в прошлом этот разработчик был тестировщиком). Такие разработчики пишут код не так быстро, но намного качественней и время на доработку сведено к минимуму.

Большинство разработчиков думают в первую очередь о том, как быстрее закончить работу. Соответственно в их мире попусту нет времени на обдумывание всех негативных сценариев. Даже такие инженерные практики, как ATDD и TDD не всегда в этом помогают. Так как при подходе к разработке через первоначальное написание теста разработчик все равно будет думать о позитивном поведении системы в первую очередь и проверит лишь несколько негативных сценариев.

Тестировщики же думают иначе. Стиль мышления тестировщика указывает на то, что нельзя работать по шаблону. Везде нужно искать подводные камни - ведь "Everybody lies". Другими словами тестировщик думает о том, как поломать что-то сейчас, пока не сломал кто-то другой. Здесь очень подойдет график о цене дефекта.
Когда тестировщик говорит с разработчиком, между ними изначально существует конфликт. Хочу заметить - не возникает, а изначально существует, по причине открытой противоположности в стиле мышления. И с этим ничего не поделаешь. Нужно изначально принять тот факт, что тестировщик думает в сторону вопроса - "А что если?". Разработчики же стараются не думать о плохом и практически всегда идеализируют представлении о пользователях и продукте в целом.

Тестировщик в этом примере выступает неким катализатором и в литературном смысле спускает разработчика с небес, предоставляя реальные факты о работоспособности и жизнедеятельности системы.

В конфликте рождается истина и если научиться находить рациональное звено в обсуждениях - можно достичь невероятных результатов. Я постараюсь дать некоторые рекомендации для тестировщиков о том, как стоит общаться с программистами, чтобы эти дискуссии были более эффективными:

  • изначально стремитесь понять разработчика, а уже затем отстаивайте свою позицию;
  • если вам что-то не понятно честно скажите об этом и попросите объяснить;
  • не критикуйте работу разработчика, оперируйте фактами;
  • не позволяйте играть в ping-pong багами, требуйте четкого ответа.

Чтобы это взаимодействие было максимально продуктивным и успешным, тестировщики должны учиться работать с технологиями не хуже программистов. А программисты в свою очередь должны знать, по крайней мере, основы работы каждого тестировщика.