Тестирование кода прежде, чем выпустить к QA

Разработчик тестирует свой код, чтобы убедиться, что код работает так, как задумал разработчик.

Команда QA тестирует код, чтобы убедиться, что код работает так, как, по мнению группы QA, они читают в документации.

Команда QA не просто тестирует код. Команда QA проверяет эффективность коммуникации между заинтересованными сторонами (клиентами, разработчиками, QA, руководством и т. Д.).

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

re: «Я слышал, как разработчики говорили, что люди, которые пишут код, не должны его тестировать. "

Если они не проверят это, как они узнают, работает он или нет? Настоящий ответ таков: «люди, которые пишут код, не должны быть только теми, кто его тестирует». Это правда, что у нас, как у разработчиков, есть белые пятна в отношении нашего собственного кода («Я знаю, что не касался того кода, поэтому не нужно его тестировать ...») и нам нужна помощь.

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

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

Да, QA, вероятно, все еще найдет дефекты. Их работа - придумывать и тестировать ситуации, которые вы в конце концов не рассматривали. В общем, я не думаю, что было бы вероятно и, конечно, необычно, чтобы код проходил напрямую через QA без проблем на первой итерации (за исключением исправлений ошибок и очень незначительных изменений).

1) Да, вам как разработчику нужно писать множество модульных тестов. Это поможет вам выявлять ошибки на более ранних этапах цикла, прежде чем передавать их вашей команде QA.

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

Разработчик должен ВСЕГДА тестировать свой код, чтобы убедиться, что он работает так, как он ожидает.

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

Интересный вопрос. Я постараюсь дать вам хороший обзор с точки зрения тестировщиков.

Если я получу сборку, я буду ожидать, что код будет протестирован на уровне модульного тестирования, чтобы проверить некоторые основы. Это означает, что когда я ввожу некоторые базовые проверки граничных значений, он не падает. Например: если поле принимает значения от 0 до 100, оно должно корректно обрабатывать 101 и -1.

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

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

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

Здесь был оставлен один комментарий, что спецификации могут быть расплывчатыми и, следовательно, сложными для написания тестов.Но как тестировщик я бы также предположил, что это тоже не усложняет кодирование?

По моему опыту, для написания модульных тестов стоит объединить разработчика и тестировщика. Это потрясающее зрелище, и широта охвата зачастую превосходна.

Ура Роб ..