Мы тоже прошли там через тестирование в прошлом году (родительский кабинет Фролик), причем первый раз по партнерке нас опубликовали без «жесткого» тестирования, а вот второй релиз — не пропустили, выкатили отчет с ошибками. Кстати, тестировал человек из perflab-a, видимо, просто отдают на аутсорс. Но молодцы, что сказать, проверяют!
Поправка :) в стиле грамма-наци: компонент (м.) — компоненты (мн.); компонентов, компонентом. wiki:В соответствии с ГОСТ 34.003-90 данный термин имеет мужской род — Компонент.
Какие корпорации в здравом уме отдадут приемку на аутсорсинг? Максимум — аутстаффинг (боди-шоппинг), т.е. использование людей и инструментов на своей территории. И зависит от видов тестирования, в этом согласен с вами. Апробацию сайтов и тесты пользовательского интерфейса — да. Но бизнес-критические решения все тестируют сами, иначе — риск потери компетенции и бизнеса.
Кратко о книге Дзен и искусство ухода за мотоциклом — сразу после прочтения я рекомендовал её всем, кто близок к тестированию и кому важно качество, но теперь думаю, что не все её осилят и оценят, а жаль.
Любой желающий может написать ЗАЧЕМ создавать отдел тестирования. И любой может ему противоречить. У меня нет готового ответа на этот вопрос. Я, конечно, много чего могу сказать в связи с этим, но ответить — увольте. У меня есть опыт создания и развития — welcome или мимо :)
Да, вы правы, все это видели. И что? Никто за вас вашу цель не выявит и не решит. Статья описывает опыт и этапы. Каждый вправе как наступать на свои грабли, так и учиться на чужих ошибках и на успешном опыте. Вы вправе на вашем авто ехать куда угодно, в том числе и в кювет, автошкола за вас не решит, куда вам ехать в текущем состоянии.
Ответ на вопрос — не может быть успехом, т.к. тестирование — не ребус, а процесс. Процесс — это деньги, методы и люди. Не надо утрировать и на пальцах решать интегралы :)
Зачем — это не вопрос топика. Цель статьи — КАК. Цель выбрана, есть опыт как решить вопрос.
Зачем в вашей в компании тестирование — ваш вопрос, хотите, отвечайте. Я отсылаю к Джоэлю Спольски.
Впрочем, колхозы в свое время много хорошего сделали :) И сейчас, при адаптации к условиям, например, в Израиле, кибуцы очень эффективны и доходны, там, говорят, самые лучшие зарплаты и социальные гарантии, лучшие школы и пр. Будем посмотреть на рост и взросление нашего «тест-кибуца» :)
Указанное вами скорее некий новорожденный краудсорс, это не вариант для корпораций вообще. Если для аутсорсинга до сих пор стоит вопрос SLA, NDA, финансовой ответственности и доверия, то для такого «колхоза» — эти слова вообще/пока неприменимы.
Все зависит от задач. Я также могу написать, что на одного разработчика должен приходиться один тестировщик — это справедливо для некоторых отраслей. Или 2 разработчика на 1 тестировщика — это также массовый случай в индустрии. Наша практика и хабровский расклад показывают иное. К сожалению, я не внедренец и не собираюсь агитировать за тестирование, я прихожу туда, где уже ясно, что НАДО строить тестирование, причем на индустриальных инструментах, достаточно мощное, часто дорогое, всегда — кастомизированное по процессам.
Потребность в тестировании — это взросление процессов в компании. Тестирование должно потребоваться руководству:
1. для проверки интеграции, для функционального (системного) тестирования, для проведения сложных видов тестирования — нагрузочных, безопасности, для приемки продуктов от внешних поставщиков…
2. для экономии сил разработчиков.
3. для экономии денег — тестировщики как правило дешевле разработчиков
4. для экономии времени — тестирование достаточно хорошо (коенчно, не полностью) параллелится с длительной, модульной/компонентной/проектной разработкой.
Есть хорошие переводы обоснований необходимости, например, Джоэл Спольски «Пять (неуважительных) причин не иметь тестеров»(http://russian.joelonsoftware.com/Articles/TopFiveReasonsYouDontHave.html)
С точки зрения программиста ни отдел тестирования, ни тестировщик не нужны для проверки его кода. Юнит-тестирование — не для тестировщиков, на это указывают все учебники. Программист отвечает за свой код сам. Вникнуть полностью в его код может только такой же программист. Используйте парное программирование (ХР). Конечно, есть тестировщики, которые смогут это сделать, но это вопрос более тонкий (если они полностью будут в курсе любого кода, то либо они уже разработчики тестов, либо автоматизаторы, либо гуру — это не вопрос организации).
А почему это должен делать программист? Вы будете начальником группы/отдела тестирования, тест-менеджером или собственно тестировщиком? Или пока таких ролей/людей нет — на вас висят задачи по тестированию?
Один тестировщик, нет тестировщиков, нет денег на инструменты — это кейсы не для той темы, которую я описываю. Если подходить со стороны работодателя, то надо описывать доходность направления, если со стороны разработки — эффективность выделения тестировщиков в отдел (не обязательно отделять от разработки!, очень важно сотрудничать и дружить).
Тезисность, а не краткость. Все не охватишь в топике. Как видно из первых откликов — у всех свои проблемы, не характерные для той среды, где 10 лет я занимаюсь автотестированием.
wiki:В соответствии с ГОСТ 34.003-90 данный термин имеет мужской род — Компонент.
Зачем в вашей в компании тестирование — ваш вопрос, хотите, отвечайте. Я отсылаю к Джоэлю Спольски.
1. для проверки интеграции, для функционального (системного) тестирования, для проведения сложных видов тестирования — нагрузочных, безопасности, для приемки продуктов от внешних поставщиков…
2. для экономии сил разработчиков.
3. для экономии денег — тестировщики как правило дешевле разработчиков
4. для экономии времени — тестирование достаточно хорошо (коенчно, не полностью) параллелится с длительной, модульной/компонентной/проектной разработкой.
Есть хорошие переводы обоснований необходимости, например, Джоэл Спольски «Пять (неуважительных) причин не иметь тестеров»(http://russian.joelonsoftware.com/Articles/TopFiveReasonsYouDontHave.html)