Хотелось бы услышать мнения по вопросы вынесенному в заголовок. Понятно, что должны, но тестирование может быть "только пройтись по основным сценариям" или провести полномаштабное тестирование с элементами творческого поиска. Про unit- тесты, я конечно знаю, но во первых они тоже не панацея, есть ситуации которые имим не отловишь, во-вторых написать качественные unit-тесты тоже не каждый сразу сможет и в третьих — существует проект с малым покрытием и быстро исправить ситуацию нереально.
Спасибо за ответы

Здравствуйте, vladpol, Вы писали:

V>Хотелось бы услышать мнения по вопросы вынесенному в заголовок. Понятно, что должны, но тестирование может быть "только пройтись по основным сценариям" или провести полномаштабное тестирование с элементами творческого поиска. Про unit- тесты, я конечно знаю, но во первых они тоже не панацея, есть ситуации которые имим не отловишь, во-вторых написать качественные unit-тесты тоже не каждый сразу сможет и в третьих — существует проект с малым покрытием и быстро исправить ситуацию нереально.
V>Спасибо за ответы

Если говорить о классических видах тестирования (unit, integration, system, acceptance/field),
то программисты должны заниматься unit и integration тестированием.
Критерии полномасшабности можно осознанно задавать.
Ну например смотреть на code coverage.
Другими виды тестирования лучше отдать на откуп профи.
В общем все зависит от принятых процессов, того как работает/хочет работать компания,
насколько важно качество и сколько усилий на качество готовы инвестировать.
Однозначного ответа на твой вопрос не существует...

Здравствуйте, vladpol, Вы писали:

unit-тесты, покрытие, основные сценарии... Это все понятно.
А давайте попробуем посмотреть на этот вопрос, немного с другой стороны. Посмотрим на него как на оптимизационную задачу.
Для начала я не знаю, что вы хотите оптимизировать, поэтому я буду, для примера, оптимизировать общее время на разработку + тестирование. Подход можно переиначить для оптимизации стоимости, если захочется.

Итак, рассмотрим одну фичу.
На ее тестирование тестировщикам нужно время T, а разработчикам v*T. Тут v определяется фичей и может быть как больше 1, так и меньше.
В фиче содержится B багов. Из них тестировщики находят всё, а разработчики только q*B багов.
Для простоты, будем считать, что количество найденных багов зависит от времени тестирования линейно.
Пусть тестировщики тестируют обязательно всю фичу целиком. То есть тратят на это время T.
Пусть разработчики тестируют ее только на 100*e%. То есть в течение времени e*v*T. Собственно исходный вопрос был в том, чему должно быть равно e.
Пусть при нахождении бага разработчику требуется Tfix времени на ее исправление.
Пусть при нахождении бага тестировщиком, ему требуется Tregister времени на его локализацию, перепроверку и регистрацию в баг-треккере.
Пусть разработчику после этого требуется Tswitch времени на то, чтобы разобраться в баг-репорте, переключить контекст своей деятельности, вспомнить, что он вообще там писал, и т.п.

Кажется теперь можно написать выражение, которое мы хотим минимизировать:

[ T + (1 — e*q)*B*(Tregister) ] + [ e*v*T + q*B*Tfix + (1 — e*q)*B*Tswitch ] = T(e)

Тут первая скобка — это время тестировщиков. Вторая скобка — время разработчиков.
Если вынести e за скобку, то мы получим линейную форму:

e * [ v*T — q*B*(Tregister + Tswitch) ] + T + B*(Tregister + Tfix + Tswitch) = T(e)

Это линейная форма, поэтому минимум у нее может быть только на краях области значений e. Либо при e=0, либо при e=1. То есть разработчики должны тестировать либо всю фичу целиком и полностью, либо вообще ничего не тестировать.

Посмотрим на коэффициент перед e. Если он положительный, то тестировать разработчики ничего не должны. Когда он положительный?
Положительный он тогда, когда время, потраченное на тестирование разработчиками заведомо больше, чем оверхэд на то, что этот баг найдут тестировщики неделей позже.

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

Если же проверить просто, и фича какая-то сложная — нужно проверять обязательно. И полностью!

Вот такой результат. А теперь дисклаймер.

Видно, что эта модель много чего не учитывает. Например то, что разработчики с тестировщиками работают параллельно. Поэтому их время вообще говоря нужно не суммировать, а хотя бы брать максимум (это тоже не точное приближение).
Она использует параметры v, q, B, которые сложно рассчитать или померять. Она предполагает, что оттестированность от времени тестирования — функция линейная (какая она на самом деле — черт разберешь). Она не учитывает, что баги бывают критичные, а бывают некритичные. И что тестировщики в первую очередь пытаются находить критичные баги. И то, что деятельность тестировщиков могут в любой момент прервать со словами "хватит тестировать! достаточно!" она тоже не учитывает.

Но! Если есть желание, то эту модель можно доработать под вашу конкретную ситуацию, вложив в нее все эффекты, которые имеют место быть в вашей команде. Пусть вы не получите количественные результаты из-за неизвестных параметров, но вы получите качественный результат, который можно интерпретировать на бытовом уровне и донести его до тех же разработчиков.

Всем удачи!

Здравствуйте, vladpol, Вы писали:

