Имя: Пароль:
LIFE
Наука
OFF: Разработка и тестирование должно проводиться разными людьми.
,
0 sol
 
14.07.14
13:44
Добрый день, форумчане!

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

Помогите, пожалуйста, найти ссылки и убедить в этом моего начальника.
1 Asmody
 
14.07.14
13:45
ты фикси? тогда никакими "программистскими сильвер-буллетами" ты это не докажешь.
2 Maxus43
 
14.07.14
13:46
должность есть такая - тестировщик. Т.е. все эти люди по мнению твоего начальника - бесполезные?
3 Aleksey
 
14.07.14
13:46
А кто писать то будет?
5 КонецЦикла
 
14.07.14
13:47
(0) А пользоваться, простите, третий?
Ну вы даете...
7 Maxus43
 
14.07.14
13:47
хватит рекурсию тут устраивать)
8 Godofsin
 
14.07.14
13:47
(5) Прощаем, третий.
9 PR
 
14.07.14
13:47
(5) Более того, должен быть тестировщик от исполнителя и тестировщик от заказчика.
10 anatoly
 
14.07.14
13:48
разработчик и тестер в принципе разные люди. по устройству мозга. потому что то что для разработчика "фича" для тестера - "бага".
11 Aleksey
 
14.07.14
13:48
(2) Ну т.е. фирма в которой 1,5 колеки (директор и 2 менеджера), должна нанять 30 человек обслуживающего персонала (бухглтаер по кадрам, бухглтер по взаиморасчетам, бухгалтер по ОС и материалам, главный бухглатер. Отдел АСУ, включая начальника админа, подавана, кодера ....)
12 vde69
 
модератор
14.07.14
13:49
вообще тестирование бывает разное
1. функциональное (что просили то и реализовано)
2. баг тестирование (обычно делается по неким сценариям)
3. нагрузочное

ты о каком тестирование?
13 Asmody
 
14.07.14
13:49
Есть такая вещь — экономическая целесообразность. Если твоя фирма занимается разработкой ПО, то тестировщик уменьшает риски, что оправдывает наличие такой единицы в штате. Но и в этом случае нужно правильно оценивать риски — стоят они того, чтобы увеличивать ФОТ на ~800 тыс. в год?
14 Shurjk
 
14.07.14
13:50
(0) Главное какой подход, а кто это делать будет не так важно.
15 Лефмихалыч
 
14.07.14
13:50
(0) я думаю, если присмотреться, то даже в библии об этом найти можно
16 Asmody
 
14.07.14
13:50
(11) фирма становится крупной, когда в штате появляется уборщица.
17 х86
 
14.07.14
13:51
(0)ITIL
18 sol
 
14.07.14
13:52
(17) Что это?
19 Aleksey
 
14.07.14
13:52
(18) стандарт
20 f_vadim
 
14.07.14
13:52
В ограниченном штате, тестирование переваливается на пользователей. Выкатываешь версию, сообщаешь пользователям - пусть основной функционал гоняют и проверяют.

(16) крупная - когда уборщицы-аутсорсеры
21 Aleksey
 
14.07.14
13:52
22 Федя Тяпкин
 
14.07.14
13:52
(17) причем тут итил?
23 Aleksey
 
14.07.14
13:53
(22) слово иностранное и непонятное. А посему умное. И любой человек который его произносит это +100 к респекту и уважению
24 Godofsin
 
14.07.14
13:55
(23) и интеллекту
25 f_vadim
 
14.07.14
13:55
(20) + если тестировать по науке - без отдельного человека не обойтись, надо писать всякие тест-кейсы, методики испытаний и т.п.
26 saasa
 
14.07.14
13:55
(0) ты покупаешь или продаешь ?
27 Aleksey
 
14.07.14
13:56
(25) И как минимум нужен начальник отдела тестирования, и зам директора отдела ИТ по тестированию
28 sol
 
14.07.14
13:57
Я разрабатываю и я фикси. А тестировать собственный продукт мне, особенно, тяжело.
29 Aleksey
 
14.07.14
13:57
Вообщем как минимум
Ведущий тестировщик-программист, специалист по автоматизированному тестированию, руководитель группы(с) http://vakant.ru/resume/cat/itcompinternet/223493.html
30 saasa
 
14.07.14
13:58
(28) забей, про косяки тебе юзеры сами расскажут.
31 f_vadim
 
14.07.14
13:58
(27) это зависит от количества непристроенных родственников руководства :)
32 sol
 
