Сообщений в теме: 22

[Sunchezzz]

Окончательное тестирование - это артефакт водопадных процессов разработки. Если у вас такой процесс, то, наверное, да, неплохая стратегия получилась. Только в таком процессе других проблем с качеством хватает. Вообще "тестирование только по окончании разработки" обозначает очень болшую длину обратной связи между тестировщиком и разработчиком. Обычно это выглядит так: разработка функциональности завершена, она уходит тестировщику, разработчик переключается (и погружается) в другую здачу, и тут внезапно! пачка ошибок на ту область, которую он только что выбросил из головы.

Кроме того, 60-70% покрытия исходного кода юнит-тестами - это относительно много, и если юнит-тестирования не было до этого вообще или оно было слабеньким, то достигать этого показатели придется очень долго. Кстати, тестировщики вполне могут помогать при разработке юнит-тестов.

Пункты, в которых печечилсяются виды тестирования, я бы как-то увязал с рисками конкретного приложения. Есть такие проекты, где по объективным причинам тестирование производительности не нужно вовсе, где-то можно вообще обойтись только автотестами (серверные-сервисные приложения), и так далее и тому подобное. По большому счету, весь этот список можно записать одной инструкцией: "Тестировщик вместе с разработчиком разрабатывают стратегию тестирования конкретного проекта и перепроверяют её с заинтересованными лицами".

Верно, у нас водопадный процесс - самый оптимальный. по моему мнению, для разработки мелких и средних проектов, в которых задействованы 1-2 программиста.
Что касается начала тестирования по окончании разработки? Т.е. лучше её делать параллельно разработки? Т.е. написали модуль "договора по клиентам ААА" и его тут же отдаём тестеру на функциональное тестирование?
Как тогда оптимально выстроить процесс тестирования, при этом выдерживать установленные сроки и качество.

Что касается юнит-тестирования - ну для начала сделаем покрытие им в 40%. Пущай тренеруются :)

[LeshaL]

Что касается юнит-тестирования - ну для начала сделаем покрытие им в 40%. Пущай тренеруются :)

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

И еще - покрытие в 40% - это конечно лучше чем ничего. Но покрытие менее 50% оставляет большие сомнения в том, что же там вообще тестируется. И каком покрытии речь - методы, блоки или бранчи?
Понятно, что добится нужного покрытия по методам, проще чем по бранчам.
Совет такой - сосредоточьтесь сначала на как можно более высоком покрытии по паблик методам (если у вас Java). Потом добивайте наиболее сложные методы, повышая покрытие по бранчам.
Не пытайтесь покрывать более чем на 80-85% - ну если только у вас есть большие временные ресурсы. Ваша цифра 60-70% - то что надо.

[rlabs]

Верно, у нас водопадный процесс - самый оптимальный. по моему мнению, для разработки мелких и средних проектов, в которых задействованы 1-2 программиста.

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

Что касается начала тестирования по окончании разработки? Т.е. лучше её делать параллельно разработки? Т.е. написали модуль "договора по клиентам ААА" и его тут же отдаём тестеру на функциональное тестирование?
Как тогда оптимально выстроить процесс тестирования, при этом выдерживать установленные сроки и качество.

Классически "раннее вступление" тестировщика в процесс выглядит так: оба, разработчик и тестровщик, получают входную спецификацию. Пока один пишет код, второй пишет тесты на "предполагаемый" код. Потом разработчик отдыхает, а тестировщик запускает тесты. Это вот классический V-процесс.

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

Таким образом, мне больше по душе процесс с минимальными итерациями. Получили ТЗ - вместе посмотрели, где могут быть проблемы. Написали прототип - сразу протестировали. Написали базовую функциональность - протестировали её. Это не значит, что протыстированное на одной итерации не придется тестировать снова, но короткая обратная связь обеспечивает быструю реакцию. Мне трудно это правмльно объяснить, но, думаю, чем короче итерация, тем лучше. Внутри итерации схема работы почти как в водопаде, за исключением того, что тестировщик не будет месяцами идти по неправильному пути, и сосредоточится не на написании тест-кейсов, а на нахождении правильного и эффективного подхода в каждом конкретном случае.

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

Что касается юнит-тестирования - ну для начала сделаем покрытие им в 40%. Пущай тренеруются :)

Юнит-тестирование такая штука... Разработчики очень не любят писать лишний код. Написание тестов на существующую функциональность - это, с их точки зрения, лишний код, потому что там "и так уже все работает". И что-то правильное в этом есть, потому что регрессионное тестирование вообще не очень эффективно, а стоит дорого. Поэтому никакими шоколадками вы не заставите разработчика покрыть старый код тестами даже на 40%. Новый - другое дело.