...

На самом деле, являясь простым обывателем, не нуждающимся в устоявшейся терминологии в области тестирования, я считаю, что 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) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.

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

2) Автоматизированные тесты только выполняются автоматически, но результат их работы оценивается человеком

Оценка результатов теста - это подпроцесс или просто активность? Т.е. он формализован, фиксирован, управляем, измерим в любом случае? Нет ли там каких-то частностей?

3) Автоматизированное тестирование является составной частью тестирования и метрики, используемые в нем, характеристики, полученные в результате их выполнения являются теми же, что и в других, сопутствующих видах тестирования

Т.е. автоматизированное тестирование принципиально без метрик и характеристик провести нельзя. Процессность в него заложена от рождения?

4) Опять же прежде чем что-то тестировать, нужно выработать стратегию, определить охват, цели и т.п. Если мы не сделаем этого и начнем писать автоматические тесты, то непонятно, что мы получим и для чего.

Опять же. Разве для выбора стратегии обязательно нужен процесс? Что вы собираетесь измерять в выборе стратегии, какие метрики? И вообще, представляю себе томик "Политика выбора стратегии тестирования" (формализация процесса).

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

Я Вам ещё раз говорю, нет таких програмных систем, которые бы нельзя было протестировать модульно (и при этом пользовательские прецеденты могут вообще не участвовать), а системы, которые нельзя или сложно протестировать через GUI есть и в большом количестве. Расклад по частотам слов в SWEBOK это косвенно подтверждает.

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

Ну т.е. стратегия это всё-таки проектный, а не процессный артефакт. :) Я согласен, процесс тестирования не нужен для выбора стратегии.

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

Я Вам ещё раз говорю, нет таких програмных систем

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

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

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

А подход к нагрузочному тестированию вшит в процесс?

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

И потом посмотреть, всё ли там необходимо и все ли эти ресурсы могут существовать только в рамках процесса регрессионного тестирования.

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

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

И как это кореллирует с утверждением, что нельзя автоматизировать то, чего нет?

Я так понимаю что Вы подразумеваете, что для автоматизации тестирования нужно чтобы существовало не само тестирование, а процесс тестирования и спрашиваю, зачем конкретно это нужно.

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

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

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

Можно вы тут пока сами? Вернусь на той неделе.

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

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

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

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

Мне показалось, что Вы хотели поспорить про приоритеты видов автоматизированного тестирования с точки зрения приносимой пользы вне контекста своей статьи, т.к. компонентное тестирование в ней не рассматривается. Я что-то путаю?

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

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

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

Ну так речь, как я понимаю, идёт о том, что некоторые тестировщики хотят делать автоматизацию (исключительно потому что это модно, приносит деньги и поглаживание по голове со стороны ISV), но не могут и не хотят делать серые и белые ящики (т.е. в некоторых случаях, когда с этого надо начинать, открыто саботируют качество). И возникает вопрос о том, нужны ли [такие] тестировщики для автоматизированного тестирования. ;)

Модуль (unit) - это логическая единица кода в процедурном языке (паскаль, например), а компонента - в объектно-ориентированном. Т.е. в обоих случаях идёт речь о сером или белом ящике.

По моему это попытка определить множество через множество. Что такое логическая единица кода?

Это так важно?
Короче, динамическое тестирование такой сущности - это модульное тестирование

UNIT unit1;INTERFACE    PROCEDURE Proc1;IMPLEMENTATIONPROCEDURE Proc1;    BEGIN         ...    END;END;

А такой - компонентное:

class Motto {  public static void main(String[] args) {    System.out.println("Java rules!");    }}

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

Всё - понял. Вы за то, что unit-тестирование полезнее и инвестировать в него правильнее и полезнее чем в средства record-playback - я верно описал вашу позицию?
Давайте в следующий раз с этого начнём? :)

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

Методику? Тиражировать? :) Я высказал в статье своё частное мнение о том, какие необходимые организационные условия (статья даже как ни странно так и называется "Что необходимо для внедрения автоматизации тестирования ПО") должны выполняться чтобы внедрение автоматизации тестирования ПО состоялось. Методика, unit-тестирование - это уже ваша часть разговора.

Тут уже, ИМХО, софистика зарождается. Предлагаю оставить способ использования статьи и комментариев на усмотрение читателя. Если хотите, уберу хинт об использовании её как методики которую можно (по форме) тиражировать.

Критику самой статьи в основных её предпосылках мне крайне интересна: с чем из основных тезисов вы не согласны. Я даже приведу цитату.

1. Мотивация руководства

2. Зафиксированный и работающий процесс тестирования

3. Ресурсы: выделенные люди, которые будут заниматься только автоматизированным тестированием + фанат своего дела

4. Если чего-то из этого нет – лучше не начинать, на выходе всё равно получится «дохлая лошадь».

Моё сообщение от 10:48.
1. Задан уточняющий вопрос о мотивации руководства;
2. Про процессы - контрпример и уточняющий вопрос про процесс тестирования (его окружение).
4. Альтернативная гипотеза о причинах провала таких проектов (при соблюдении Ваших условий всё равно возможен провал, без некоторых из них возможен успех).

А, теперь дошло. Не закапывайте смысл, а? :)

Нельзя автоматизировать несуществующий процесс тестирования. Если тестирования как выделенного вида деятельности нет, то внедрение средств автоматизированного тестирования не оправдано. Под процессом тестирования я понимаю связку "цель-задача-план-активности-результат-анализ" и выделенные ресурсы - тестировщиков ПО.

Мне уже пора. Я не уловил в Ваше статье перехода от обобщенных критериев успеха внедрения автоматизации тестирования к оправданности использования или неиспользования для этого САТ.
Процесс тестирования в Вашей терминологии возможно и нельзя будет автоматизировать, если его нет, но тестирование (активности) конечно можно автоматизировать сразу, без их предварительного существования, а статья ведь про автоматизацию тестирования (название даже соответствующее).
Вообще, я придерживаюсь мнения что автоматизация процесса тестирования - это workflow, в данном случае bugtracker, а автоматизация тестирования - это автоматическое выполнение проверок.

Я всё-таки ещё раз повнимательнее почитал статью.

необходимы всего

Это "необходимо и достаточно"?

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

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