...

На самом деле, являясь простым обывателем, не нуждающимся в устоявшейся терминологии в области тестирования, я считаю, что Nadya Kochetova защищала верную терминологию.

План это последовательность действий (возможно с параллельными ветками выполнения, возможно с проставленными датами). Диаграмма Ганта выражает план. Примером плана является «Дорожная карта» продвижения к постоянному урегулированию палестино-израильского конфликта в соответствии с принципом сосуществования двух государств на основе оценки выполнения сторонами своих обязательств. Переводчики этого документа (а вряд ли кто-то знает русский язык лучше переводчиков Объединённых Наций) ссылаются на него как на план.

Термин же "стратегия", вот уже лет пятьдесят как, часто употребляется в смысле, который в него вкладывает теория игр (см. Стратегия).
В применении к тест-менеджменту, стратегия - это дефиниция того, что надо делать (планировать) при наступлении тех или иных обстоятельств, вероятность которых заранее неизвестна. Стратегия отражает неопределённые аспекты планирования, которые на ту же диаграмму Ганта не ложатся. В этом смысле, приоритезация рисков - это способ определения стратегии. На русский язык термин переведён точно - стратегия не эквивалентна плану. Для проверки можно попытаться, например, мысленно назвать Стратегию развития металлургической промышленности Российской Федерации на период до 2015 года планом. :) Заодно можно обратить внимание на обилие количественных показателей и элементы неопределённости (впрочем, довольно слабо прописанные) в этом документе. Это именно то, что отличает её от плана.

Что же касается James Lyndsay, то он, видимо, просто забыл поставить в свою фразу оговорку under various circumstances, потому что она для него очевидна. Понятие стратегии - это просто часть его (и, возможно, его читателей) математической культуры.

любите вы переливать из пустого в порожнее.

Решил сделать небольшой follow-up в рамках рекламной компании SWEBOK:


5.5.1.2. Test guides

The testing phases could be guided by various aims, for example: in risk-based testing, which uses the product risks to prioritize and focus the test strategy; or in scenario-based testing, in which test cases are defined based on specified software scenarios.

Хочется выстроить понимание, что все мы работаем не для себя, не для абстрактного идола под названием Качество - мы работаем в IT, мы работаем для бизнеса.

О как.

-------------------------------------------------------------------
Даже если отвлечься от госзаказов, "бизнес" - это всего-лишь одно из средств организации улучшения качества жизни, но никак не самоцель.

Когда-нибудь Вы столкнетесь с темой мотивации.

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

..и вообще..нет такого понятия как "младший" тестировщик, есть QA-engineer и Senior QA-engineer ...

Это Вы по своей компании судите? Количество позиций и их название зависят от штатного расписания. В каждой компании оно свое.

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

Это Вы по своей компании судите? Количество позиций и их название зависят от штатного расписания. В каждой компании оно свое.

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

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

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

Если что-то вызывает у Вас волну неконтролируемого смеха, то извольте - объяснитесь.

А можно нарисовать чартер всей затеи? На уровне цели, решаемые проблемы, бенефициары.

Дополнительно имеет смысл осветить еще одну сторону вопроса "программер vs тестер" - самодостаточность деятельности. Программер без работы тестера может работать - он создает, а вот тестер не сможет работать, если собственно говоря тестить нечего. Другое дело, что качество работы программера напрямую будет оценивать уже конечный пользователь, но опять же писать качественный продукт теоретически возможно без промежуточного тестирования (со стороны разработчиков), но это накладно по времени, поэтому-то и выделились отдельно специалисты по тестированию.

А попадает меж тем всё кучнее.
Решится ли кто-то на рассуждения о том, благодаря чему из роли тестировщика (которую, конечно же, разработчик может играть по отношению к результатам деятельности другого разработчика) получилась профессия тестировщика?

Если взять мою вакансию: она по требованиям и зп в Москве уже неадекватна?

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

Т.е. получается по дефолту: отмывать сортир в студенческой общаге и не забывать петь гимны процессному подходу к работе. :) Ясен красен на неё не особо отзываются.

