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

[Case]

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

Интересует мнение и в том как убедить раскошелиться на тот предмет (статьи, ссылки) и рекомендации для компании как поступить.

[Case]

Размеры проекта большие, компания небольшая. Вопрос поддержки в дальнейшем стоит.
Компании в принципе и решать открывать ли свой отдел (который не факт, что будет активно использоватсья в дальнейшей работе) либо отдать на сторону.

Кстати про дешевле выйдет, совершенно не согласен.
Затраты чистые одинаковые - кол-во разработчиков, ставка, кол-во месяцев работы при перемножении дадут одно и тоже.
А вот что аутсорсинговоая компания также хочет кушать и жить несомненно. Кроме того уатсорсинг это в принципе своём затачивание чужого оружия (то есть опыт уходит вместе со сторонними разработчиками).

[Case]

Логично, но не убеждает, что собрать свою команду тестирования будет дороже чем вынести тестирование за пределы компании, а с точки зрения стратегического развития фирмы-разработчика так и вовсе, по-моему, слов нет насколько своя команда выгоднее.

[sashaf]

О каком тестировании идёт речь? Для многих проектов должное качество можно поддерживать без отдела тестировщиков.

[Олешка]

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

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

А стратегически, имея в перспективе другие проекты - ИМХО, надо делать отдел.

[OlegSh]

Я не совсем понял - есть компания , к-рая разрабатывает ПО, но у нее нет тестеров (и они решают нужны ли им тестеры) или же есть заказчик у компании к-рая разрабатывает ПО и стоит вопрос набирать ли людей в компанию Заказчика для тестирования ПО или воспользоваться услугами третьей организации для тестирования?

[Case]

Для многих проектов должное качество можно поддерживать без отдела тестировщиков.

Слушаю Вас очень внимательно, Александр :)
Пример такого проекта.

[Case]

В любом случае оценить стоимость и объем работ по тестированию надо. Такой проект можно будет показать заказчику. Как минимум, он увидит, на что предполагается потратить его деньги.

Что и пытюсь сделать. Это проблема не моя, попросили проконсультировать - вот готовлюсь, советуюсь.

У вас же сложились определенные этапы работы тестировщиков над проектом - их можно оценить по времени, хотя бы на основе предыдущего опыта.

Такого рода проект мне тестировать не доводилось (крупный веб портал), не могу оценить.

И, как вариант, можно договориться с заказчиком об incremental delivery (любимая фича нашего директора).

Растолкуйте, что за зверь.

[Case]

Есть компания , к-рая разрабатывает ПО, но у нее нет тестеров (и они решают нужны ли им тестеры)

Есть компания разработчик у которой нет тестеров и стоит вопрос открыть ли свой отдел или отдать на сторону. Заказчику мы ничего не будем нанимать :)

[Олешка]

To Case: определяются этапы работы над проектом - что и в какие сроки будет разработано. Исходя из этого, строится план непрерывных поставок - например, каждую среду должны отдать заказчику на просмотр то, что сделано. На каждую поставку устанавливаются определенные тестовые процедуры. Это то, что наш директор называет incremental delivery. При этом заказчик может оплачивать проект частично, а вы получаете возможность, оценив предварительно объем работ, в дальнейшем эти цифры корректировать.

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

[Case]

То есть по-сути обычный итеративный подход, только термин итерации ужат до недели, а не до ХР-шных двух. Но идея с частичной поставкой/оплатой интересная.

[sashaf]

To Case: определяются этапы работы над проектом - что и в какие сроки будет разработано. Исходя из этого, строится план непрерывных поставок - например, каждую среду должны отдать заказчику на просмотр то, что сделано. На каждую поставку устанавливаются определенные тестовые процедуры. Это то, что наш директор называет incremental delivery. При этом заказчик может оплачивать проект частично, а вы получаете возможность, оценив предварительно объем работ, в дальнейшем эти цифры корректировать.

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

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

[sashaf]

Слушаю Вас очень внимательно, Александр
Пример такого проекта.

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

[Case]

Саша :)
Вот я и хочу спросить, какой же из проектов где мы могли пересекаться не проходил тестирования?

[ShS]

to Case
Как я понял из первого поста, речь шла о том как раскрутить заказчика на дополнительные $$$ (заставить согласиться его с пунктом в смете: Тестирование - ...$$$), а свелось к тому, надо ли привлекать тестировщик к проекту или нет, и если ДА, то свих или чужих...

Решение о том надо подключать тестировщиков на проект или нет должен принимать менеджер проекта (или руководители компании)...имхо

Главное, чтобы это получилась система, удовлетворяющая требованиям заказчика...

[sashaf]

Ну вот, опять я неправильно был понят :(
Я не говорил об отсутствии тестирования, а лишь об отсутствии отдела тестировщиков, да и просто тестировщиков, для определённых проектов. Хотя это и не говорит об отсутствии тестирования. Отдел тестирования компенсировался другими уловками.
Я вобще этот разговор затеял не для того чтобы ущимить чьи-либо интересы и знания. Я считаю что для каждого конкретного проекта необходимо применять минимальные но достаточные ресурсы. Например, для некоторых проектов будет достаточным обилия модульных тестов, написанных самим же разработчиком, для тестирования веб приложений можно воспользоваться объектной моделью IE, автоматизировать который может также разработчик. Правда в этой схеме применим лишь TDD подход.
Хотя есть и проекты в которых без отдела качества не обойтись. Но необходимо это или нет тяжело узнать наперёд, в умных книгах пишут о постепенном привлечении большего количества людей.

[Case]

Как я понял из первого поста, речь шла о том как раскрутить заказчика на дополнительные $$$ (заставить согласиться его с пунктом в смете: Тестирование - ...$$$), а свелось к тому, надо ли привлекать тестировщик к проекту или нет, и если ДА, то свих или чужих...

Не идёт речь о раскрутке - я так и написал, заказчик прекрасно понимает что тестирование нужно и готово за него платить.
Вопрос в том кому доверить - своему отделу, который нужно раскрыть, зааутсорсить тестирование.

[Case]

Отдел тестирования компенсировался другими уловками.

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