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