Странно у вас как-то получается Вакансия как вакансия, обычные требования к человеку в компанию, а не в проект. Я когда по рынку искал людей примерно также искал - ибо нет чётких заморочек "j2ee два ода минимум", ну нет - так что ж теперь делать? У нас вакансии ещё интереснее описаны - и приходят люди, и работают.

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

Растолкуйте, пожалуйста, чего вы мне порекомендовали, я не сумел вычленить из текста. Сравнить свою готовность идти на указанные в вакансии деньги и ЗП в резюме Влада? Бр...

Нет. Проделать ментальное упражнение, которое заключается в осознании своей полной ненужности. Помедитировать на тему реального места обеспечения качества, консультирования и обучения на эту тему в общей картине мира. Так ли уж трагично, что кто-то не может нанять себе сотрудников, или найти больше заказчиков? Что от этого меняется? Вот если где-то есть реальная проблема, за которую вообще никто не берётся, то это действительно было бы трагично. Но по моим наблюдениям, свято место пусто не бывает, а в обсуждаемой вакансии никакой реальной проблемы не обозначено.

2 раза сменить работу за 9 месяцев? acute.gif А как же тезис о том, что работодатель предпочитает не иметь дело с перебежчиками?

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

У нас высокотехнологичные проекты, что подтверждается тем ...

Можете даже не сомневаться, что кандидат с нужными Вам опытом и скилами уже поработал в нескольких точно таких же компаниях, не первый раз слышит эту песню, и знает о своих реальных перспективах по только что приобретённому опыту увольнения. Ещё раз попытаюсь объяснить: если бы я её рассматривал, то меня бы интересовало не какие там требования и насколько я им соответствую (ведь если я тот самый кто Вам нужен, то я им уже соответствую), а чем я буду заниматься и зачем именно я со своими знаниями и опытом там вообще нужен. Потому что если я не нужен, то меня всё равно ничего хорошего не ждёт. Без этого ничего не получится, будь я хоть Джонатаном Льюисом, Брюсом Эккелем и <кто уж там самый крутой в функциональном тестировании>. Иногда нужность действительно вскрывается только на собеседовании. Но раз до собеседования никто не доходит, то я бы рекомендовал совершить какой-нибудь подвиг или хотя бы развить какую-нибудь слабость, которую может легко восполнить нужный кандидат, а не поднимать одну и ту же тему на форуме. Чтобы вам нанять какого-нибудь гражданина, который стартует с места и может тягаться с разработчиками, аналитиками, админами, нужно ему показать, что он точно не подписывается на то чтобы какую-нибудь студенческую поделку перекладывать с места на место и портить друг другу нервы с её единственным разработчиком, что его скилы будут востребованы.

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

Мог бы привести в пример кучу компаний, который проверяют на собеседованиях совсем не те знания, которые им требуются.

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

Может и не доведёт. Хотел бы я знать, что доведёт.

На мой взгляд Вам просто не нужна работа. ... Приходите познакомимся :)

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

С другими описаниями сравнивать пробовали?

Пробовал. Два раза выходил на новую работу, пока Ваше объявление тут висит. Один раз в Белл, кстати, по объявлению в этом форуме.

Или мне опус написать на 5 страниц текста? А просто прийти пообщаться и выяснить все на практике уже в лом?

Не надо на 5 страниц. Надо без выпендрёжа, по делу, убедительно. Ну вот не подтверждается из других источников тезис о том что конторе нужны описанные в вашей вакансии люди.
Подход "прийти пообщаться" себя в общем-то исчерпал, т.к. всё равно лапшу на уши вешают. Ну а идти на собеседование изначально настраиваясь на конфликт и уличение собеседника во всех смертных грехах мне кажется неконструктивно, лучше просто забить. Короче, лучше всё на расстоянии выяснить, по пресс-релизам и постингам в форумах, например. :)

Вы похоже так и не поняли, что не в описаниях дело. Case верно отмечает
текущую ситуацию на рынке.

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

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

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

