Насколько хорошо нужно тестировать фичи, которые ты делаешь?
Всем привет
Собирая статистические данные по работе отдела разработки и тестирования, стало понятно, что тестировщики в среднем тратят на проверку задач, которые делают разработчики в 2, а то и 3 раза больше времени, чем эту фичу делает сам разработчик.
К этому всему добавляется статистика, что всего порядка 20% всех задач закрывается с первого раза, остальные же переоткрываются с ошибками один, а то и несколько раз.
Поэтому появляется вопрос: насколько это "нормальная практика", и нужно ли заставлять разработчиков тщательнее тестировать свои задачи перед передачей в тестирование?
p.s. я понимаю, что время тестирования стоит гораздо дешевле, чем время разработки. Да и фиксить задачи просто, когда тебе говорят, где что упало. Но есть опасения, что в таком режиме работы появляется большая вероятность пропуска багов на продакшен.
sim3x, готов подписаться. Нормочас разработчика стоит выше нормочаса тестировщика, и количество времени, затрачиваемое на разработку, значительно выше количества времени, затрачиваемого на тестирование.
Таким образом, имеем два компонента из двух идентичных множителей. Простое произведение позволит понять, насколько они друг от друга отличаются. По факту - на порядки.
Поэтому ТС прав. Программирование стоит значительно дороже тестирования.
Конечно, есть и исключения. Неадекватные менеджеры, которых очень, очень много... и экзотические кейсы, которые берут да иногда попадаются. Но на то они и исключения - чтобы быть вне тренда.
Делается задача, составляются стандартные вопросы, что ты сделал, где это должно работать, как это должно работать, и что это могло сломать? Пробегаешься по этим пунктам, если все ок, отправляешь на тестирование. Обычно это занимает минут 10-20, за кружкой кофе.
Ну, по крайней мере не надо допускать такого, что дали задачу, написал код и даже не проверил. Основное правило - проверь что сделал.
Тут еще возникает вопрос: а какого фига тестировщики так долго тестируют? Либо программисты слишком быстро делают, либо тестировщики долгие.
Классная штука. РЕАЛЬНО экономит время в разработке. Реально быстрее разработка происходит. Раза в 2-3.
Единственный момент - это автоматизированное тестирование интерфейсов. Возможно, я ошибаюсь, но это не к TDD. Пытался подружиться с ним несколько раз, но в итоге пришел к общему выводу, что люди это делают лучше. Рацпредлы высказывают, о юзабилити воздыхают.
Тестировщики курят бамбук и тестируют только интерфейсы. Приходится им много платить, чтобы они ну хоть что-нибудь нашли.
В некоторых ситуациях - нет. Не экономит. Особенно, если это крупное приложение, где нужно продумывать интеграционные тесты.
К слову, вы предвзяты к тестировщикам. Они работают, реально работают. Мой знакомый тестировщик весь рабочий день пишет эти тесты, чтобы ничего не сломалось на проде. Фактически, весь функционал рабочего сайта описывает именно он. И кроме того, вся автоматизация, когда нужно покрыть не менее 98% кода тестами (это реальный кейс), сделать интеграционные и функциональные тесты, сделать так, чтобы это все работало на коммитах, чтобы перед сборкой все прогонялось на проде. Все это требует сил, времени и денег.
Хотите, чтобы работало без ошибок - платите тестировщику.
Сергей Попов, да. В некоторых ситуациях не то, чтобы не экономит, а просто на грани бессмысленности. Пример привел - тестирование пользовательского интерфейса. Хотя тестирование API будет обратным примером.
Нет, TDD здорово выручает и в на больших проектах. Если бы их несколько десятков за плечами не было (20 лет работаю в этой отрасли), я бы не спорил. Когда сроки от плановых 3-9 месяцев сокращаются до фактических 1-2 - это прув, знаете ли.
Я не предвзят к тестировщикам, потому что ничего против и не высказывал. Сленговые выражения про бамбук и прочие в моем сообщении можно понять так "автоматизированное тестирование уменьшает нагрузку на тестировщика, позволяя ему больше уделять внимания интерфейсам и юзабилити, а следовательно и качеству проекта, не заморачиваясь над работоспособностью функционала - который как раз тысячекратно автоматически тестируется на всем протяжении разработки".
Яков Е, да, это удивительно, но на практике с учетом времени на написание тестов разработка происходит в несколько раз быстрее. Чуть-чуть знаю, о чем говорю.
В некоторых проектах так и бывает, что на QA уходит в 3-5 раз больше времени, чем на разработку.
Потому что QA, кроме тестирования самой фичи, должны протестировать это в разных условиях, могут выполнять регрешен тестирование (не сломалось ли чего старое) и так далее.
Отсюда возникает вопрос автоматического тестирования, когда тестировщики руками тестируют совсем небольшую часть, но в основном заняты написанием и обновлением автоматических тестов.
Даёте разработчику базовый тест реализуемого в проекте функционала, без прохождения которого не принимаете на тестирование в отдел тестирования.
Задача отдела тестирования - отлавливать неявные ошибки, а не лень разработчиков.
Простые правила для любого нового функционала:
1. Реализованный новый функционал негативно не влияет на другие модули/блоки/узлы системы.
2. Система всегда защищена от "помех" со стороны пользователя: "кривые" руки пользователя с недопустимыми символами/значениями/командами.
3. Минимальный функционал работает корректно (т.е., например, калькулятор может работать без кнопки с какой-то любой цифрой, но не может работать без операций над значениями).
4. Рабочий процесс (work-flow) с заранее заданными значениями проходит корректно.
5. Отсутствуют явные визуальные ошибки отображения информации и/или визуальных элементов интерфейса на протяжении всего рабочего процесса.
Если все пункты выполняются - можно передавать в отдел тестирования, где они сделают покрывающее тестирование с различными входными/ожидаемыми данными/значениями и отловят неявные ошибки.
Средний
