четверг, 14 июня 2012 г.

Тестировщики Vs Программисты: Конфликт или взаимодействие?



По приглашению организаторов online конференции -  IT Brunch, подготовил интересный доклад на вечную тему конфликта между тестировщиками и программистами. Так как тема конференции была "Учимся на чужих ошибках", я отобрал 7 самых интересных ошибок, которые допустил в командной разработке ПО.

Ниже можно посмотреть слайды и послушать сам доклад.
 

Ответы на вопросы: 
Как бороться с проблемой когда "ты QA - тебе и надо". PM так же относится. Такие проблемы обычно и заваливали проект. PS я QA :)
Нужно начинать с малого. Напишите один тест, установите Continuous Integration сервер, запускайте UI тесты на нем. Покажите команде, что от этого есть толк. Поговорить с программистами и попросите их подключить несколько unit-тестов, автоматизировать сборку продукта. Основная цель - добиться рабочего Continuous Integration процесса!
Кто занимается созданием подобных полиси и кто принимает решения о их принятии?
Не старайтесь загонять людей в рамки полиси. На уровне компании хорошо. Но на самом низком уровне работы, дайте людям самим организовать свой процесс. Он не может быть под копирку. Люди - не роботы.
Я правильно поняла, что: нельзя оплачивать овертаймы - это расслабляет и демотивирует команду
Я бы не сказал, что нельзя. Лучше не допускать ситуацию на проекте к тому, чтобы были овертаймы!
Можно конкретный пример по поводу какого таска тестировщик мог знать что это 8 стори поинтов а не 3 - на моей практике не приходилось встречать ситуацию где тестировщик настолько может "шарить" в объёме тасков по имплементации
Я попытался обширно ответить на этот вопрос в записи. Если у вас еще остались уточняющие вопросы, свяжитесь со мной!
Автоматизация тестирования: для таких задач скорее должны быть тестировщики, специализирующиеся на автоматизации - программисту обычно этим неохота заниматься и давать ему такие таски не оптимально. У вас другой опыт?
Я с этого начинал. Скажу по правде, изначально не видишь проблем. Есть тесты, ты их автоматизируешь. Но спустя время понимаешь, что занимаешься только тем, что исправляешь эти тесты. И времени на тестирование и написание новые катастрофически не хватает. Более рационально поручить автоматизацию на всю команду и научить тестировщиков и программистов взаимодействовать друг с другом для достижения максимального тестового покрытия.
После разъассайнивания обязанностей руководством высшего звена,в отдел тестирования назначили-QA Team Lead Deputy, до этого был назначен Team Lead Deputy программистов,которому новый QA не нравится. Размер палок в колеса растет.Как исправить ситуацию? Спасибо
На мой взгляд в команде не должно быть должности QA Team Lead, тогда тестировщики и  начинают конфликтовать с разработчиками. Пытайтесь избегать Quality Police Mentality. Сделайте одну команду разработки, в которой будут несколько тестировщиков, не делайте тестировщиков отдельной командой. В команде могут быть крутые и некрутые тестировщики и в зависимости от скилов они выполняют разные задачи. Так же практикуйте парное и exploratory тестирование, чтобы делиться опытом.
У нас программисты УПОРНО не хотят запускать код который пишут.Упорно не хотят писать юниттесты. Причина - Вы тестировщики, вам за тестирование платят. Как изменить ситуацию? что посоветуете?
Оговорите с программистами критерии приемки задач на тестирование. Опишите это в Definition of Done. Но перед этим конечно же нужно, чтобы они поняли зачем все это. Для этого нужно посчитать сколько времени уходит у тестировщика на то, чтобы проверить задачу и вернуть ее обратно программисту на доработку. В итоге получится, что дешевле программисту перепроверить позитивный сценарий, что задача работает, нежели потом 10 раз вносить изменения.
Если разработчики будут заниматься ручным тестированием фич друг друга это может увеличить стоимость разработки и замедлить саму разработку
 Верно подметили, я переслушал запись и словил себя на том, что не до конца донес мысль. Просить программистов тестировать нужно только тогда, когда с тестированием завал и тестировщики не успевают протестировать задачи. Очень хороший индикатор завала это "Limiting Work in Poregress" в теории Lean Development.
Бывают ли у Вас ситуации что один и тотже баг появляется через билд? Что посоветуете чтобы защититься от таких проблем?
Бывают и очень часто. Напишите тест, который будет находить этот баг и запускайте на ряду с остальными тестами.
Автоматизация и программисты + аджайл = не согласен! 
Ваше право. Но помните, unit тесты тоже автоматизация, точно так же как и UI тесты.
Что делать, если программисты даже пишут тесты, но совершенно игнорируют результаты прогонов? Ошибки копятся и копятся..
Нужна договоренность внутри команды. Мы решили это при помощи магической копилки!
Как отслеживаете кто профейлил?
Современные системы сборок могу показать после чьего комита упали тесты. Вся команда получит письмо с указанием виновника.