Праздник заканчивается, так что не буду на всё отвечать. Надеюсь я не слишком оффтопил по теме "Как найти готовых сотрудников, которых не надо учить [и которые всё будут делать сами]". :)

a66at: Позволю себе вопрос, чтобы прояснить для себя вашу точку зрения, окончательно. Из какой роли в отрасли тестирования и QA вы в последнее время извлекаете прибыль?

PS
А что за дядьки такие "Джонатан Льюис" и "Брюс Эккелль"? Можно ФИО в оригинале чтобы я не гадал на гугле?

Инженер по нагрузочному тестированию. Правда в свете последних обсуждений не совсем понятно QA это или не QA. Кворум телеком как я прочитал на их сайте тоже хочет этим заниматься, так что мои чувства к ним не праздны. :) На самом деле, я хоть и не Jonatan Lewis или там Bruce Eckel, но тоже есть в гугле.

Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".

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

Т.е. продолжая аналогию с полётами на Луну, процесс нужен:
1. Для сопоставления результатов автоматизированных полётов на Луну с полётами на Луну на собственной тяге;
2. Для оценки доли автоматизированных полётов на Луну в общем объёме полётов на Луну;
3. Для интеграции этого процесса (вот тут путаница, то ли процесса полётов на Луну, то ли процесса автоматизации полётов на Луну) с другими процессами и унификации управляющих воздействий на него (чтобы у менеджеров мозг не лопнул от напряжения при заходе в сферу непознанного :).

Ну это уже не вручную же Это уже автоматика.

Ну ещё одна иллюстрация к утверждению, что нельзя автоматизировать то, чего нет. :)

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

Нет, не понимаю.
Хорошо, будем считать что процесс это просто последовательность стадий, алгоритм, что после чего делать и какими входами выходами активности цепляются друг за друга.
Представим что есть уже внедрённый процесс регрессионного тестирования, который несколько десятков раз сработал.
И представим, что есть просто записанный на бумаге процесс автоматизировааного тестирования, который можно внедрить сверху вниз в первый же раз как вам понадобится провести итерацию автоматизированного тестирования.
В чём преимущество первого процесса перед вторым в данном случае? Или в чём сложность внедрения второго с первого раза?

Автоматизировать тестирование можно только, когда есть чего автоматизировать. А ведь со мной по этому вопросу многие не соглашались.

Неужели Вы правда не понимаете, что подобные утверждения можно опровергнуть не только простым контрпримером, но и чисто на пальцах? На волне размышлений над соседним топиком (про НАСА) мне пришла в голову следующая метафора: "Если бы при автоматизации полётов на Луну было бы необходимым требованием, чтобы предварительно неавтоматизированные полёты на Луну уже были реализованы, то никаких полётов на Луну не было бы".

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

А что значит управляемое состояние? По-моему, для процесса, который просто является последовательностью действий, для управляемости достаточно просто возможности менять его описание и распространить новое описание среди участников.

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

Вы просто посмотрите, что нужно сделать, чтоб это самое автоматизированное тестирование внедрить вот так как вы описали. Особенно в контексте функционального тестирования на уровне ГУИ (от чего изначально отталкивались).

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

А для наращивания нужна основа, нужны артефакты, которые надо подготавливать.

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

Если же процесс только на бумаге, то стадию тест-дизайна ему не миновать.

А каким образом минует стадию тест-дизайна процесс, который не на бумаге? В обоих случаях делается тест-дизайн.

Да, вы ничего не поняли. Живой процесс регрессионки пригоден тем, что он уже есть и его со временем можно по мере возможностей автоматизировать, снимая нагрузку с людей, задействованных в тестировании (часть тестов делегируется на автоматическое тестирование и вручную не проходится).

Так он пригоден или необходим?

С удовольствием, только не с вами - ибо безыдейно :) У вас на меня аллергия, видимо.

Ой, да ради бога.

