Автоматическое тестирование: способы помочь и обучить разработчиков?

Question

Я инженер по тестированию программного обеспечения, встроенный в команду разработчиков. Большая часть моей работы связана с проверкой состояния автоматизированных тестов проекта (главным образом, тестов на единицу/интеграцию).

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

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

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

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

Я не исправить их код и тесты для них, но я добавлю больше тестовых примеров и т. Д., Если я обнаруживаю пробелы. Причина, по которой я решил не исправить тесты для них, - это то, что разработчикам слишком легко сказать «спасибо», но настроить. Мое рассуждение состоит в том, что, если они должны решить проблемы, которые я определил до того, как я подпишусь, это приведет к лучшему стандарту тестирования проекта (т. Е. Более самодостаточному тестированию разработчиков).

Мой вопрос: когда дело доходит до оказания помощи команде, могу ли я сделать что-нибудь лучше? Какие подходы вы нашли, что может быть полезно?

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

* edit: Спасибо за ответы; все они содержали полезные предложения. Я считаю, что лучший из них является лучшим ответом, так как я думаю, что это сводится к поддержке разработчиков, а парное программирование - это то, что я еще не пробовал (не так много импровизированных «вот как я сделал бы это» демонстрации после того, как тесты были написано). Я дам, что пойдем с кем-нибудь, кто борется с тестированием чего-то :) Привет.

Answer 1

Если у вас есть определенные люди, которые склонны быть слабыми при тестировании, то садитесь с ними, программируйте пар, и когда они работают над своим кодом, вы можете помочь им увидеть, как они могут его протестировать.

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

Другое дело, что каждый должен смотреть на тесты. Если я коснусь функции, внесите какие-либо изменения, тогда я должен проверить тесты, чтобы убедиться, что они полны. Если есть проблема, я могу обсудить ее с разработчиком.

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

Answer 2

Несколько вещей, которые я хотел бы сделать:

1. Получить их запустить покрытие и определить любые пропущенные участки кода и подчеркнуть, как хотя они думают, что они получили все случаи охвачены, они не могли бы иметь. Я сделал это с несколькими людьми, и они всегда кажутся довольно удивленными областями, которые они пропустили, когда они думали, что они написали водонепроницаемые тесты.
2. Начните «рецепт» на своей локальной вики. Каждый раз, когда кто-то придумывает сценарий тестирования, который они не могут понять, или вам нужна ваша помощь, вставьте его в Wiki и упростите его поиск. Попросите других людей также внести свой вклад
3. Похоже, вы все равно это делаете, но убедитесь, что у кого-то есть вопросы, связанные с тестированием, сделайте себе доступным, даже если это в ущерб вашей обычной рабочей нагрузке. Если вы увлечены этим, это должно вдохновлять тех, кто заинтересован в том, чтобы делать правильные вещи.

Когда я представляю кого-то для тестирования (или новой методики тестирования), я часто трачу много времени, случайно блуждая по их рабочей станции, чтобы увидеть, как они набираются и подталкивают их в правильном направлении. Это может быть прекрасно подобрано при переходе на чай/дым или когда вы делаете сборку. У меня были хорошие отзывы об этом, но YMMV.

Answer 3

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

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

Не то, чтобы у меня была такая же позиция, но как кто-то, кто был разработчиком на некоторое время, это именно то, что я хотел бы видеть, чтобы помочь сделать тестирование хорошим, как сказала Марта Стюарт ,

Answer 4

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

Этот подход также может быть выполнен, когда код изменяется внутренне (без публичных изменений API). - Записывайте тесты, чтобы охватить измененную область, чтобы убедиться, что она не сломается при изменении кода. Написание тестов таким образом намного меньше работы и наглядно демонстрирует преимущества, когда разработчик ловит свою первую ошибку регрессии.