Добрый день, форумчане!

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

Помогите, пожалуйста, найти ссылки и убедить в этом моего начальника.

ты фикси? тогда никакими "программистскими сильвер-буллетами" ты это не докажешь.

должность есть такая - тестировщик. Т.е. все эти люди по мнению твоего начальника - бесполезные?

А кто писать то будет?

(0) А пользоваться, простите, третий?
Ну вы даете...

хватит рекурсию тут устраивать)

(5) Прощаем, третий.

(5) Более того, должен быть тестировщик от исполнителя и тестировщик от заказчика.

разработчик и тестер в принципе разные люди. по устройству мозга. потому что то что для разработчика "фича" для тестера - "бага".

(2) Ну т.е. фирма в которой 1,5 колеки (директор и 2 менеджера), должна нанять 30 человек обслуживающего персонала (бухглтаер по кадрам, бухглтер по взаиморасчетам, бухгалтер по ОС и материалам, главный бухглатер. Отдел АСУ, включая начальника админа, подавана, кодера ....)

вообще тестирование бывает разное
1. функциональное (что просили то и реализовано)
2. баг тестирование (обычно делается по неким сценариям)
3. нагрузочное

ты о каком тестирование?

Есть такая вещь — экономическая целесообразность. Если твоя фирма занимается разработкой ПО, то тестировщик уменьшает риски, что оправдывает наличие такой единицы в штате. Но и в этом случае нужно правильно оценивать риски — стоят они того, чтобы увеличивать ФОТ на ~800 тыс. в год?

(0) Главное какой подход, а кто это делать будет не так важно.

(0) я думаю, если присмотреться, то даже в библии об этом найти можно

(11) фирма становится крупной, когда в штате появляется уборщица.

(0)ITIL

(17) Что это?

(18) стандарт

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

(16) крупная - когда уборщицы-аутсорсеры

http://www.pvsm.ru/testirovanie/45406

(17) причем тут итил?

(22) слово иностранное и непонятное. А посему умное. И любой человек который его произносит это +100 к респекту и уважению

(23) и интеллекту

(20) + если тестировать по науке - без отдельного человека не обойтись, надо писать всякие тест-кейсы, методики испытаний и т.п.

(0) ты покупаешь или продаешь ?

(25) И как минимум нужен начальник отдела тестирования, и зам директора отдела ИТ по тестированию

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

Вообщем как минимум
Ведущий тестировщик-программист, специалист по автоматизированному тестированию, руководитель группы(с) http://vakant.ru/resume/cat/itcompinternet/223493.html

(28) забей, про косяки тебе юзеры сами расскажут.

(27) это зависит от количества непристроенных родственников руководства :)

Роль тестировщика, иногда, выполняет наш аутсорс из франчайзи.

более-менее крупные конторы по разработке ПО в первую очередь пишут тесты и только затем код который будет эти тесты проходить.

(28) не видать тебе ещё одного человека, сваливай на пользователей. На основные модули можно накидать автотестов.

(28) А что такое собственный продукты? Это продукты для себя любимого, типа учет личных финансов?
Или для предприятия? Если второе, то у тебя есть куча пользователей. Они все твои тестировщики.

А так у нас на предприятие обычно выделяем фокус группу среди пользователей (зачастую это "заказчик") которые и тестирую.

> Это продукты для себя любимого, типа учет личных финансов?

значит не только я такую шнягу писал? )))

(13) Даже если фирма не занимается разработкой ПО, то тестироващик может быть экономически целесообразен.

По всем признакам, фирме 1С тестировщики не по карману. Неужели проекты ПО вашей фирмы способны окупить тестировщиков?

+37 но если 1 разработчик и 1 тестировщик, то неладное что-то в консерватории...

(28) чем вызвана "тяжесть" прогнать несколько контрольных примеров?

(32) Просто сегодня начальник на мою просьбу подключить тестировщика (аутсорс, сам начальник, или параллельный программист) ответила с иронией (якобы я халявщик).

(40) Как минимум внутренняя лень разработать эти тесты

(0) согласен. после трех месяцев внедрения на мои предложения тестировать то, что пишут внедренцы, гендир сказала "да, это правильно", но дальше слов дело не дошло
сидим, плачем и колемся )

(41) Тут все очень просто. Цена услуг тестировщика и тебя как кодера. Если дешевле чтобы ты как кодер не занимался своими прямыми обязанностями а за з/п кодера еще и тестировал, то ...

(41)Ваши пользователи все постепенно оттестируют. Только надо держать руку на пульсе и быть внимательным к их словам и предложениям.

(32) обычно наоборот происходит. странная у вас связь..

(40) В определении этих контрольных примеров.

Могут быть 100 таких контрольных примеров и не одной ошибки (хотя ошибок - куча).

(47) И почему ты уверен что тестировщик их найдет?

мне кажется есть некий порог сложности разработки начиная с которого дальнейшая разработка без создания тестов становится экономически менее выгодной.