А вот если кто-то посчитает и покажет как он это сделал, что от внедрения unit-тестирования сэкономили n% ресурсов на тестирование я готов внимательно посмотреть и поговорить крайне вдумчиво.

Простой пример. Вспомните, как Вы сами возились со своим rss фидом. Там надо было конечно не файлы сравнивать, а дебаггером несколько раз пробежать. :) То же самое с unit-тестированием. Впрочем, это действительно вопрос экспов, я полным полно инцидентов видел (и функциональных), которые через GUI невозможно отловить, и очень дорогостоящих. И типичный тестировщик даже не стал бы никаких усилий предпринимать для их предотвращения, потому что у него своя методология и инструментарий, которые для этого по его мнению не предназначены. Так и получается, что тестирование есть, а качества нет.

Только не совсем понял как это к теме "когда и при каких условиях надо внедрять автоматизацию". Я без наезда, просто или я не до конца понял вашу мысль, либо это уже просто ветка ушла в сторону.

Что именно непонятно?

Ошибки в коде бизнес-логики очень дороги, я думаю, любой, кому приходилось их исправлять, согласится, что это сложнее (отнимает больше времени) чем поправить визуалку или разобраться с интерфейсом чужой библиотеки. Это происходит от того, что такие дефекты приходят нелокализованными (если не позаботиться заранее, то непонятно в каком месте кода ошибка или неочевидно сразу как её исправить, зачастую даже когда есть стек-трейс, а его может не быть, просто заведётся сколько-то неправильных проводок), а для их повторения требуется окружение с реалистичными данными и иногда интеллектуальная интуиция. Поскольку они дорогие (в том числе репутационно из-за неопределённости сроков исправления), на них важно концентрироваться в первую очередь. Во многих типах систем (ядро АБС, биллинг) GUI тулы и ручное тестирование через GUI для этого оказалось малоэффективным (моё личное мнение). При обеспечении их качества надо начинать с тестирования компонент, реализующих бизнес-логику, не потому что это сокращает затраты, а потому что это фактически единственный путь добиться результата вообще (для бизнес-систем, например, уверенности, в том, что счёт внутри ведётся правильно в любом случае, а не только, если проводка введена через GUI, и не придётся потом кучу сторнирующих проводок вводить после массовой загрузки).

Т.е. я фактически поддерживаю тезис SALar-а "автоматизированное тестирование это не только и столько тестирование через GUI, но в первую очередь модульное и компонентное тестирование", каковой (тезис), кстати, значительно реже появляется мне на глаза, чем оголтелая реклама методологий, претендующих на универсальность, и патентованных тулов. Лично для себя я его (тезис) обосновываю на основе размышлений над реестрами инцидентов, отсортированных по убыванию цены (тут, надеюсь, есть некая новизна в аргументации). А размышления эти обычно о том, как надо было тестировать, чтобы предотвратить появление таких инцидентов. Конечно, у каждого могут свои классы систем, свои реестры инцидентов и, соответственно, своя точка зрения, но далеко не все пишут об этом статьи с претензией на всеобщность.

Про то что в первую очередь, а что во вторую я бы поспорил.

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

Unit это вообще не к тестерам

Интересно даже стало. Это отражение нежелания или неспособности?

это holy war, пока никто не возьмётся что-то подсчитать в цифрах

А если качественную оценку поставить на место - перед количественной. Вы же специалист по бизнес-приложениям и работали на системах с пакетной обработкой, понимаете, что просто нажать кнопку старта недостаточно. Неужто в этом случае работа только через GUI - самый оптимальный вариант, если отвлечься от цены. И так ли уж редка эта ситуация? А системы отчётности, через GUI, без парсера отчёта?

Про unit-ы.
Я не хочу зацикливаться на определении unit-а, но книгам тут я верю меньше чем людям, с которыми работал: я видел как девелоперы по разному определяли что есть unit даже в рамках одной проектной команды, видел как каждая функция "заворачивалась" в код вызова или как целый модуль, который читает из базы, обсчитывает (дёргая 2-3! других модуля) и пишет обратно в базу тоже обзывали unit-ом и писали целый пакет тестов (со своим доступом к данным), который на входе даёт ID-шку абонента, а на выходе сам же считывает контрольный ответ из пакета подготовленный руками контрольных наборов данных.