V>Хотелось бы услышать мнения по вопросы вынесенному в заголовок. Понятно, что должны, но тестирование может быть "только пройтись по основным сценариям" или провести полномаштабное тестирование с элементами творческого поиска.

Вопрос — слишком индивидуален, поэтому в каждом случае в силу разных исторических причин сложившийся процесс тестирования может быть разный, но во всех случаях вполне правильный. Так что тестировать надо так, как в конкретной компании/коллективе тестируют заслуженные программисты. В моем конкретном случае лучше всего работает проход в отладчике (если есть возможность отладки) каждой строчки своего нового C++ кода. В случае изменения существующего кода — объем отладки по опыту, опыт ведь не пропьешь.

Теоретически, программист (а также его коллеги во время code review) могут выявить множество багов, причем таких, которые, судя по опубликованной статистике, тестеры никогда не найдут. Теоретически это будет стоить дешевле, чем перекладывать работу на обычных тестеров. Особенно если программисты — российские, а тестеры — американские. Поэтому по идее надо программистов заставлять долго-долго и нудно-нудно тестировать свой код. К тому же зачастую это по душе хорошим программистам, которые под предлогом «тестирования» будут “улучшать” свой код.

Но в реальной жизни все бывает по-другому.

Например, тестировать могут многие, а программист – он один такой, который в предметной области и в существующем коде разбирается. А дедлайн неумолимо приближается.

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

Стоимость тестирования программистом может быть разная. Например, в моем случае, выдавать каждому программисту для тестирования 20 разных моделей промышленных спутниковых приемников и 10 роботизированных теодолитов суммарной стоимостью на 1 миллион баксов — нерентабельно. Кроме того, программист будет никак не меньше месяца перетестировать каждое свое изменение на 10-ке платформ * 50 вариантов оборудования. В некоторых случаях тесты надо проводить на открытом воздухе. И все равно в Москве долгота и широта больше нуля, так что же программисту со всей этой кучей оборудования проходить таможню и ехать в Австралию для тестирования?

Здравствуйте, vladpol, Вы писали:

V>Хотелось бы услышать мнения по вопросы вынесенному в заголовок. Понятно, что должны, но тестирование может быть "только пройтись по основным сценариям" или провести полномаштабное тестирование с элементами творческого поиска. Про unit- тесты, я конечно знаю, но во первых они тоже не панацея, есть ситуации которые имим не отловишь, во-вторых написать качественные unit-тесты тоже не каждый сразу сможет и в третьих — существует проект с малым покрытием и быстро исправить ситуацию нереально.
V>Спасибо за ответы

Как пример.
У нас раньше все тестирование производили тестеры. И была куча проблем. Опишу одну из них.

Известно, что фикс бага может породить другие баги. Процесс разработки был такой, что билд собирался раз в сутки. Сделанный баг мог проявиться в двух формах:
1) Блокер! Самая худшая ситуация, когда фикс одного бага приводит к блокеру. Блокер для нас — это когда билд невозможно тестировать вообще. Соответственно все тестеры сидят и тестят предпоследний билд. Это целый день простоя команды! Это очень и очень дорого.
2) Менее плачевная ситуация когда сделанный баг затрагивает какую-то компоненту и не блокирует тестирование всего билда. При этом программисту требовалось возвращаться к задаче, которую он сделал вчера. Не факт еще, что баг был найден на следующий день. Вобщем программист мог уже забыть что он там делал, из контекста выпасть. Это влечет дополнительные затраты времени на фикс бага. Также растет вероятность сделать новый баг, это опять же отражается на времени.

Чтобы решить эти проблемы было сделано следующее.
1) Сделаны тесты компонент. Причем это было интеграционное тестирование, а не модульное. Компонента тестилась как набор связанных модулей. Если программист делал фикс в своей компоненте, то он должен был прогнать весь тест план на компоненту. Если все пассед, то делает коммит.
2) Коде ревью. Много ошибок выявлялось при коде ревью.
3) BVT тесты. Все билды после сборки проходили BVT тесты. Если что-то рухнуло, то начиналась раздача пенделей, билд в тестирование не отдавался. Также новый билд собирался не вечером, а после обеда, чтобы к концу рабочего дня билд по возможности был.
...
Еще много чего было для того, чтобы избавиться от проблем. Пункт 1) отвечает на вопрос. Девелопер должен проверять свой код и очень тщательно. Лучше это делать автотестами, человек может что-то забыть или посчитать не нужным, схалтурить одним словом. Человеческий фактор надо максимально исключать. Мне вообще лень что-то тестить руками по второму разу, только что-то новое меня может заинтересовать. И это важный момент!
И еще побольше ответственности за все. Реопены багов идут в минус оценки для разработчика, это их заставляет все тщательно проверять. И жесткий контроль дубликатов и верифаев, чтобы не обманывали.

Не учтён регресс. В помойку такую логику.

Здравствуйте, VGn, Вы писали:

VGn>Не учтён регресс. В помойку такую логику.
Ваш комментарий непонятен. В помойку такой комментарий.

VGn>>Не учтён регресс. В помойку такую логику.
XSH>Ваш комментарий непонятен. В помойку такой комментарий.

Стыдно не знать. Особенно ваяя "шедевры" в форуме о тестировании.