Какое то у тебя странное понимания возможностей тестировщика

(47) плохо ориентируетесь в предметной области разработки? фантазии не хватает?
найдите толкового пользователя, который согласится помогать вам в тестировании.

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

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

начни с того, что-бы заказчики описывали результат хотелок

(41) Так может так и есть?
Если не выделяют отдельного тестировщика, я бы поступил следующим образом.
Перед разработкой создавал бы тестовые задания и результаты их действий. Согласовывал бы с заказчиком.
Все. Далее у тебя удобная и комфортная разработка. Тестирование по утвержденным шаблонам. Оттестировал - сдал. Дальше их проблемы.
Переходи на методику разработки XP.

(45) Мысль хорошая.

Я в крупной фирме и начальник мой немного комплексует из-за возможности кучи ошибок.

(53) Есть функционал, достаточно громоздкий, в обычном приложении. Так я его перевожу в управляемое приложение.

(56) начальник твой должен войти в ситуацию и помочь с тестированием, раз у него комплекс из-за этого.

(56) невозможно 100% функционала обычного приложения веревести в УФ (например динамические списки тупо другие, поиск другой и т.д.)... по этому описание функционала НУЖНО!!!

(58) Именно функционала  - можно

(59) Интерфейсно может конечно по другому немного быть

на вылеты в программе тупо и студенты-бибизяны могут тестировать, как в фирме 1С
ЗЫ а хотелки надо понимать - верь конечному юзеру, он не пердит

(0) А в чем сыр-бор? Хотите взять тестировщика в штат? Объемы какие? При наличие в отделе больше одного разработчика тестировать можно задачи друг друга. И смена деятельности (что полезно) и глаз не замыливается. Можно и начальника подключить к тестированию.

+62 Только не вздумай назвать начальника тестировщиком!!! Пусть выглядит солидно!! Пусть будет "Служба контроля качества". Звучит солидно...

(0) попроси у начальника подразделения чей функционал затрагивает разработка, 1 человечка по смышленее на тестирование, если согласится то получится сразу несколько плюшек.
1)  т.к человек намного лучше представляет свой каждодневный труд то сразу скажет недочеты в интерфейсе и функционале(да да интерфейс это очень важно одна надпись на форме может экономить 1-3 минуты рабочего времени одного цикла бизнес процесса, а если данный цикл на предприятие совершается 1000 раз в месяц то.. )
2)это человек намного быстрее пробежится по функционалу (оператор раз 100 быстрее набьет заказ по сравнению с программистом)
3) когда будет происходить внедрение то это человек будет в курсе дел и сможет на мелкие вопросы коллег отвечать сам не дергая внедрение по пустякам.
4) зарплат оператора обычно меньше зп программиста (так, что выгоднее чисто экономически)

(61) грамотный проф.тестер не только на вылеты проверит, но и найдет такие баги о которых сами разработчики не подозревают ))

(65) если разраб знает о баге, и не исправляет, то это недокументированная возможность

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

(55) Ну скажи ему, чтобы не комплексовал - ошибки в процессе разработки ПО есть явление совершенно рядовое.

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

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

Я учился тестировать свои разработки. В целом, это тяжело, ибо глаз обычно намылен, но ничего невозможного тут нет. В свое время сильно мне помог "волшебный пендель" от руководства. Когда моя обработка чуть не завалила работоспособность подразделения на день. На что мне открыли оборотку и показали сколько стоит день простоя по подразделению и по фирме. И что лучше так не ошибаться. После этого процесс проверки на работоспособность стал занимать заметно больше 10 минут, но и подобных эксцессов больше не было.  Вообще мое мнение, что если вы - фикси, то просто учитесь проверять за собой. Отдельный человек в штат - это роскошь, а тестировать на пользователях - это плохая идея. Будет складываться ощущение, что вы делаете задачи на отвяжись.

(0) Ясен красен!

(70) Обычная тема. Поэтому работать в таких мелких конторах лучше не устраиваться.

история стара как 1С
Многие мои знакомые считают, что без ошибок - серьёзных программ не бывает. Случается, программист сам, что делает, не понимает и за бутылкой пива обо всём забывает.

(74) мы так доэволюционируем до уровня разработчиков игр. И будем отделам продавать ранний доступ к обработкам. Дескать хотите на 2 недели получить раньше остальных отделов доступ к обработке "Сделать все (ну почти все)", тогда притаскивайте в IT'шную конфеты/питье. И потом еще с них багрепорты трясти.

(71) Ну протестировать маленькую обработку, которая кардинальным образом меняет данные - это одно. Но когда ты вводишь в эксплуатацию какую-то большую систему, и тут начинается нудотство по поводу того, что все должно работать сразу без тестовой эксплуатации, а потом если находятся ошибки, которые исправляются за день/два, но тебе выедают по этому поводу мозг... это напрягает.
(74) А а как по другому ? Вот если щас не кривя душой сравнить все отделы разработки в которых я работал за последние 5 лет. Я делал меньше всего ошибок и косяков и работал на результат, но я все равно считаю что не возможно что-то серьезное написать без ошибок и без тестовой эксплуатации. А текстовая эксплуатация это либо отдел тестирования, либо пользователи, разработчику это просто не под силу.