Повторю - это должно делаться разработчиками.

Про тестирование на уровне бизнес-модулей.
Основная или базовая функциональность (то что замыкает бизнес-цикл: закрытие периода, перерасчёты, выставление НН, пени и прочей лабуды) зачастую тестировалась внутренней разработкой. Мы делали свои фреймворки, которые дёргали через удалённые вызовы торчащие методы, заменяя по сути вызовы клиента и интерфейсов в другие системы. Отчёты не парсили (ну его нафиг этот "кристалл"), а собирали из базы по опорным точкам на основе бизнес-правил: банально, чтобы например внутри сети электроенергия не возникала.

Unit-тестами этот слой - я бы назвал это тестированием бизнес логики - не покрывается. Средствами record-playback зачастую тоже в основном из-за сложности проверок получаемого состояния. Либо руками, либо создаваемыми отдельно для тестовых нужд приложениями (фреймворками).

Теперь моя очередь пришла тупить и притворяться пеньком. Это что, была аргументация в пользу утверждения "да, встречаются проекты в которых невыгодно или неэффективно автоматизировать через средства record-playback. Но к вопросу внедрения автоматизации тестирования такие исключения зачастую не относятся"?
Вообще, у меня к этому отрывку замечаний нет, я со всем согласен, но хотел бы обратить Ваше внимание на следующие обстоятельства:
1. Оказывается что в Ваших прошлых проектах кто-то ведь делал часть работы по обеспечению качества продукта ("это должно делаться разработчиками", "зачастую тестировалась внутренней разработкой"). Причём, Вы не умеете определить этот вклад количественно. Вы как-то учитываете это теперь, когда стали "дорогим консалтером" и вроде бы собираетесь нести ответственность за весь спектр? Хочу напомнить, что тестирование и автотестирование - это не самоцель.
2. Вообще говоря, в процитированном отрывке описана автоматизация того, чего не существует. По крайней мере, можно себе представить (лично я могу вспомнить) случаи, когда это справедливо.
3. Рискну предположить что дохлые лошади именно так и получаются - делается ставка на тестирование через GUI, когда критические с точки зрения качества продукта участки кода доступны только синтетически, люди чувствуют что занимаются фуфлом и перестают работать. При том подходе, который вы описали в процитированном отрывке, я могу понять как лошадь может получиться и как - не получиться, но как она может получиться дохлой - нет.
4. Всё что вы описали не обязательно делать в процессе разработки, всё то же самое может понадобиться проделать при приёмочном тестировании (если понадобится, и unit test тоже). Т.е. непонятно, что может объективно помешать этому, кроме слепой веры в то что "так не делается". Разумеется, делать это должны квалифицированние люди - "разработчики".
5. Непонятно также, при чём здесь процессы? Вот представьте самую плохую ситуацию (кошмар KaNoN-а): вы - аутсорсер, приходите к заказчику, вам дают стенд и какие-то доки, можно спрашивать у разработки, и надо автоматизированно протестировать какую-то функциональность (неважно даже, доступна она через GUI или нет). Какие после это Вам ещё нужны процессы чтобы были у этого заказчика? Можно список, в нём плюсиками отметить те, становление которых Вы случайно можете разрушить неверным движением, внедряя автоматизацию, и звёздочкой - такие, что Вы без них откажетесь работать, а будете требовать, чтобы владельцы бизнеса немедленно взяли под свой личный контроль их внедрение.

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

Виктор, а если отбросить ваши рефлексии на тему "дорогого консалтера" (вы ещё отмахиваетесь от слова "аллергия? :)"), которым я не являюсь (моё резюме в принципе доступно онлайн - полюбопытствуйте, если есть желание) - что вы пытаетесь доказать?

