How well do you need to test the features you make?

Question

Web development

Всем привет
Собирая статистические данные по работе отдела разработки и тестирования, стало понятно, что тестировщики в среднем тратят на проверку задач, которые делают разработчики в 2, а то и 3 раза больше времени, чем эту фичу делает сам разработчик.
К этому всему добавляется статистика, что всего порядка 20% всех задач закрывается с первого раза, остальные же переоткрываются с ошибками один, а то и несколько раз.
Поэтому появляется вопрос: насколько это "нормальная практика", и нужно ли заставлять разработчиков тщательнее тестировать свои задачи перед передачей в тестирование?
p.s. я понимаю, что время тестирования стоит гораздо дешевле, чем время разработки. Да и фиксить задачи просто, когда тебе говорят, где что упало. Но есть опасения, что в таком режиме работы появляется большая вероятность пропуска багов на продакшен.

Answer 1

Делается задача, составляются стандартные вопросы, что ты сделал, где это должно работать, как это должно работать, и что это могло сломать? Пробегаешься по этим пунктам, если все ок, отправляешь на тестирование. Обычно это занимает минут 10-20, за кружкой кофе.
Ну, по крайней мере не надо допускать такого, что дали задачу, написал код и даже не проверил. Основное правило - проверь что сделал.
Тут еще возникает вопрос: а какого фига тестировщики так долго тестируют? Либо программисты слишком быстро делают, либо тестировщики долгие.

Answer 2

Приходит задача
Тестировщик пишет приемочный тест
Разраб пулит его и пишет по нему юнит тест
Итерактивно пилятся тесты и функционал
Когда функционал готов - он проходит тесты
После, тестировщику требуется находить заквыристые баги

Answer 3

Знакомы с TDD?
Классная штука. РЕАЛЬНО экономит время в разработке. Реально быстрее разработка происходит. Раза в 2-3.
Единственный момент - это автоматизированное тестирование интерфейсов. Возможно, я ошибаюсь, но это не к TDD. Пытался подружиться с ним несколько раз, но в итоге пришел к общему выводу, что люди это делают лучше. Рацпредлы высказывают, о юзабилити воздыхают.
Тестировщики курят бамбук и тестируют только интерфейсы. Приходится им много платить, чтобы они ну хоть что-нибудь нашли.

Answer 4

Зависит от проекта.
В некоторых проектах так и бывает, что на QA уходит в 3-5 раз больше времени, чем на разработку.
Потому что QA, кроме тестирования самой фичи, должны протестировать это в разных условиях, могут выполнять регрешен тестирование (не сломалось ли чего старое) и так далее.
Отсюда возникает вопрос автоматического тестирования, когда тестировщики руками тестируют совсем небольшую часть, но в основном заняты написанием и обновлением автоматических тестов.

Answer 5

На то оно и фичи, чтоб быть необычными, а следствие надо тестировать чтоб подогнать там, где юзеры его будут пользовать

Answer 6

Даёте разработчику базовый тест реализуемого в проекте функционала, без прохождения которого не принимаете на тестирование в отдел тестирования.
Простые правила для любого нового функционала:
1. Реализованный новый функционал негативно не влияет на другие модули/блоки/узлы системы.
2. Система всегда защищена от "помех" со стороны пользователя: "кривые" руки пользователя с недопустимыми символами/значениями/командами.
3. Минимальный функционал работает корректно (т.е., например, калькулятор может работать без кнопки с какой-то любой цифрой, но не может работать без операций над значениями).
4. Рабочий процесс (work-flow) с заранее заданными значениями проходит корректно.
5. Отсутствуют явные визуальные ошибки отображения информации и/или визуальных элементов интерфейса на протяжении всего рабочего процесса.
Если все пункты выполняются - можно передавать в отдел тестирования, где они сделают покрывающее тестирование с различными входными/ожидаемыми данными/значениями и отловят неявные ошибки.