14.07.14
13:58
Роль тестировщика, иногда, выполняет наш аутсорс из франчайзи.
33 Bigbro
 
14.07.14
13:59
более-менее крупные конторы по разработке ПО в первую очередь пишут тесты и только затем код который будет эти тесты проходить.
34 f_vadim
 
14.07.14
13:59
(28) не видать тебе ещё одного человека, сваливай на пользователей. На основные модули можно накидать автотестов.
35 Aleksey
 
14.07.14
14:00
(28) А что такое собственный продукты? Это продукты для себя любимого, типа учет личных финансов?
Или для предприятия? Если второе, то у тебя есть куча пользователей. Они все твои тестировщики.

А так у нас на предприятие обычно выделяем фокус группу среди пользователей (зачастую это "заказчик") которые и тестирую.
36 anatoly
 
14.07.14
14:01
> Это продукты для себя любимого, типа учет личных финансов?

значит не только я такую шнягу писал? )))
37 Sammo
 
14.07.14
14:01
(13) Даже если фирма не занимается разработкой ПО, то тестироващик может быть экономически целесообразен.
38 Гобсек
 
14.07.14
14:01
По всем признакам, фирме 1С тестировщики не по карману. Неужели проекты ПО вашей фирмы способны окупить тестировщиков?
39 Sammo
 
14.07.14
14:01
+37 но если 1 разработчик и 1 тестировщик, то неладное что-то в консерватории...
40 Azverin
 
14.07.14
14:01
(28) чем вызвана "тяжесть" прогнать несколько контрольных примеров?
41 sol
 
14.07.14
14:02
(32) Просто сегодня начальник на мою просьбу подключить тестировщика (аутсорс, сам начальник, или параллельный программист) ответила с иронией (якобы я халявщик).
42 Aleksey
 
14.07.14
14:02
(40) Как минимум внутренняя лень разработать эти тесты
43 mikecool
 
14.07.14
14:03
(0) согласен. после трех месяцев внедрения на мои предложения тестировать то, что пишут внедренцы, гендир сказала "да, это правильно", но дальше слов дело не дошло
сидим, плачем и колемся )
44 Aleksey
 
14.07.14
14:03
(41) Тут все очень просто. Цена услуг тестировщика и тебя как кодера. Если дешевле чтобы ты как кодер не занимался своими прямыми обязанностями а за з/п кодера еще и тестировал, то ...
45 Гобсек
 
14.07.14
14:04
(41)Ваши пользователи все постепенно оттестируют. Только надо держать руку на пульсе и быть внимательным к их словам и предложениям.
46 Azverin
 
14.07.14
14:04
(32) обычно наоборот происходит. странная у вас связь..
47 sol
 
14.07.14
14:04
(40) В определении этих контрольных примеров.

Могут быть 100 таких контрольных примеров и не одной ошибки (хотя ошибок - куча).
48 Aleksey
 
14.07.14
14:05
(47) И почему ты уверен что тестировщик их найдет?
49 Bigbro
 
14.07.14
14:05
мне кажется есть некий порог сложности разработки начиная с которого дальнейшая разработка без создания тестов становится экономически менее выгодной.
50 Aleksey
 
14.07.14
14:05
Какое то у тебя странное понимания возможностей тестировщика
51 Azverin
 
14.07.14
14:06
(47) плохо ориентируетесь в предметной области разработки? фантазии не хватает?
найдите толкового пользователя, который согласится помогать вам в тестировании.
52 Aleksey
 
14.07.14
14:06
Даже в программе которая выводит слово "привет мир" можно сделать кучу ошибок
53 vde69
 
14.07.14
14:07
для того что-бы тестировать нужны как минимум требования к функционалу, я не так часто его видел даже во франчах....

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

Я в крупной фирме и начальник мой немного комплексует из-за возможности кучи ошибок.
56 sol
 
14.07.14
14:09
(53) Есть функционал, достаточно громоздкий, в обычном приложении. Так я его перевожу в управляемое приложение.
57 Azverin
 
14.07.14
14:12
(56) начальник твой должен войти в ситуацию и помочь с тестированием, раз у него комплекс из-за этого.
58 vde69
 
14.07.14
14:12
(56) невозможно 100% функционала обычного приложения веревести в УФ (например динамические списки тупо другие, поиск другой и т.д.)... по этому описание функционала НУЖНО!!!
59 acsent
 
14.07.14
14:14
(58) Именно функционала  - можно
60 acsent
 
14.07.14
14:15
(59) Интерфейсно может конечно по другому немного быть
61 дедушка Вах
 
