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

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

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

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

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

Пруфлинк?

И вообще, с чем именно борется товарищ Бах? Я вижу в Вашей дискуссии с Максимом вот что:
М: Тестирование должно обеспечивать результат для заказчика, а не просто стремиться к "умозрительному высокому качеству"
С: Бах считает иначе, называя стремление обеспечить результат для заказчика ругательным словом "fake testing"

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

Пруф на поржать, например: http://www.satisfice...ations/fake.pdf
Там как раз про те тонны стандартов, которые тут maksiq и SALar приводят как то, чем является тестировщик. Про тот сабботаж, который называется в стандартах "perform as specified".

Контрпример это:
"отвечать за пуговицы" и "Который отличен от умозрительно 'высокого качества покрытого тестами продукта'".

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

"Приемлемое качество", да, хорошая концепция. Но опять же - тестировщик не обеспечивает его. Его обеспечивает процесс/команда/менеджер принимающий решения.

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

Воооот.

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

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

Зрелая команда не нуждается в непосредственном руководстве, но персонализация внешних интерфейсов сохраняется.

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

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

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

Это можно перефразировать как "я не люблю учебники, потому что они бессмысленны сами по себе. Это просто знания, теория в лучшем случае шаблоны решения каких-то умозрительных задач. Они ничего не гарантируют в реальной жизни. Для каждой задачи все равно приходится искать свой метод решения."

Слишком вольная метафора. Тренд это просто тенденция. Много agile это тренд. Рост популярности соцсетей это тренд. Угги у девочек на ногах это тренд. Но в большинстве своем IT-контора это не модная девочка и для нее следование трендам далеко не всегда не самоцель.

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

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

Простите, но вот то что вы привели как контрпример это и есть тот самый пресловутый 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 и некоторые другие.

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

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

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

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

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

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

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

Spike load - сколько угодно. Ultimate Thread Group позволяет его организовать. Свежи-сочни Throughput Shaper - тоже.

Данные с удаленной машинки я тоже предпочел бы собирать по-другому. Но увы - нормального универсального решения без агента не нашлось. Хотя в начале я очень-очень хотел без агента обойтись. Но ведь без этого решения в ЖМетре вообще ничего нет! Плюсы перевешивают.

Оу, значит пропустил. Надо будет покопаться на досуге.

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

В какую, если не секрет?

Торговля наркотиками, оружием и прочая работорговля. Говорят там гешефт сейчас самый большой.

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

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

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

Писать на перле? Боженька упаси!

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

надеюсь понятно обьяснила.

Вот это, кстати, я категорически не понимаю.

Суть поста в том, что хотелось бы иметь какой-то инструмент (если таковой имеется), чтобы лучше локализовывать баги.

Основной инструмент тестировщика это его мозг. Все остальные инструменты применяются когда мозга уже явно недостаточно (я не про наркотики!)

почему именно на перле?)
мало ли кто с чем и как работает то)

Потому что читать я его могу. Писать на нем желания не возникает от слова "вообще".

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

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

Вы не поймете если вы занимаетесь только автоматизированным тестированием.

Я занимаюсь очень разным тестированием. В том числе не очень автоматизированным тестированием в местах где GUI не светит.

Не знаю)
возможно, но сомнительно.

"Я могу печатать до 9000 знаков в минуту, правда фигня какая-то получается" (с)

Конечно :) Писать код намного проще :)

Смотря какой

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

Вы не поверите, но читать код и писать код это две большие разницы.

ЗЫ: У меня нет должностной инструкции. У меня теперь нет обязанностей? Или есть? Можно я буду считать что мои обязанности это кушать пончики и смотреть телек? "Если в ваши обязанности не входит..." - аж ругаться хочется от такого рудимента.

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

Баги вида "НИЧЕГО НЕ РАБОТАЕТ!" (общий случай бага "крутится круглый значок и ничего не появляется") это в худшем случае совершенно бесполезная паника (читать как "вредительство"), а в лучшем просто флажок вида "копать тут". ответ на вопрос кому копать во многом зависит от задач, которые ставятся. Если нужно посмотреть (поверхностно) как можно больше в сжатые сроки - тогда копать разработчику (тут, правда, предполагается что его время не казенное). Если нужно искать проблемы, причем проблемы серьезные - копать тестировщику.

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

Так вот и получается, что бага все-таки локализована была неправильно

Изучайте используемые технологии, изучайте внутреннее устройство продукта. Со временем придет понимание как оно работает, как оно устроено. Выгода, кстати, не только в том, что вам будет проще локализировать и описывать проблемы (а в ряде случаев и фиксить всякую мелочь), но и в том, что вы получите отличный дополнительный арсенал для моделирования отказов и сбоев.

Crawljax взять и не париться, если уж так хардкорно хочется. Все равно тот же WebDriver, а вся логика на обход урлов и прочего там уже вшита.

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

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

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

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


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

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

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

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