1. Гугль все еще не переплюнут.

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

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

Я говорю что не уверен что это хороший метод. Все.

Ну то есть это примерно как начинать учить математику с изучения всей имеющейся там терминологии. Терминологию освоить может и поможет. Понять как оно работает - нет. А скорее всего только бардак в голове усилит.

Я не уверен что пытаться собрать и упорядочить over 9000 терминов это хороший способ что-то понять.

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

Я жажду подробностей этого извращения.

ручное нагрузочное тестирование

Совершенно нормальное и часто применяемое тестирование. Именно ручное, именно нагрузочное.

Я жажду подробностей этого извращения.

http://webest.net/2006/06/22/professionalnyiy-minet-ot-5-u-e.php

Это где-то очнь далеко от тестирования. Но вообще можно и как фб делать - нагрузки сразу на живых пользователях проверять.
Главное чтобы мозг рака вот до такого не добрался (а необремененный знаниями и перенасыщенный терминами мозг может): http://loadstorm.com.../happy-new-year

Это уже BDD какой-то получается. В любом случае и те и те проверки стоит скорее называть "rejection checks" а не "acceptance tests", как это принято. По смыслу корректнее получится. И в любом случае это все еще недостаточные процедуры.

Виды контроля качества должны выбираться исходя не из типа ПО, а в первую очередь из уровня культуры разработки в компании. Во вторую очередь исходя из заранее заданных требований к атрибутам качества ПО. А веб там или не веб - дело 100500-ое. "Там где моют руки - там все нормально."

Я боюсь все еще сложнее и волшебный ответ как всегда - "there is no silver bullet for this problem".
Опять же - "контроль качества" это странная фикция, просто потому что "Там где моют руки - там все нормально", например. С другой стороны, "качество" это субъективное понятие и активность тестировщика по выявлению нужных субъектов и выявлению их же нужд она +/- всегда нужна. Опять же - опеределение атрибутов качества которые нас интересуют вопрос зачастую вполне обсуждаемый: http://thetesteye.co...acteristics.pdf

Тестирование скорости и надежности (load/stress/performance testing)
Тестирование опыта пользователя (usability testing)

Таки не скорости и надежности и не опыта пользователя (который вообще UX).

Но вообще:
1. Гугль все еще не переплюнут.
2. "Общество без цветовой дифференциации штанов не имеет цели. А если нет цели - нет будущего" (с). Вопрос цели все еще не понятен.

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

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

Хотя может оно лучше так чем вообще никак. Я подумаю над этим. Это концентрация на терминах хороша только в меру.

До ваших переходов по факультетам никому нет дела. У нас есть парень, который в принципе - археолог, однако адекватно тестирует и не парит себе самосознание.

Я знаю как минимум одного филолога из тайги который в NativeDriver репы коммитит...

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

А зачем менять ip клиента? Request lib в руки и копать.

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

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

Андрей, кстати, было бы круто если бы кто-нибудь (например ты %)) собрал все эти материалы в одном месте и еще чтобы с камментами, картинками, линкой на то чтобы скачать лунапарк и все такое)

3. Какой интервал берете при сборе показателей системы - 1сек, 5сек, etc. Например как часто следует мониторить утилизацию диска. Ведь если брать интервал в 1 сек, то например за 10 часов будет такое кол-во данных что график либо не отрисуется, либо будет сильно лагать.

10 часов по секунде это всего 36к кортежей, если все в одну кучу. Ну если расстараться то больше, но линейно и не сильно, почти наверняка. Это плюш, честно.
К тому же 10 часов на один тест это совсем не торт. Много такого редко надо. А после прогона можно результаты и обработать как следует.

зы: для анализа еще матмоды ок.

Трудовая книжка в наше время это такой совковый рудимент который ни о чем не говорит.

Ой. У меня вообще SDET написано. Как дальше жить?

Каждый выбирает для себя .....
если нравится жить вне правового поле - то никто и не заставляет.


Интересно просто - а в каком документе "У меня вообще SDET написано" ?

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

А правовое поле... ну смешно, да. Если я фрилансом займусь у меня вообще пустота в трудовой будет. Я получается тестировщик-никто?

Трудовая книжка - это документ, фиксирующий Ваши взаимоотношения с работодателем. В определенных терминах -- там должность записана, а не роль. Как и в штатном расписании в РФ -- должности, а не роли.

Это рудимент полицейского государства. Как прописка, например. Или то что у вас единственное удостоверение личности это паспорт, на котором важен номер, а не фото. Вне постсоветского пространства аналогов тащемта не очень много. Мои взаимоотношения с работодателем фиксирует контракт. В контракте пишут другие вещи. Но тут наше законодательство тоже весьма отстойное.

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

Воооот.

Называть то что в 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). Так это или нет - решать тому, кто рулит проектом. Нужна ли ему эта информация или нет - так же решать ему.

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

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

Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый fake testing по James Marcus Bach (уже больше десяти лет с этим вредным явлением борется). Это вообще не совсем то, чем тестирование должно заниматься.

Если же брать мировой опыт, то, например, 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.

Простите, но после того как я увидел IEEE 1044 я эти ваши стандарты читать серьезно уже не могу. Почитайте www.satisfice.com (а лучше сразу Jerry Weinberg "Perfect Software And Other Illusions About Testing"), мне такой мировой опыт сильно ближе чем тот удаленный от реальности бред, что пишут в стандартах.

А вот единого аналитика там нет, вместо этого имеем 36 DTAN - Data analysis, 37 REQM - Requirements definition and management, 32 BSMO - Business modelling, 38 DESN - Systems design, 40 DBDS - Database/repository design и некоторые другие.

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

Текущее состояние Nokia в принципе не связано с разработкой ПО, там работают другие, макроэкономические причины. Если вам нужен успешный пример для флейма, можно взять MS, который перешел на agile - естественно, оригинальный, но на то agile и гибкий. Или внутреннюю разработку Дойча, также использующую agile для достижения вполне конкретных результатов. Skype, кстати, тоже вполне успешен. Контекст предложения про Мартина Фаулера я не понял.

Текущее состояние MS тоже напрямую с разработкой ПО никак не связано, потому что разработка ПО это, как ни крути, Cost Center. Те или иные методики могут помочь снизить затраты напрямую или косвенно, а могут не помочь. Но оно как было Cost Center так и останется. Можно взять, например SAP. Он не успешный? Я думаю вполне успешный. Или Oracle.

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

mea culpa. Не привык я к этому канцеляриту.

ЗЫ: Но вообще читаю 34.602 и то-ли там рудиментов много, то ли еще что. Почему так часто слово "общесоюзный"? Что оно означает в 2011-м году? И таки оттуда явно не стоит проецировать все на любоую разработку ПО.

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

Agile slaves как они есть, короче.