14.07.14
14:18
на вылеты в программе тупо и студенты-бибизяны могут тестировать, как в фирме 1С
ЗЫ а хотелки надо понимать - верь конечному юзеру, он не пердит
62 VladZ
 
14.07.14
14:27
(0) А в чем сыр-бор? Хотите взять тестировщика в штат? Объемы какие? При наличие в отделе больше одного разработчика тестировать можно задачи друг друга. И смена деятельности (что полезно) и глаз не замыливается. Можно и начальника подключить к тестированию.
63 VladZ
 
14.07.14
14:29
+62 Только не вздумай назвать начальника тестировщиком!!! Пусть выглядит солидно!! Пусть будет "Служба контроля качества". Звучит солидно...
64 Kamas
 
14.07.14
15:10
(0) попроси у начальника подразделения чей функционал затрагивает разработка, 1 человечка по смышленее на тестирование, если согласится то получится сразу несколько плюшек.
1)  т.к человек намного лучше представляет свой каждодневный труд то сразу скажет недочеты в интерфейсе и функционале(да да интерфейс это очень важно одна надпись на форме может экономить 1-3 минуты рабочего времени одного цикла бизнес процесса, а если данный цикл на предприятие совершается 1000 раз в месяц то.. )
2)это человек намного быстрее пробежится по функционалу (оператор раз 100 быстрее набьет заказ по сравнению с программистом)
3) когда будет происходить внедрение то это человек будет в курсе дел и сможет на мелкие вопросы коллег отвечать сам не дергая внедрение по пустякам.
4) зарплат оператора обычно меньше зп программиста (так, что выгоднее чисто экономически)
65 anatoly
 
14.07.14
15:13
(61) грамотный проф.тестер не только на вылеты проверит, но и найдет такие баги о которых сами разработчики не подозревают ))
66 Kamas
 
14.07.14
15:23
(65) если разраб знает о баге, и не исправляет, то это недокументированная возможность
67 StanLee
 
14.07.14
15:36
гдето читал, что разработка и флейм на мисте должны проводиться разными людьми..
68 MSII
 
14.07.14
15:36
(55) Ну скажи ему, чтобы не комплексовал - ошибки в процессе разработки ПО есть явление совершенно рядовое.
69 Karavanych
 
14.07.14
15:42
(68) А он тебе скажет - твой код, недоработки и баги в нем - твой косяк, за то что это попало в боевой релиз - тебе снимаем премию :) Надо лучше тестировать.
Самое прикольное- это когда такой разговор происходит после не типового обновления конфигурации... Типа ты обновлял - должен был проверить весь функционал !!! :)
70 Karavanych
 
14.07.14
15:48
(69) Я вот как то бывал в конторе где у меня был такой разговор, я не нашел даже что ответить... И руководству про тестирование ничего не объяснишь это бесполезно, как бараны на своем стоят, позиция то простая четкая, какие такие тестировщики... сделал - проверь свою работу да и все... вроде как в чем проблемы, а объяснения что создать какую-то более менее сложную систему без ошибок и полномасштабного тестирования - они так глазками хлоп хлоп... типа ты дурак чтоли... сам сделал - сам можешь и проверить... вроде в чем проблема, че ты нас лечишь ?
Я конечно просто забил, да и все... потом через какое-то время просто уволился, но блин интересно находят люди выход из подобной ситуации вообще...у меня не хватило так сказать аргументов и сил для борьбы, да и по большому счету было влом.
71 Ymryn
 
14.07.14
16:12
Я учился тестировать свои разработки. В целом, это тяжело, ибо глаз обычно намылен, но ничего невозможного тут нет. В свое время сильно мне помог "волшебный пендель" от руководства. Когда моя обработка чуть не завалила работоспособность подразделения на день. На что мне открыли оборотку и показали сколько стоит день простоя по подразделению и по фирме. И что лучше так не ошибаться. После этого процесс проверки на работоспособность стал занимать заметно больше 10 минут, но и подобных эксцессов больше не было.  Вообще мое мнение, что если вы - фикси, то просто учитесь проверять за собой. Отдельный человек в штат - это роскошь, а тестировать на пользователях - это плохая идея. Будет складываться ощущение, что вы делаете задачи на отвяжись.
72 Aswed
 
14.07.14
16:12
(0) Ясен красен!
73 Necessitudo
 
14.07.14
16:16
(70) Обычная тема. Поэтому работать в таких мелких конторах лучше не устраиваться.
74 Кай066
 
