Перейти к содержимому

Публикации a66at

169 публикаций создано a66at (учитываются публикации только с 29 марта 2023)



#52332 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 01 февраля 2008 - 14:20 в QA: обеспечение качества

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

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



#52331 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 01 февраля 2008 - 14:02 в QA: обеспечение качества

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

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

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

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

Ваш вопрос звучал так

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

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

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



#52326 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 01 февраля 2008 - 13:31 в QA: обеспечение качества

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

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

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

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

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

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



#52319 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 01 февраля 2008 - 12:42 в QA: обеспечение качества

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

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

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

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

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



#52307 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 01 февраля 2008 - 10:29 в QA: обеспечение качества

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

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



#52274 QA в инженерных отраслях.

Отправлено автор: a66at 31 января 2008 - 15:26 в QA: обеспечение качества

процесс - это всего лишь набор последовательных действий.

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



#52211 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 31 января 2008 - 07:58 в QA: обеспечение качества

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

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

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

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

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

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



#52188 QA в инженерных отраслях.

Отправлено автор: a66at 30 января 2008 - 15:00 в QA: обеспечение качества

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

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

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



#52184 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 14:49 в QA: обеспечение качества

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

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

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

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



#52181 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 14:17 в QA: обеспечение качества

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



#52179 QA в инженерных отраслях.

Отправлено автор: a66at 30 января 2008 - 14:00 в QA: обеспечение качества

Если у кого не получается правильно применить стандарт, то стоит проверить, откуда руки растут, а уж потом пенять на бумажку.

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



#52176 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 13:28 в QA: обеспечение качества

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

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



#52171 QA в инженерных отраслях.

Отправлено автор: a66at 30 января 2008 - 12:35 в QA: обеспечение качества

:acute:

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

P.S. А позитивизмом я назвал позицию: "Ну вот оно же где-то работает, приносит прибыль, значит вещь стоящая, разбираться подробно не будем".



#52158 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 11:53 в QA: обеспечение качества

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

По логам и audit trail-ам. Тулы этого кстати не делают, и интеграция с ними по этому поводу бывает сложной.

Как при ограниченнном количестве людей проверите производительность системы при одновременной работе 100, 200 человек? Тут нужно что-то эмулировать, запускать ботов и т.п. Я вот про это говорил.

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



#52150 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 11:31 в QA: обеспечение качества

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

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

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

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

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

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



#52142 QA в инженерных отраслях.

Отправлено автор: a66at 30 января 2008 - 10:58 в QA: обеспечение качества

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

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



#52135 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 10:12 в QA: обеспечение качества

Если учесть, что аналогия с полетами на Луну несколько неуместна, то можно учесть следующие моменты:

Не понял, почему не уместно. В чём заключается принципиальное отличие по Вашему мнению?

1) Тестирование крайне сложно и в лучшем случае нецелесообразно автоматизировать на 100%. Даже то же Unit-тестирование если и автоматизируется на 80%, то это очень неплохой результат, а для более высокоуровневых видов показатели и к таким достаточно сложно свести в общем случае.

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

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

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

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

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

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

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

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

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



#52131 QA в инженерных отраслях.

Отправлено автор: a66at 30 января 2008 - 09:40 в QA: обеспечение качества

Пекут пирожки, булочки.

Какое это отношение имеет к инженерии? Или к "крупной" проектной деятельности?
Я не отрицаю, что QA успешно применяется при массовом производстве и обслучивании. Там даже слово "процесс" имеет смысл сходный с тем, который применяется в слупах. См. например здесь. Эти методы мне в целом ясны и я их, кстати, применяю профессионально, т.к. нагрузочные тестировщики по долгу службы часто работают с процессами массового обслуживания и (пусть иногда воображаемыми) control chart-ами.
А вот то, как SEI или кто там ещё этим делом занимается подтягивает его к денежным в настоящий момент областям, при этом ещё и осваивая федеральные фонды, действительно выглядит непонятно (и путаница в терминологии во многом из-за этого и возникла, как я могу судить). Ну а то, как это дело поняли и могут объяснить консультанты по тестированию и QA, вообще выглядит смехотворно.



