Рецензирование для тестов так же, как обзоры кода

Кто-нибудь практикует процесс «проверки кода» для функциональных тестов? Считаете ли вы это полезным? То, как мой нынешний работодатель практикует SCRUM, мы включаем функциональное тестирование как часть нашего «должно быть сделано» в любом заданном спринте.

Мы также практикуем SCRUM. И так же, как и вы, мы также включаем функциональное тестирование как часть нашего определения, как сделано.

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

Еще одна приятная вещь в обзоре кода: он дает вам еще один взгляд на реальную функциональность и на 100% уверен, что он соответствует желанию клиента / клиента. Было несколько раз, когда кто-то просматривал код и функциональность, куда человек пошел ... «Держись, это не правильно ...», и оказалось, что человек, реализующий код, просто что-то неправильно понял.

Боже мой, да (я стараюсь не использовать ругательства на SO; p). Независимая проверка ваших функциональных тестов - это в основном экспертная оценка ваших требований и анализа, это невероятно важно, и если вы используете язык BDD, такой как огурец, вы можете привлекать и не программистов!

Это замечательно, когда наши конечные пользователи обнаруживают проблемы с нашими функциональными тестами, и это заставляет их чувствовать себя неотъемлемой частью процесса разработки: «Я тоже могу читать код !!»

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

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

Проверка правильности тестов - это один аспект, то, что они достаточно полны и точны / репрезентативны, а также очень важны.

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

Вы можете сделать пару проверок!

Парные проверки:

Активное и неформальное рассмотрение документов в рамках цикла разработки и производства документов.

Причины, по которым это хорошо работает с тестированием, заключаются в том, что:

1. Вы можете часто проверять требования или документы несколькими глазами.
2. Вы можете привлечь больше, чем просто разработчиков: попробуйте BA с Test Lead, BA с PM, BA с Dev.
3. Вы можете назначить повторное лечение собраний как часть гибкого процесса. Убедитесь, что вы серьезно относитесь к этому с твердыми обязательствами членов команды.
4. Вы можете использовать эти парные проверки как часть упражнения по налаживанию связей и общения с заинтересованными сторонами. Начни разговор!

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

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