14.07.14
16:22
история стара как 1С
Многие мои знакомые считают, что без ошибок - серьёзных программ не бывает. Случается, программист сам, что делает, не понимает и за бутылкой пива обо всём забывает.
75 Ymryn
 
14.07.14
16:33
(74) мы так доэволюционируем до уровня разработчиков игр. И будем отделам продавать ранний доступ к обработкам. Дескать хотите на 2 недели получить раньше остальных отделов доступ к обработке "Сделать все (ну почти все)", тогда притаскивайте в IT'шную конфеты/питье. И потом еще с них багрепорты трясти.
76 Karavanych
 
14.07.14
17:03
(71) Ну протестировать маленькую обработку, которая кардинальным образом меняет данные - это одно. Но когда ты вводишь в эксплуатацию какую-то большую систему, и тут начинается нудотство по поводу того, что все должно работать сразу без тестовой эксплуатации, а потом если находятся ошибки, которые исправляются за день/два, но тебе выедают по этому поводу мозг... это напрягает.
(74) А а как по другому ? Вот если щас не кривя душой сравнить все отделы разработки в которых я работал за последние 5 лет. Я делал меньше всего ошибок и косяков и работал на результат, но я все равно считаю что не возможно что-то серьезное написать без ошибок и без тестовой эксплуатации. А текстовая эксплуатация это либо отдел тестирования, либо пользователи, разработчику это просто не под силу.
77 Shurjk
 
14.07.14
17:15
(76) Согласно науки о тетсирование тестирование есть процесс бесконечный.
78 IamAlexy
 
14.07.14
17:15
(0) так и есть..
объяснения просты: я как программист писавший программу знаю как она ДОЛЖНА работать, соответственно нажимаю на кнопки в том порядке и с той силой чтобы оно работало как должно..

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

ибо "защита от дурака" стоит весьма недурацких денег..
79 Ymryn
 
14.07.14
17:18
(76) Любая большая подсистема состоит из множества маленьких. Сначала проверяется работоспособность маленьких, потом проверяется стык. Как бы проектирование для того и делается на этапе разработки, чтобы проанализировать узкие места и подложить там соломки. То что исключить все ошибки самому не получится - я согласен, но хотя бы отсеять критические, которые повлияют на работу программы, или которые вообще могут прекратить её работу - это по силам. Все-таки все уязвимые места, как архитектор ты должен знать. И укрепить их, протестировать на прочность - вполне посильная задача.
80 Karavanych
 
14.07.14
17:18
(77) Ну и этот аргумент куда воткнуть ?
Вот тебе приходит руководство и говорит, какого х... вы запустили, а тут ошибки, тут ошибки, и тут ошибки... а ты им говоришь - тестирование есть процесс бесконечный. ???
Они глазками хлоп, хлоп, -30% от премии.
81 Shurjk
 
14.07.14
17:19
(80) Обычно удается обойтись без штрафов.
82 Shurjk
 
14.07.14
17:21
+(81) Я им не выдвигаю дурацких требований как например принять в штат тестировщиков, они с меня не требуют чего то супер идеального но в то же время знают что свои ошибки я всегда исправляю максимально быстро.
Ну и в амно меня носом как правило никто не тыкает, мне и без них обычно стыдно.
83 Karavanych
 
14.07.14
17:23
(81) Удается то удается, я к тому, что позиция руководства:
Вы делаете свою работу, должны сами ее проверять и выдавать уже рабочий результат - это позиция то в принципе очень твердая.
И я хочу понять, какие в противовес такой позиции должны быть так же железобетонные аргументы ? вот какие они ?
84 ilpar
 
14.07.14
17:26
(0) продукт - да. А вот доделки по хотелкам - нет )
Юзабилити и все такое.
85 IamAlexy
 
14.07.14
17:27
(83) тут если идти на принцип я бы просто написал пошаговую инструкцию согласно которой все работает.. а шаг влево- щаг в право - не мои проблемы... вот инструкция, по ней работает...  читайте и следуйте строго
86 Shurjk
 
14.07.14
17:27
(83) Наверное что то такое чтоб они поняли что ты реально делаешь все от тебя зависящее, а не ищещь оправдания.
Можешь сказать что у тебя времени не хватает на это, можешь сказать что физически не можешь все проверить - это в принципе будет правдой, но если ты после этого остаешься работать то значит ты все таки принимаешь обязательства и желательно при этом хоть сделать вид что ты их собираешься выполнять.
Опять же  что считается не рабочим результатом? Ты же все равно на месте, возник небольшой косяк исправил его и работаете дальше, такие ошибки когда приходиться чему то простаивать ведь кранйе редки, или ты работу сдаешь и пропадаешь на неделю?
87 Shurjk
 