#52113 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 30 января 2008 - 07:05 в QA: обеспечение качества

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

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

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

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



#52107 QA в инженерных отраслях.

Отправлено автор: a66at 29 января 2008 - 17:51 в QA: обеспечение качества


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

Могу превести такой пример
...
Да, кстати, все это было в америке.

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



#52104 Что необходимо для внедрения автоматизации тестирования ПО

Отправлено автор: a66at 29 января 2008 - 17:18 в QA: обеспечение качества

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

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



#52093 Профессия тестировщик ПО (перезапуск tester.com.ua)

Отправлено автор: a66at 29 января 2008 - 14:50 в Анонсы и обсуждения материалов it4business.ru

Мне интересна ваша точка зрения. Чтобы её понять (я местами не понимаю как видно из наших споров), я хочу понимать во что верит собеседник.

С чего Вы взяли, что я во что-то верю? К тому же, если бы такая вера существовала с чего вы взяли, что её можно было бы выразить ограниченным количеством слов?

Моя точка зрения о чём Вам интересна, о QA?
1. Я не считаю, что любое действие по предотвращению дефектов продуктов - это QA (результативные действия в этом направлении могут быть вообще индивидуальными (выполняться только одним человеком, причём успех/неуспех может зависеть от его личных качеств), не иметь формализованного, повторяемого, измеримого или вообще заметного невооружённым глазом выхода, например).
2. Я не считаю, что QA это только действия по предотвращению дефектов продуктов (собственно, ISO 9000, например, по моему мнению, утверждает, что это вообще не так, и после этого там есть ещё много букв).
3. Я считаю, что QA - это процессная область, т.е. конкретные активности уже рассматриваются как некоторые атомарные явления (ну вроде того, как переставить code review из процесса тестирования в процесс разработки, не особо заморачиваясь о том, что оно из себя конкретно представляет).
4. Эта парадигма (что можно результативно управлять чем-то, тасуя квадратики процессов/активностей и поправляя шаблоны документации, не вдаваясь в технологические особенности конкретных активностей) в основном работает (действительно работает, можете не сомневаться) в условиях статистической повторяемости (когда эти активности неизменно выполняются очень много раз, как на конвейере).
5. Инжиниринг и проектная деятельность не отличаются особой повторяемостью, поэтому такой процессный подход в них плохо работает, для принятия решений нужно отталкиваться в том числе от конкретных технических деталей, а это уже не QA (см п.1).

А про использовать чужую систему ценностей это как? :)

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



#52091 Профессия тестировщик ПО (перезапуск tester.com.ua)

Отправлено автор: a66at 29 января 2008 - 14:03 в Анонсы и обсуждения материалов it4business.ru

a66at - а уменя мнение, что это вы подменяете понятия, причем в моих словах

Да, скорее всего так и было. Утратил внимание, извиняюсь.



#52084 Профессия тестировщик ПО (перезапуск tester.com.ua)

Отправлено автор: a66at 29 января 2008 - 13:24 в Анонсы и обсуждения материалов it4business.ru

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


А сейчас вы (в отличии от слов указанного топика) во что верите?

Это так важно? Я готов использовать систему ценностей и терминологию собеседника до тех пор пока они внутренне непротиворечивы и исключают подмену понятий из какой-нибудь другой системы ценностей. :)



#52081 Профессия тестировщик ПО (перезапуск tester.com.ua)

Отправлено автор: a66at 29 января 2008 - 12:04 в Анонсы и обсуждения материалов it4business.ru

Не буду приводить доводы здесь - лучше напишу в вашем топике.

Да было бы лучше всё туда снести. Впрочем, напишете - видно будет.

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

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

А процесс у НАСА уверен, что есть.

Да есть, конечно. Но возникает вопрос, как давно он появился, при каких обстоятельствах, и стала ли организация после этого более плодотворно работать?

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

Ну и что, вы будете инвесторам с MBA рассказывать, что это и есть QA? :) Не лучше ли завести собственную терминологию, чтобы не смущать людей.

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