(76) Согласно науки о тетсирование тестирование есть процесс бесконечный.

(0) так и есть..
объяснения просты: я как программист писавший программу знаю как она ДОЛЖНА работать, соответственно нажимаю на кнопки в том порядке и с той силой чтобы оно работало как должно..

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

ибо "защита от дурака" стоит весьма недурацких денег..

(76) Любая большая подсистема состоит из множества маленьких. Сначала проверяется работоспособность маленьких, потом проверяется стык. Как бы проектирование для того и делается на этапе разработки, чтобы проанализировать узкие места и подложить там соломки. То что исключить все ошибки самому не получится - я согласен, но хотя бы отсеять критические, которые повлияют на работу программы, или которые вообще могут прекратить её работу - это по силам. Все-таки все уязвимые места, как архитектор ты должен знать. И укрепить их, протестировать на прочность - вполне посильная задача.

(77) Ну и этот аргумент куда воткнуть ?
Вот тебе приходит руководство и говорит, какого х... вы запустили, а тут ошибки, тут ошибки, и тут ошибки... а ты им говоришь - тестирование есть процесс бесконечный. ???
Они глазками хлоп, хлоп, -30% от премии.

(80) Обычно удается обойтись без штрафов.

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

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

(0) продукт - да. А вот доделки по хотелкам - нет )
Юзабилити и все такое.

(83) тут если идти на принцип я бы просто написал пошаговую инструкцию согласно которой все работает.. а шаг влево- щаг в право - не мои проблемы... вот инструкция, по ней работает...  читайте и следуйте строго

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

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

(83) Тут изначально посыл неверный и в противовес тут сказать нечего. На больших проектах "должны сами ее проверять и выдавать уже рабочий результат" - не работает.

(88) Т.е. что в противовес просто говоришь - "так не работает" и заявление на стол ? других вариантов нет ?

(79) Не все так однозначно. Например был у контрагента реквизит ТипКонтрагента
Вип-клиент
Обычный

Потом решили разбить обычный на 2 ларёк-шмарёк, оптовая база.
Ты прописал проверил работоспособность, но потом выяснилось что у юзверя есть личная печатная форма/обработка которая завязана на этом реквизите.
Кто виноват, что у  юзверя всё сломалось?

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

100 грин за каждый косяк в данных + я вам жену дам в аренду

(90) Не, не аргумент.
1) Вариант А. Обработка на поддержке вашего отдела.

Виноваты вы. По результатам инцидента берете и исправляете.

2) Обработка неизвестна вам, ее разработали для пользователя (сам пользователь или сторонние программисты). Политикой компании допускаются личные обработки.

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

3) Обработка неизвестна вам, ее разработали для пользователя (сам пользователь или сторонние программисты). Политикой компании запрещены личные обработки.

Виноват ответственный за безопасность в ИС. Возможно, это вы, возможно кто-то еще. Пользователь не должен был иметь возможность ее запустить.

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

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

(0) Лучше вазелином запасайся. Даже в относительно больших контрах не видел "тестировщиков" ака "мальчиков для битья", вполне хватало бухов, из тех что по-грамотнее.

"Кроме того, сокращения могут быть связаны с новым подходом к организации отделов разработки, о котором на прошлой неделе объявил глава Microsoft Сатья Наделла. Команды разработчиков традиционно делятся на менеджеров программ, собственно разработчиков и тестеров. Наделла же в связи с появлением новых "облачных" методов разработки программного обеспечения предложил авторам приложений самостоятельно тестировать свой продукт и исправлять ошибки вместо того, чтобы содержать отдельную команду тестеров."
(C) РБК
Даешь корпорацию ИПшников!

(0) чаще всего функции тестировщиков ложатся на:
а) самих прогов
б) пользователей
в) аналитиков или тех кто есть сейчас на фирме в этой роли.
Например у нас это фин. менеджеры

(95) Класс... прощай Microsoft ? Че-то мне казалось что Наделла не из Кокаколы пришел... а вон оно как оказалось то.

(78) Угу, хорошая "защита от дурака" автоматически умножает размер кода на два, имхо.

(0) Вообще, разработчик сам по себе должен заниматься тестированием "белого ящика", т.е. удостоверится, что алгоритм пройдет по всем веткам и как минимум программа не вылетит, а как максимум отработает верно.

Но это занимает столько времени, сил, денег, что практически никто так не делает.

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

Вот заявленный функционал, вот интерфейс, вот кнопки, которые можно нажимать в любой или определенной последовательности.

Не падает, правильно отрабатывает -- хорошо;
падает, неправильно отрабатывает -- баг-репорт.

100

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