Тестирование вашего кода перед выпуском в QA - PullRequest
9 голосов
/ 16 июня 2010

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

Есть ли у кого-нибудь на этой доске процесс, который позволит им полностью протестировать свой код перед выпуском в QA?

Ответы [ 10 ]

20 голосов
/ 16 июня 2010

Разработчики обычно работают изнутри наружу, с акцентом на код:

  • Утверждения - проверка потока данных и структур
  • Отладчик - проверка потока кода и данных
  • Статический анализатор - проверить стандарты кодирования и найти известные ошибки
  • Модульное тестирование - проверка каждой функции
  • Интеграционное тестирование - проверка подсистем
  • Проверка системы - проверка работоспособности
  • Регрессионные тесты - проверка исправности дефектов
  • Тесты безопасности - убедитесь, что в систему нелегко проникнуть.

Тестеры, с другой стороны, обычно работают снаружи внутрь, с акцентом на функции:

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

Конечные пользователи обычно работают извне довольно случайным образом:

  • Приемочные испытания - проверка требований конечного пользователя
  • Сценарные тесты - проверка реальных ситуаций
  • Юзабилити-тесты - убедитесь, что система проста в использовании
  • В поисках причуд и неровностей.
5 голосов
/ 16 июня 2010

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

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

3 голосов
/ 23 июня 2010

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

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

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

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

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

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

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

Cheers Rob ..

2 голосов
/ 16 июня 2010

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

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

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

2 голосов
/ 16 июня 2010

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

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

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

2 голосов
/ 16 июня 2010

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

1 голос
/ 22 октября 2010

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

Перед началом фактического программирования:

  • Создание начальных контрольных примеров
  • Оцените, что может сломаться

при кодировании:

  • Автозаполнение имен символов
  • Выделите имена символов, чтобы убедиться, что они совпадают
  • Печатайте спокойно, чтобы избежать опечаток
  • Код небольших сумм за раз
  • Спроси своих сверстников
  • заниматься парным программированием
  • Запишите больше тестовых случаев
  • Оцените дальше, что может сломаться
  • Используйте хороший OOD и чистый код
  • Понять код
  • Оставьте код на некоторое время (дней) и вернитесь, чтобы просмотреть его
  • Запустите diff для постоянных данных, чтобы убедиться в их правильном изменении
  • Проверка синтаксиса для проверки ошибок
  • Проверка синтаксиса, чтобы избежать злоупотреблений и обеспечить соблюдение стандарта кодирования
  • Юнит-тесты
  • Автоматические функциональные тесты
  • Ручные функциональные тесты
  • Проверка выходных данных

Перед совершением:

  • Обновить рабочую копию и запустить все тесты и проверки
  • Запуск отладчика
  • Проверка орфографии
  • Сравнение различий, что изменилось
  • экспертная оценка
  • Оцените, что может сломаться

Сервер интеграции

  • Синтаксические контролеры
  • Автоматические тесты и проверки
  • Испытание на дымность
  • Уведомление о рецензировании

Выпуск в QA:

  • Проведение испытаний в зоне подготовки
  • Подтвердить вывод
  • Уведомить QA о завершении задания и отправить оценки поломки

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

1 голос
/ 16 июня 2010

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

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

1 голос
/ 16 июня 2010

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

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

0 голосов
/ 13 мая 2013

Как разработчик, вы можете протестировать свой код до некоторой степени, например:

  • Модульное тестирование, когда модули полностью собраны.
  • Интеграция Тестирование после интеграции двух или более модулей.

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

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

...