- Форум тестировщиков
- → Публикации OVA
Публикации OVA
162 публикаций создано OVA (учитываются публикации только с 30 июня 2023)
По типу контента
По пользователю
#89275 Нагрузочное тестирование в Яндексе
Отправлено автор:
OVA
30 мая 2011 - 03:46
в
Тестирование производительности
У вас (не только у тебя, Андрей, а вообще) было много презентаций на тему того как у вас все устроено, как оно работает и как вы планируете с этим жить. Видео, слайды и прочая. Я думаю было бы очень классно, если бы их не надо было собирать по закромам разных конференций, а все они лежали в одном месте. Тем более что часто слышу и вижу ответы вида "а посмотрите вот это вот видео, потом может понятнее станет".
Я понимаю что вопросов сильно меньше не станет, но в меру ленивому мне было бы удобно. Ну а в целом для ознакомления публики, т.к. очень круто искать когда ты знаешь что искать тебе надо, но я готов поспорить что вопросы по прошлогоднему докладу из Ебурга про мяско просто так далеко не всем в голову придут.
Я понимаю что вопросов сильно меньше не станет, но в меру ленивому мне было бы удобно. Ну а в целом для ознакомления публики, т.к. очень круто искать когда ты знаешь что искать тебе надо, но я готов поспорить что вопросы по прошлогоднему докладу из Ебурга про мяско просто так далеко не всем в голову придут.
#87406 Нагрузочное тестирование в Яндексе
Отправлено автор:
OVA
21 апреля 2011 - 17:21
в
Тестирование производительности
10 часов по секунде это всего 36к кортежей, если все в одну кучу. Ну если расстараться то больше, но линейно и не сильно, почти наверняка. Это плюш, честно.3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.
К тому же 10 часов на один тест это совсем не торт. Много такого редко надо. А после прогона можно результаты и обработать как следует.
зы: для анализа еще матмоды ок.
#88998 Нагрузочное тестирование в Яндексе
Отправлено автор:
OVA
26 мая 2011 - 03:19
в
Тестирование производительности
Андрей, кстати, было бы круто если бы кто-нибудь (например ты %)) собрал все эти материалы в одном месте и еще чтобы с камментами, картинками, линкой на то чтобы скачать лунапарк и все такое)
#96860 Разновидности тестирования.
Отправлено автор:
OVA
10 ноября 2011 - 11:28
в
Про тестирование обо всём подряд
Это где-то очнь далеко от тестирования. Но вообще можно и как фб делать - нагрузки сразу на живых пользователях проверять.http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php
Я жажду подробностей этого извращения.
Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.ручное нагрузочное тестирование
Главное чтобы мозг рака вот до такого не добрался (а необремененный знаниями и перенасыщенный терминами мозг может): http://loadstorm.com.../happy-new-year
#96866 Разновидности тестирования.
Отправлено автор:
OVA
10 ноября 2011 - 11:40
в
Про тестирование обо всём подряд
Я боюсь все еще сложнее и волшебный ответ как всегда - "there is no silver bullet for this problem".Виды контроля качества должны выбираться исходя не из типа ПО, а в первую очередь из уровня культуры разработки в компании. Во вторую очередь исходя из заранее заданных требований к атрибутам качества ПО. А веб там или не веб - дело 100500-ое. "Там где моют руки - там все нормально."
Опять же - "контроль качества" это странная фикция, просто потому что "Там где моют руки - там все нормально", например. С другой стороны, "качество" это субъективное понятие и активность тестировщика по выявлению нужных субъектов и выявлению их же нужд она +/- всегда нужна. Опять же - опеределение атрибутов качества которые нас интересуют вопрос зачастую вполне обсуждаемый: http://thetesteye.co...acteristics.pdf
#96890 Разновидности тестирования.
Отправлено автор:
OVA
10 ноября 2011 - 16:05
в
Про тестирование обо всём подряд
Это уже BDD какой-то получается. В любом случае и те и те проверки стоит скорее называть "rejection checks" а не "acceptance tests", как это принято. По смыслу корректнее получится. И в любом случае это все еще недостаточные процедуры.
#96787 Разновидности тестирования.
Отправлено автор:
OVA
08 ноября 2011 - 17:50
в
Про тестирование обо всём подряд
Если бы все было так просто... Бета-тестирование белого ящика это конечно хорошо. Ровно как и приемочные тесты которые никогда и низачто не могут быть регрессионными (ручное нагрузочное тестирование обоземойнекраудсорсинг). От таких выводов приходится потом санитарию голов делать.Но действительно начинающему тестировщику так проще понимать, ибо:
-- если два термина находятся в разных классификациях, значит, они достаточно ортогональны и их можно комбинировать,
-- если два термина находятся в одной классификации, значит, они достаточно взаимоисключающие.
Хотя может оно лучше так чем вообще никак. Я подумаю над этим. Это концентрация на терминах хороша только в меру.
#96832 Разновидности тестирования.
Отправлено автор:
OVA
10 ноября 2011 - 03:50
в
Про тестирование обо всём подряд
Я жажду подробностей этого извращения.Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.ручное нагрузочное тестирование
#96662 Разновидности тестирования.
Отправлено автор:
OVA
06 ноября 2011 - 16:05
в
Про тестирование обо всём подряд
Я не уверен что пытаться собрать и упорядочить over 9000 терминов это хороший способ что-то понять.
#96666 Разновидности тестирования.
Отправлено автор:
OVA
06 ноября 2011 - 18:21
в
Про тестирование обо всём подряд
Я говорю что не уверен что это хороший метод. Все.
Ну то есть это примерно как начинать учить математику с изучения всей имеющейся там терминологии. Терминологию освоить может и поможет. Понять как оно работает - нет. А скорее всего только бардак в голове усилит.
Ну то есть это примерно как начинать учить математику с изучения всей имеющейся там терминологии. Терминологию освоить может и поможет. Понять как оно работает - нет. А скорее всего только бардак в голове усилит.
#96660 Разновидности тестирования.
Отправлено автор:
OVA
06 ноября 2011 - 14:46
в
Про тестирование обо всём подряд
Таки не скорости и надежности и не опыта пользователя (который вообще UX).Тестирование скорости и надежности (load/stress/performance testing)
Тестирование опыта пользователя (usability testing)
Но вообще:
1. Гугль все еще не переплюнут.
2. "Общество без цветовой дифференциации штанов не имеет цели. А если нет цели - нет будущего" (с). Вопрос цели все еще не понятен.
#96714 Разновидности тестирования.
Отправлено автор:
OVA
07 ноября 2011 - 15:23
в
Про тестирование обо всём подряд
О да, разбивка конечно же очень поможет. Вместо беспорядочной нерелевантной ерунды будет упорядоченная нерелевантная ерунда вызывающая много вопросов касательно методов классификации.По ссылке - нет разбивки по классификационным признакам. Получилась каша.
1. Гугль все еще не переплюнут.
#97363 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
21 ноября 2011 - 05:49
в
Портал Software-Testing.Ru
Первое и самое главное - это "их число все увеличивается" это ваше субьективное мнение или у вас есть хорошая такая статистика с указанием источников и так далее?Дело в том, что большое количество проектов связано с развитием уже существующих продуктов. И даже при разработке нового продукта обычно достаточно быстро возникает некоторая минимальная версия, показываемая заказчику. И процессы формулирования требований, разработки и тестирования идут параллельно, с некоторым отставанием, и, более того, все это замкнуто быстрой обратной связью от заказчика. В этих условиях активности тестирования и аналитики оказываются очень сильно похожи. Я говорю именно о таких проектах, а их число все увеличиваются - многие заказчики начинают сильно ценить быструю обратную связь и инициируют перестройку процесса. А вот обратного хода, к более структурированному процессу - не видно.
Второе, не такое главное - не вижу чем они становятся очень похожи. Еще раз - на мой взгляд без купирования активностей по этим направлениям нет возможности заниматься эффективно аналитикой и тестированием одновременно. Складывается ощущение, что вы говорите про какой-то сильно узкоспециальный артефакт работающий только в определенных условиях как с точки зрения процессаа, так и с точки зрения внешних влияний на проект. Это, имхо, такой же рудимент как и команды живущие на голом BDD (для кого-то работает, но многие так и не могут заставить это взлететь, да и тестированием я не могу это назвать толком). Обобщать это на тестирование никак нельзя. Я не вижу как можно заниматься нагрузочным тестированием и аналитикой, например.
Третье - это все, как я понимаю, про аутсорсинг?
#97277 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
17 ноября 2011 - 18:48
в
Портал Software-Testing.Ru
И в то же время указал, что в стандартах вроде как есть согласие на счет того что такое тестировщик. Т.е., есть основание полагать что там вопросов у Максима нет. У меня есть.Сергей, тебе враги тестирования уже мерещатся всюду :)
Максим указал на то, что в стандартах (которые вроде бы ради всемирного порядка создаются) и то нет согласия относительно такой роли как "аналитик". Вы с Бахом не согласны с этим?
Или может быть ты лично являешься сторонником строгого разделения, чётких должностных инструкций, "тестировщик не имеет права фиксить баги, потому что он не девелопер" и так далее? Что-то я сомневаюсь :)
Это опять кажущиеся враги :)
Никто же не утверждал, что тестировщик должен обеспечивать результат личным подвигом, а все вокруг должны стоять и восхищенно смотреть.
Речь шла о том, что если тестировщик что-то делает исходя исключительно из личных высочайших стандартов качества, он может сильно промазать мимо цели, если не будет интересоваться, а чего, собственно, хочет заказчик.
Про баги...
Я фиксил баги. Более того, я их на горячую фиксил. Не вижу в этом ничего хорошего. Я это мог делать только потому что для этого хватало моих знаний на тот момент. Если бы проблема была более серьезной, то никак не справился бы. Я фиксил баги в софте для тестирования который сам же писал. Но это другое, потому что это система которую я писал, я знаю зачем она мне нужна и я знаю что там чинить. Фиксить баги в тестируемом софте на регулярной основе? Я боюсь у меня бы тогда времени на тестирование совсем не осталось.
Я не дизайнер. Но у меня есть свое мнение насчет дизайна. Только не думаю что мне стоит заниматься дизайном, т.к. моих знаний на это не хватит. Это не в моей компетенции. А чтобы это стало в моей компетенции мне придется очень долго заниматься тем, что сильно отличается от тестирования. Долго. В итоге получится морская свинка.
Могу про футбол добавить, но это будет уже совсем театр абсурда.
А тестировщик работающих только исходя из своих личных высших стандартов это плохой тестировщик.
Оценивать требования? Да. Все ли согласовано и нет ли там дыр? Arnold's Laws of Documentation вспоминаются. Все не согласуешь. Дыры будут. Надо другой вопрос задавать. Более того - есть люди вообще без документации работающие и ничего.Давайте попробуем вот так переформулировать: нужно ли тестировщику "заниматься анализом"? (я намеренно не говорю "работать аналитиком")
Должен ли тестировщик оценивать требования, пытаться понять, всё ли там согласовано и нет ли дыр?
Следует ли тестировщику пытаться соотносить то, что делает программа, с реальными потребностями пользователей, или следует лишь "блюсти букву спецификации" (ибо не дело тестировщика вмешиваться в работу "аналитика")?
Действительно ли это такая уж ортогональная активность? Может всё таки немного параллельная?
Соотносить то что делает программа с реальными потребностями пользователей? Опять же в меру. У меня нет потребности в рекламе в гугле. Более того - она меня порой раздражает. Баннеры - одна из причин по которым я не пользуюсь Яндексом, например. У меня опять нет однозначного ответа на этот вопрос. Надо еще вопросы. Мне их задать?
Меня как математика фраза "немного параллельная" вымораживает. Надо другую.
Активность пересекается.
Для составления требований совсем не нужен продукт, но нужна глубокая проработка кучи вопросов. Сам процесс разработки требований тестировщику пользы мало приносит. А вот результат может быть полезен.
Для тестирования нужно хоть что-то. Потому что нельзя тестировать ничто (хотя...). Требования это просто вспомогательный инструмент в тестировании. Причем в ряде случаев можно вообще без них обойтись. Опять же вспоминаем Arnold's Laws of Documentation, Five Orders Of Ignorance и прочее. система до разработки, в процессе и после это зачастую разные сущности. Разные знания. Внутренности готовой системы, выпущенной в мир и работающей, аналитику, для разработки дальнейших требований, нужны в довольно урезанном виде. У тестировщика исследование самой системы по сути основная деятельность.
Так что еще раз - активность разная, она требует фокусировки на разных вещах. Точки пересечения есть, но их мало и они не позволяют делать одновременно две работы. Экономить на обучении - вполне возможно. Экономить на выполняемой работе - нет. И если внезапно появляются большие объемы работы требующие детальной проработки в тестировании, то ни о какой разработке требований ближайшие много-много времени речи не будет. И наоборот.
#97464 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
22 ноября 2011 - 11:26
в
Портал Software-Testing.Ru
Воооот.
Называть то что в MS agile можно только с очень большой натяжкой. Да, они о нем говорят, но то, что у них сейчас есть очень далеко от agile manifesto и нет никаких оснований полагать, что там все быстро-быстро утрясется.
При этом есть основания полагать, что с MS как и в Nokia тяготеют к ортодоксальному agile с сертифицированными скрам мастерами и прочими ритуалами. Просто потому что крупным организациям с сертификатами работать проще.
Считать что Agile шагает по миру семимильными шагами можно, но насколько семимильными никто из нас не знает. Никто не знает сколько особо ортодоксального Agile, сколько действительно гибких контор. Т.е. то что есть тренд отрицать трудно. Качество его выхлопа оценить практически невозможно. Общение на конференциях, увы, не столько показатель качества выхлопа, сколько показатель тренда. Т.к. между трендом и реальностью может существовать огромный разрыв, масштабы которого оценить не представляется возможным.
Промежуточный вывод у меня как и прежде:
1. Говорят много
2. Говорят практически все
3. У кого-то действительно работает и очень похоже на agile как оно и задумывалось
4. Никаких других выводов касательно КПД перевода количества разговоров в качество процесса мы сделать не можем, т.к. нужных данных нет и ближайшее время не предвидится. Т.е. ставить равенство между словами "agile" и "успешность" по меньшей мере спекуляция
Собственно то, о чем я с самого начала и говорил.
Теперь про тестирование.
Автоматические тесты хороши для одной цели - повышение продуктивности. unit->api->gui Тесты это стандартная пищевая цепочка, которая в купе с нормально поставленной работой с CI позволяет на выходе получить более качественный код. Меньше будет тратиться времени на неработающие билды и билда, где почти вся функциональность заблокирована. Экономия налицо, как говорится: "If you think test-first is expensive, try debug-later".
Второй полезный тренд, это вещи типа Continuous Deployment/Delivery + модные на западе (и еще не очень докатившиеся до нас) DevOps. Там очень много практик по раннему обнаружению дефекта не только через тесты, но и через нормальные логи, мониторинги, обработку ошибок и все то, что раньше называлось словом Testability. Обнаружению в том числе на продакшене, т.к. для ряда компаний типа Google это оправданное поведение. Им дешевле чинить баги по мере обнаружения их пользователем.
Это все отличная практика, позволяющая практически избавиться от того тестирования, которое в context-driven school принято называть словом "checking". Т.е. сверка того, что по заявленным сценариям приложение работает, что соответствие требованиям соблюдено (тут я люблю приводить в пример итальянскую забастовку).
Они хороши, когда мы прекрасно понимаем с чем имеем дело. Т.е. делаем все это правильно. Как делать правильно? Это найти очень сложно. Об этом практически нигде не говорят и не пишут. Пишут о том как сделать миллиарды тестов в секунду в облачную пустоту. Это технически не очень трудно, кстати.
Одно из проявлений проблем связанных с непониманием цели и области применения автоматических проверок - Automation Bias. Почитать можно тут: http://citeseerx.ist...p=rep1&type=pdf
Это проблема не только автоматических тестов. Поэтому в Штатах, например, есть целые институты, которые ею занимаются.
Для того чтобы избегать этого и многих других рисков и нужны тестировщики (согласно context-driven school, опять же). Так как для решения проблем Automation Bias, например, нужны люди понимающие все риски автоматических экспериментов, то чего они показывают и что нужно еще проверять. Нужны люди, которые будут заниматься дизайном автоматических тестов (не той детской шалостью под названием "комбинаторные методы", а реальным дизайном). Нужны эксперименты, которые полностью автоматически провести никак нет возможности.
Иначе мы рискуем запускать в космос ракеты, которые проверены только на то, что еслив них задуть дыма, то он никуда не выйдет. Может они полетят. Может нет. А может мы как гугль грохнем несколько терабайт пользовательских писем. Или как фликр грохнем случайно несколько тысяч платных аккаунтов. И хорошо, если проект, как гугль или фликр, не потонет после этого.
В том же нагрузочном тестирование постановка теста и прогон его занимают довольно мало времени (спросите граждан из Яндекса, они про это часто рассказывают), а вот анализ результатов и всякий performance tuning - существенно больше. Делать его автоматически не получится, увы.
Если вы считаете, что у вас нет никаких рисков, которые вы не можете выявить автоматическими проверками, то вам эти эксперименты не понадобятся. Тогда вам не понадобится тестировщик, который будет ставить несколько более сложные эксперименты и проводить исследования (о том какие это могут быть исследования можно поговорить отдельно, но коротко наброшу еще - ux testing, security testing). Так это или нет - решать тому, кто рулит проектом. Нужна ли ему эта информация или нет - так же решать ему.
Это, в кратце, то что я понимаю под тестированием. Сверка продукта с требованиями по заранее заготовленному чеклисту это не тестирование.
Называть то что в MS agile можно только с очень большой натяжкой. Да, они о нем говорят, но то, что у них сейчас есть очень далеко от agile manifesto и нет никаких оснований полагать, что там все быстро-быстро утрясется.
При этом есть основания полагать, что с MS как и в Nokia тяготеют к ортодоксальному agile с сертифицированными скрам мастерами и прочими ритуалами. Просто потому что крупным организациям с сертификатами работать проще.
Считать что Agile шагает по миру семимильными шагами можно, но насколько семимильными никто из нас не знает. Никто не знает сколько особо ортодоксального Agile, сколько действительно гибких контор. Т.е. то что есть тренд отрицать трудно. Качество его выхлопа оценить практически невозможно. Общение на конференциях, увы, не столько показатель качества выхлопа, сколько показатель тренда. Т.к. между трендом и реальностью может существовать огромный разрыв, масштабы которого оценить не представляется возможным.
Промежуточный вывод у меня как и прежде:
1. Говорят много
2. Говорят практически все
3. У кого-то действительно работает и очень похоже на agile как оно и задумывалось
4. Никаких других выводов касательно КПД перевода количества разговоров в качество процесса мы сделать не можем, т.к. нужных данных нет и ближайшее время не предвидится. Т.е. ставить равенство между словами "agile" и "успешность" по меньшей мере спекуляция
Собственно то, о чем я с самого начала и говорил.
Теперь про тестирование.
Автоматические тесты хороши для одной цели - повышение продуктивности. unit->api->gui Тесты это стандартная пищевая цепочка, которая в купе с нормально поставленной работой с CI позволяет на выходе получить более качественный код. Меньше будет тратиться времени на неработающие билды и билда, где почти вся функциональность заблокирована. Экономия налицо, как говорится: "If you think test-first is expensive, try debug-later".
Второй полезный тренд, это вещи типа Continuous Deployment/Delivery + модные на западе (и еще не очень докатившиеся до нас) DevOps. Там очень много практик по раннему обнаружению дефекта не только через тесты, но и через нормальные логи, мониторинги, обработку ошибок и все то, что раньше называлось словом Testability. Обнаружению в том числе на продакшене, т.к. для ряда компаний типа Google это оправданное поведение. Им дешевле чинить баги по мере обнаружения их пользователем.
Это все отличная практика, позволяющая практически избавиться от того тестирования, которое в context-driven school принято называть словом "checking". Т.е. сверка того, что по заявленным сценариям приложение работает, что соответствие требованиям соблюдено (тут я люблю приводить в пример итальянскую забастовку).
Они хороши, когда мы прекрасно понимаем с чем имеем дело. Т.е. делаем все это правильно. Как делать правильно? Это найти очень сложно. Об этом практически нигде не говорят и не пишут. Пишут о том как сделать миллиарды тестов в секунду в облачную пустоту. Это технически не очень трудно, кстати.
Одно из проявлений проблем связанных с непониманием цели и области применения автоматических проверок - Automation Bias. Почитать можно тут: http://citeseerx.ist...p=rep1&type=pdf
Это проблема не только автоматических тестов. Поэтому в Штатах, например, есть целые институты, которые ею занимаются.
Для того чтобы избегать этого и многих других рисков и нужны тестировщики (согласно context-driven school, опять же). Так как для решения проблем Automation Bias, например, нужны люди понимающие все риски автоматических экспериментов, то чего они показывают и что нужно еще проверять. Нужны люди, которые будут заниматься дизайном автоматических тестов (не той детской шалостью под названием "комбинаторные методы", а реальным дизайном). Нужны эксперименты, которые полностью автоматически провести никак нет возможности.
Иначе мы рискуем запускать в космос ракеты, которые проверены только на то, что еслив них задуть дыма, то он никуда не выйдет. Может они полетят. Может нет. А может мы как гугль грохнем несколько терабайт пользовательских писем. Или как фликр грохнем случайно несколько тысяч платных аккаунтов. И хорошо, если проект, как гугль или фликр, не потонет после этого.
В том же нагрузочном тестирование постановка теста и прогон его занимают довольно мало времени (спросите граждан из Яндекса, они про это часто рассказывают), а вот анализ результатов и всякий performance tuning - существенно больше. Делать его автоматически не получится, увы.
Если вы считаете, что у вас нет никаких рисков, которые вы не можете выявить автоматическими проверками, то вам эти эксперименты не понадобятся. Тогда вам не понадобится тестировщик, который будет ставить несколько более сложные эксперименты и проводить исследования (о том какие это могут быть исследования можно поговорить отдельно, но коротко наброшу еще - ux testing, security testing). Так это или нет - решать тому, кто рулит проектом. Нужна ли ему эта информация или нет - так же решать ему.
Это, в кратце, то что я понимаю под тестированием. Сверка продукта с требованиями по заранее заготовленному чеклисту это не тестирование.
#98074 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
02 декабря 2011 - 04:00
в
Портал Software-Testing.Ru
Я, возможно, опять покажусь занудой, но у меня magic numbers всегда вызывают подозрения.Тут вот какая ситуация. Размер эффективно работающей команды для сложных задач - 5-7 человек. Это выявлено на опыте и проверено экспериментально, например, Белбиным. При большем количестве человек - возрастают накладные расходы на коммуникации, при меньшем - не хватает разнообразия личностей. Потому что команда действительно должна работать автономно, не нуждаясь во внешнем вмешательстве, что, в том числе, означает дублирование, достаточное чтобы болезнь или отпуск одного человека не сказались на автономности команды (а в идеале - если при двух отсутствующих она все равно работала). При таком ограничении сверху внутри команды не может быть слишком много специализаций, и они должны касаться тех активностей, которых много. Собственно, поэтому мы пришли к тому, что роли аналитика и тестировщика совмещаются - тогда в команде есть разработчики, аналитики-тестировщики и еще руководитель, для которого тоже обычно есть дублер.
"Для решения сложных задач" звучит как "среднее по больнице". Я видел команды меньше (больше, кстати, редко видел) и им всего хватало. Не назвал бы их задачи простыми. Для разных задач нужны разные наборы специализаций.
Мне в свое время довелось работать в команде, размер которой менялся от 2 до 8 человек на разных стадиях проекта. Это работало. Более того - ничего страшного в этом небыло, т.к. объемы работ менялись время от времени, а в компании производили продукты такие, что переключение с одного на другой много времени не занимало.
В достаточно больших проектах опять же приходится разбивать работы по проекту на несколько комнд.
Кстати, в командах с руководителями я не работал уже года четыре как.
Это для вас тестирование производительности это временная активность. Для ряда продуктов она практически непрерывная. В ряде случае оно решается проще - выделенные команды дизайнеров/администраторов/нагрузки/прочих специалистов. Часто, кстати, команда консультирует профессионала, а не наоборот.Если брать специфические активности, например, тестирование производительности или тестирование юзабилити интерфейса, то это - временная активность в ходе проекта. Соответственно, вариантами является аутсорсинг профессионалу (наружу команды), или временное введение профессионала в команду, или привлечение профессионала как консультанта. С моей точки зрения, нынешний тренд - возлагать на команду с консультациями профессионала, в отличие от предыдущего тренда - передачи профессионалам. Все это не исключает проектов, где соответствующие требования - критичны, и потому в команде должны быть профессионалы с опытом по ним.
Я не люблю тренды, потому, что они бессмысленны сами по себе. Это просто шаблоны, которые ни к чему не обязывают и ничего не гарантируют. У всех свой контекст. У всех своя специфика проектов/задач/людей/законодательства/прочаяпрочая. Перекладывать на них тренды в слепую глупо, так что в итоге все равно нужно делать свое.
ЗЫ: Кстати, в фазу тестирования я уже давно не верю. Но это отдельный разговор.
#97234 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
17 ноября 2011 - 12:12
в
Портал Software-Testing.Ru
Пруф на поржать, например: http://www.satisfice...ations/fake.pdfПруфлинк?
Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый fake testing по James Marcus Bach (уже больше десяти лет с этим вредным явлением борется). Это вообще не совсем то, чем тестирование должно заниматься.
И вообще, с чем именно борется товарищ Бах? Я вижу в Вашей дискуссии с Максимом вот что:
М: Тестирование должно обеспечивать результат для заказчика, а не просто стремиться к "умозрительному высокому качеству"
С: Бах считает иначе, называя стремление обеспечить результат для заказчика ругательным словом "fake testing"
Предполагаю, что просто в пылу спора утрачена логическая связь, давайте постараемся восстановить её.
Там как раз про те тонны стандартов, которые тут maksiq и SALar приводят как то, чем является тестировщик. Про тот сабботаж, который называется в стандартах "perform as specified".
Контрпример это:
"отвечать за пуговицы" и "Который отличен от умозрительно 'высокого качества покрытого тестами продукта'".
Тестировщик не отвечает за качество. Не может никак просто.
С другой стороны maksiq предлагает "обеспечивать результат для заказчика". Увы это тестировщик тоже никак не может сделать, т.к. он не менеджер и фискальные роли по надзору за людьми с пенетрационными функциями не выполняет.
"Приемлемое качество", да, хорошая концепция. Но опять же - тестировщик не обеспечивает его. Его обеспечивает процесс/команда/менеджер принимающий решения.
То есть я рад, что описанные в стандартах тестировщики уже осознаны гражданами как недостаточные. Это хорошо. На этом месте можно почитать, например, тех людей, которые с этими стандартами борются. Попытаться понять почему. Попытаться осмыслить какую роль тестировщика они предлагают (тут можно написать много слов про многие "успешные" компании, но я так не люблю). А вместо этого топикстартер предлагает прилепить ортогональную активность с совершенно другими целями. Это мне уже не нравится.
#98680 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
14 декабря 2011 - 05:44
в
Портал Software-Testing.Ru
Не вижу причин почему внешние интерфейсы должны быть зациклены на одну персону.Зрелая команда не нуждается в непосредственном руководстве, но персонализация внешних интерфейсов сохраняется.
Я вполне нормально отношусь к agile. Я плохо отношусь к продаже silver bullets, неосмысленным ритуалам и к тому когда выдают желаемое за действительное, даже если они очень похожи.Для нас (то есть для разработки в нашей компании) тестирование - постоянная активность, потому что идет постоянное развитие с частыми релизами, для некоторых проектов они еженедельные. Но если говорить об отрасли в целом, то достаточно много проектов разовой разработки с последующим внедрением, либо редкий выпуск релизов. Впрочем, agile-подходы, столь нелюбимые Вами, действительно привели к тому, что тестирование становится постоянной активностью, этот тренд - есть.
Ну и еще раз - я всю жизнь работаю в "продуктовых лавках", где одноразовых проектов практически не существует. Т.е. с моей точки зрения тестирование как было постоянной активностью, так ей и осталось и "заслуг" agile тут в принципе нет.
Да и в целом тесторование всегда было настолько постоянным насколько вам хотелось. Не более и не менее
Слишком вольная метафора. Тренд это просто тенденция. Много agile это тренд. Рост популярности соцсетей это тренд. Угги у девочек на ногах это тренд. Но в большинстве своем IT-контора это не модная девочка и для нее следование трендам далеко не всегда не самоцель.Это можно перефразировать как "я не люблю учебники, потому что они бессмысленны сами по себе. Это просто знания, теория в лучшем случае шаблоны решения каких-то умозрительных задач. Они ничего не гарантируют в реальной жизни. Для каждой задачи все равно приходится искать свой метод решения."
#96898 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
11 ноября 2011 - 04:25
в
Портал Software-Testing.Ru
mea culpa. Не привык я к этому канцеляриту.
ЗЫ: Но вообще читаю 34.602 и то-ли там рудиментов много, то ли еще что. Почему так часто слово "общесоюзный"? Что оно означает в 2011-м году? И таки оттуда явно не стоит проецировать все на любоую разработку ПО.
ЗЫ: Но вообще читаю 34.602 и то-ли там рудиментов много, то ли еще что. Почему так часто слово "общесоюзный"? Что оно означает в 2011-м году? И таки оттуда явно не стоит проецировать все на любоую разработку ПО.
#96977 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
13 ноября 2011 - 16:58
в
Портал Software-Testing.Ru
Agile slaves как они есть, короче.
#96953 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
12 ноября 2011 - 13:15
в
Портал Software-Testing.Ru
Самое забавное что каждая вторая agile-агитка предполагает демонизацию водопада через демонтрации совершенно уродских воплощений водопада. При этом скромно умалчивая про весь кошмарный agile.
Второе - кроссфункциональность в виде толпы клонов умеющих все это бред даже больший чем сертифицированные scrum-мастера.
Второе - кроссфункциональность в виде толпы клонов умеющих все это бред даже больший чем сертифицированные scrum-мастера.
#97002 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
14 ноября 2011 - 08:08
в
Портал Software-Testing.Ru
Демонизация Agile в топиках случается сама, когда начинается беседа на баззвордах и процесс ради процесса плавно перерастающий в ортодоксальную мессу.2. Критики совмещения ролей -- не стоит демонизировать и Agile тоже, призывая образы "клонов, умеющих всё", потому что в контексте agile речь как правило идёт о кроссфункциональных командах, а не специалистах.
Пруф, пруф, пруф (продолжите сами)
#97050 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
14 ноября 2011 - 15:35
в
Портал Software-Testing.Ru
Если вместо недоаналитика и недотестировщика взять просто двух нормальных спецов, то получится еще лучше, я думаю.Что же касается совмещения не навыков, но ролей, то совмещение ролей аналитика и тестировщика позволяет серьезно, а иногда и кардинально уменьшить трудозатраты на один и тот же объем работ. Если вместо недоаналитика и недотестировщика взять нормального кроссфункционального спеца, то часто можно еще и пару кодировщиков из проекта вывести и все равно сделать проект быстрее.
Про трудозатраты и объем работ я не понял, ровно как и про то откуда взялись лишние программисты (не будем их кодировщиками называть, ладно?) в проекте.
#97217 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
17 ноября 2011 - 10:25
в
Портал Software-Testing.Ru
Текущее состояние MS тоже напрямую с разработкой ПО никак не связано, потому что разработка ПО это, как ни крути, Cost Center. Те или иные методики могут помочь снизить затраты напрямую или косвенно, а могут не помочь. Но оно как было Cost Center так и останется. Можно взять, например SAP. Он не успешный? Я думаю вполне успешный. Или Oracle.Текущее состояние Nokia в принципе не связано с разработкой ПО, там работают другие, макроэкономические причины. Если вам нужен успешный пример для флейма, можно взять MS, который перешел на agile - естественно, оригинальный, но на то agile и гибкий. Или внутреннюю разработку Дойча, также использующую agile для достижения вполне конкретных результатов. Skype, кстати, тоже вполне успешен. Контекст предложения про Мартина Фаулера я не понял.
Я видел как продают за сумасшедшие деньги (удачно, с хорошим таким ростом продаж) плохой софт, разработанный по RUP. И видел как уходят вникуда agile-стартапы. Корелляция "успешности" того или иного продукта и "agile" для меня мягко говоря не очевидна (там все сложнее, чем просто знак "="). А то что вы пишите это как раз попытка сделать "успешность=agile". По крайней мере оно так выглядит и вы не делаете ничего, чтобы говорить о том что на самом деле, вместо чрезмерного рекламного упрощения.
#97221 Максим Цепков: Аналитик и Тестировщик в одном лице – путь к качеству
Отправлено автор:
OVA
17 ноября 2011 - 10:39
в
Портал Software-Testing.Ru
Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый fake testing по James Marcus Bach (уже больше десяти лет с этим вредным явлением борется). Это вообще не совсем то, чем тестирование должно заниматься.В той формулировке, которая обозначена у меня в статье мы имеем роль с обозначенными границами ответственности. Которая эффективно реализуется на практике. Естественно, определенная девальвация гордости за квалификацию в узкой специализации происходит, потому что тебе надо не просто "отвечать за пуговицы", а обеспечивать результат для заказчика. Который отличен от умозрительно "высокого качества покрытого тестами продукта" - которое просто никому не нужно, нужно "приемлемое качество".
Простите, но после того как я увидел IEEE 1044 я эти ваши стандарты читать серьезно уже не могу. Почитайте www.satisfice.com (а лучше сразу Jerry Weinberg "Perfect Software And Other Illusions About Testing"), мне такой мировой опыт сильно ближе чем тот удаленный от реальности бред, что пишут в стандартах.Если же брать мировой опыт, то, например, SFIA выделяет тестировщика как 45 TEST - Testing: The concurrent lifecycle process of engineering, using and maintaining testware (test cases, test scripts, test reports, test plans, etc) to measure and improve the quality of the software being tested. Testing embraces the planning, design, management, execution and reporting of tests, using appropriate testing tools and techniques and conforming to agreed standards (such as ISO 29119), to ensure that new and amended systems, configurations, packages, or services, together with any interfaces, perform as specified.
Еще раз - тестирование и формулирование требований (это же под аналитикой понимается в этом топике?) это две ортогональные активности. И там и там можно применять одни и те же навыки, но цели разные. Я вижу только одну причину совмещать - если у вас нет работы для одного человеко-аналитика и одного человеко-тестировщика. Тогда ок, совмещайте. В противном случае будет человек которому будет не хватать времени на то чтобы полноценно заниматься тестированием и написанием требований одновременно.А вот единого аналитика там нет, вместо этого имеем 36 DTAN - Data analysis, 37 REQM - Requirements definition and management, 32 BSMO - Business modelling, 38 DESN - Systems design, 40 DBDS - Database/repository design и некоторые другие.
- Форум тестировщиков
- → Публикации OVA
- Политика Конфиденциальности
- Правила форума ·