Про "дорогих консалтеров" отсюда: http://software-test...a...ost&p=39704 :)

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

Что автоматизация тестирования не только GUI? Да, не только. И что?

Говорите, что автоматизация тестирования не столько GUI и я немедленно отвалю. Пока что из серьёзных аргументов от Вас слышно только аппеляции к личному опыту, о котором надо спрашивать отдельно. :) Т.е. тезис у Вас открыто висит, а аргументация в персональном порядке, авось и так прокатит?

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

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

С одной стороны вы пишите что согласны с тем что я написал и тут же двумя-тремя пунктами ниже пишите про своё понимание вопроса.

Я пишу о том, что Ваше описание синтетического тестирования у меня возражений не вызывает и потом на этой основе перехожу к критике самой статьи с точки зрения, заданной замечанием SALar-а. Я не слишком сложные для Вас манёвры делаю? :)

Про автоматизиацию того что не существует - повеселили. Описываемые системы существуют, подходы взяты из жизни - сильно поломал представление о реальности?

В контексте статьи об автоматизации тестирования, заявление о том что нельзя автоматизировать то, что не существует, я посчитал эквивалентным утверждению: "Нельзя автоматизировать тестирование, если не существует тестирования (требований, тест-кейсов)". Привёл контрпример. Что Вы в статье на самом деле имели в виду? Что нельзя автоматизировать бизнес, если нет бизнеса? Что нельзя автоматизировать IT-систему, если нет системы?

Unit-тестирование на этапе приёмки - это вы пошутили сейчас верно? Заказчик или сторонний подрядчик на стороне заказчика садится и покрывает код системы (который ему ещё кто-то должен дать, ага) unit-тестами: так и вижу, угу.

Я вам объясняю-объясняю, что иногда (не так редко) это приходится делать практически в чистом виде, а вы не хотите понимать (и это уже не в первый раз). Что с Вами делать? Я вот не помню, то ли в те времена дебаггера в Query Analyser не было, то ли не умел им пользоваться, так нет проблем, заглушил, наставил "assert"-ов и протестил. Приёмка была, точнее сертификационное тестирование. Unit был, testing был. Другие виды синтетики, впрочем, много чаще случаются.

Похоже стоит всерьез задуматься над формированием единого словаря на данном форуме.

Я бы просто предложил пользоваться SWEBOK 2004 Eng. Там практически всегда можно найти опору, хотя бы косвенно.

Собственно, я позволил себе развернуть небольшую рекламную кампанию по этому поводу, использовав топики с терминологическими дискуссиями:

Про стратегию тестирования

Про конфигурационное тестирование и тестирование на этапе сопровождения

Ну и, собственно, по этому топику:

----------------------------
5.2.1.1. Unit testing [Bei90:c1; Per95:c17; Pfl01:c8s7.3] (IEEE1008-87)

Unit testing verifies the functioning in isolation of software pieces which are separately testable. Depending on the context, these could be the individual subprograms or a larger component made of tightly related units. A test unit is defined more precisely in the IEEE Standard for Software Unit Testing (IEEE1008-87), which also describes an integrated approach to systematic and documented unit testing. Typically, unit testing occurs with access to the code being tested and with the support of debugging tools, and might involve the programmers who wrote the code.

----------------------------
Термин 'software testing process' всречается в книге только один раз, в этом контексте:
10.1.4. Software Testing Tools [Dor02, Pfl01, Rei96]

Test generators. These tools assist in the development of test cases.
Test execution frameworks. These tools enable the execution of test cases in a controlled environment where the behavior of the object under test is observed.
Test evaluation tools. These tools support the assessment of the results of test execution, helping to determine whether or not the observed behavior conforms to the expected behavior.
Test management tools. These tools provide support for all aspects of the software testing process.
Performance analysis tools. [Rei96] These tools are used for measuring and analyzing software performance, which is a specialized form of testing where the goal is to assess performance behavior rather than functional behavior (correctness).

----------------------------
Термин 'GUI testing' встречается один раз, в списке дополнительных методик тестирования.