14.07.14
17:28
(85) Инструкции это само собой, но все равно бывают мелкие косячки, где то за типами недлглядел, где то еще чего то забыл проверить, у всех думаю такое бывает.
88 f_vadim
 
14.07.14
17:36
(83) Тут изначально посыл неверный и в противовес тут сказать нечего. На больших проектах "должны сами ее проверять и выдавать уже рабочий результат" - не работает.
89 Karavanych
 
14.07.14
18:25
(88) Т.е. что в противовес просто говоришь - "так не работает" и заявление на стол ? других вариантов нет ?
90 Aleksey
 
14.07.14
19:07
(79) Не все так однозначно. Например был у контрагента реквизит ТипКонтрагента
Вип-клиент
Обычный

Потом решили разбить обычный на 2 ларёк-шмарёк, оптовая база.
Ты прописал проверил работоспособность, но потом выяснилось что у юзверя есть личная печатная форма/обработка которая завязана на этом реквизите.
Кто виноват, что у  юзверя всё сломалось?
91 ILM
 
гуру
14.07.14
19:33
Работаю в аджайл стиле уже два года. Скорость разработки максимальная, тестируют функционал заказчики, раз в две недели или раньше обсуждается требуемый функционал. Объем задач ненапряжный и всех устраивает. Со срочняками в сад.
92 дедушка Вах
 
14.07.14
19:44
100 грин за каждый косяк в данных + я вам жену дам в аренду
93 Kateryne
 
14.07.14
20:03
(90) Не, не аргумент.
1) Вариант А. Обработка на поддержке вашего отдела.

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

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

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

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

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

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

При вменяемом руководстве - это отлично достигается. Просто за небольшое количество багов никто премии не лишит.
При невменяемом - если зп даже после лишении премии и/или криков и оров - устраивает, вырабатывайте пофигизм. Если не устраивает - увольняйтесь.
94 mdocs
 
14.07.14
21:38
(0) Лучше вазелином запасайся. Даже в относительно больших контрах не видел "тестировщиков" ака "мальчиков для битья", вполне хватало бухов, из тех что по-грамотнее.
95 DailyLookingOnA Sunse
 
15.07.14
10:04
"Кроме того, сокращения могут быть связаны с новым подходом к организации отделов разработки, о котором на прошлой неделе объявил глава Microsoft Сатья Наделла. Команды разработчиков традиционно делятся на менеджеров программ, собственно разработчиков и тестеров. Наделла же в связи с появлением новых "облачных" методов разработки программного обеспечения предложил авторам приложений самостоятельно тестировать свой продукт и исправлять ошибки вместо того, чтобы содержать отдельную команду тестеров."
(C) РБК
Даешь корпорацию ИПшников!
96 Анцеранана
 
15.07.14
10:21
(0) чаще всего функции тестировщиков ложатся на:
а) самих прогов
б) пользователей
в) аналитиков или тех кто есть сейчас на фирме в этой роли.
Например у нас это фин. менеджеры
97 Karavanych
 
15.07.14
10:41
(95) Класс... прощай Microsoft ? Че-то мне казалось что Наделла не из Кокаколы пришел... а вон оно как оказалось то.
98 jk3
 
15.07.14
12:48
(78) Угу, хорошая "защита от дурака" автоматически умножает размер кода на два, имхо.
99 jk3
 
15.07.14
12:56
(0) Вообще, разработчик сам по себе должен заниматься тестированием "белого ящика", т.е. удостоверится, что алгоритм пройдет по всем веткам и как минимум программа не вылетит, а как максимум отработает верно.

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

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

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

Не падает, правильно отрабатывает -- хорошо;
падает, неправильно отрабатывает -- баг-репорт.
100 jk3
 
15.07.14
12:56
100
101 BuHu
 
15.07.14
13:28
на одном из предыдущих мест работы мы тестировали задачи друг друга , так как бывает , что замылиным взглядом и не заметишь ошибку . ответственность за наличие ошибок в рабочей базе ложилась на обоих . да и когда сам тестируешь отрабатываешь только благоприятный сценарий , не принимая во внимание , что пользователь может все делать через одно место .
Выдавать глобальные идеи — это удовольствие; искать сволочные маленькие ошибки — вот настоящая работа. Фредерик Брукс-младший