Будущее тестирования Опции

[barancev]

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

Читать дальше...

[rlabs]

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

Мы тут регулярно пытаемся доказывать (в таком виде, как сами это понимаем), что тестированию уже давно не является "деятельностью по контролю". Зачем ждать 20 лет, если меняться надо было позавчера?

[Clauster]

представитель Visual Studio Team тест-менеджер Amit Chatterjee недвусмысленно заявил, что через 10-20 лет тестировщики будут не нужны

Некторые Agile-методологии уже давно об этом говорят. Ох уж эти сказочки, ох уж эти сказочники...

[Alfa]

представитель Visual Studio Team тест-менеджер Amit Chatterjee недвусмысленно заявил, что через 10-20 лет тестировщики будут не нужны

Некторые Agile-методологии уже давно об этом говорят. Ох уж эти сказочки, ох уж эти сказочники...

Они говорят, что не нужны тестировщики, которые умеют только тестировать.
А Amit Chatterjee действительно сказочник.

[dlg99]

Дык, IMO он говорит о простых вещах - о размытии границы между (старательно вычеркнуто: "городом и деревней") разработчиками и тестировщиками.
Он даже не очень сильно мечтает, он просто смотрит по сторонам и описывает то, что видит:

- STE (software test engineers) вымерли, их просто не нанимают. Монотонная ручная работа на несколько итераций отдается контракторам-оффшорникам (обычно UI, cross-browser/cross platform testing etc.), но старательно автоматизируется, причем все быстрее. Некоторую работу им все равно нельзя отдать (бекенд, оценка юзабилити и пр.), для этого есть выделенные специалисты.

- 'дизайнеры' (SDE, software design engineers aka developers) обязаны писать юнит тесты к своему коду и обеспечивать определенный минимальный уровень покрытия кода, а также делают reviews тестам и тест планам, т.е. вовлечены в тестирование.

- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.

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

учтите еще, что он сейчас "General Manager" - т.е. управленец и часть контекста воспринимает "со своей колокольни" (какого черта его назвали 'тест-менеджер'? в оригинале 'Amit Chatterjee, General Manager, Visual Studio Team Test'). Впрочем, он проработал в компании 20 лет, начав с разработки (просто найдите его профайл в линкедин) и наблюдал эти изменения изнутри. К тому же он непосредственно занят разработкой тех средств (Visual Studio Team Test), которые должны помочь эту границу стереть и дальше, и частично он 'рекламирует' свою команду (опять таки, по-моему)

я не согласен с утверждениями про 10 или 20 лет в глобальном контексте - просто инерция в индустрии в целом не позволит совершить такой переход глобально в такие сроки (IMO), но многие (Microsoft, Google, Facebook, ...) уже на этом пути и далеко не в начале. "сказочником" я бы его называть не стал.

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

P.S. мнение исключительно мое и т.д. и т.п.; все уточняющие вопросы к Amit Chatterjee адресуйте ему.

[Case]

- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.

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

[Clauster]

Они говорят, что не нужны тестировщики, которые умеют только тестировать.
А Amit Chatterjee действительно сказочник.

Дык, такие, по-моему, никому не нужны.
А, чуть не забыл, в Ереване вроде нужны. :)

[Alfa]

- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.

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

Да нет, вроде еще кто-то остался, даже в MS -- http://members.microsoft.com/careers/caree...aretesting.mspx .

Кстати гугл (http://www.google.ru/search?q=SDET ) термин SDET в значении software _design_ engineers in test знает только в отношении к MS.
Я по малограмотности раньше считал, что SDET -- это software _development_ engineers in test, но теперь исправлюсь, буду знать оба значения.
В значении development такая должность есть за пределами MS (данные гугла) и подразумевают под ней чаще всего чистого автоматизатора.

Короче мутный товарищ этот SDET -- тестировщик будущего.

[Alfa]

Кроме серии постов на тему будущего тестирования, Джеймс Виттакер так же сделал webinar на эту тему.
Посмотреть webinar можно тут: http://www.utest.com/webinar_james_whittaker.htm

[barancev]

Он ещё и на GTAC 2008 выступил с ключевым докладом. С нетерпением жду, когда появится видео...

[dlg99]

- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.

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

SDET и разрабатывает. иначе - какой смысл автоматизировать, если непонятно на что должны пойти основные усилия.
а про 100% автоматизацию никто и не говорит [пока]. Говорят про значительное уменьшение доли и роли ручного тестирования.

[dlg99]

Да нет, вроде еще кто-то остался, даже в MS -- http://members.microsoft.com/careers/caree...aretesting.mspx .

вы реальные позиции пытались искать? на данный момент их две.
В одной сходу написано "As a SDE/T Engineer," + требования к знанию C#/.Net, вторая - тестирование игр на XBox ("2 year college degree", "2 years of game or software test engineering experience"). Еще на такие позиции иногда школьников приглашают, типа от 16 лет и от 5 лет опыта игр в Halo or similar :)

[dlg99]

Кстати гугл (http://www.google.ru/search?q=SDET ) термин SDET в значении software _design_ engineers in test знает только в отношении к MS.
Я по малограмотности раньше считал, что SDET -- это software _development_ engineers in test, но теперь исправлюсь, буду знать оба значения.
В значении development такая должность есть за пределами MS (данные гугла) и подразумевают под ней чаще всего чистого автоматизатора.

мелкие отличия в названиях мы отметем с негодованием, как несущественные ;)
В MS и 'develeopment engineers' нет.

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

[SALar]

А подолью ка я керосинчику в обсуждение.

http://blog.shumoos.com/archives/168

[Alfa]

Да нет, вроде еще кто-то остался, даже в MS -- http://members.microsoft.com/careers/caree...aretesting.mspx .

вы реальные позиции пытались искать? на данный момент их две.

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

[dlg99]

jfyi:

вот тут и вот тут про того самого мутного SDET-а пишут всякое интересное.

[barancev]

Коллеги, вы всё-таки не очень вникли в мысль Джеймса Виттейкера. SDET в светлом будущем не нужен :)

[dlg99]

Коллеги, вы всё-таки не очень вникли в мысль Джеймса Виттейкера. SDET в светлом будущем не нужен :)

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

Я увидел, например здесь:

Imagine a world where testing knowledge is contained in each and every contributor’s head. The architects know testing, the designers know testing, the developers know testing and they apply that knowledge constantly and consistently in everything they do. This doesn’t wipe out the separate testing role, there is something to be said for some amount of test independence, it enables better testing. If each decision made throughout product development asks the right testing questions, then the final system test can reach a level of thoroughness we can only dream about now. If everyone on the project understood testing, imagine what a few dedicated testers could accomplish!

....

Testing is too important to be the ‘bit at the end’ of the process. It is early in the process where design decisions impact testing and it is there that the solutions lay. It's also too important to leave it in the hands of a single role dedicated to quality assurance. Instead we need a fundamental cultural shift that makes quality everyone’s job and embeds its principles in everything we do.

что, собственно, только подтверждает все ранее сказанное.

где я ошибаюсь/не дочитал/..?

[barancev]

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

Да, Андрей, конечно ты прав -- SDET это уже шаг в том самом направлении. Но это ещё далеко не финал путешествия!

[dlg99]

Ошибка состоит в попытках "натянуть" существующие описанные "служебные обязанности" SDET на "тестировщика будущего".

не путайте, пожалуйста, описание настоящего с прогнозами.
я просто описываю ту версию настоящего, которая дает контекст для понимания, того откуда эти прогнозы берутся.
т.е. есть люди, которые наблюдали/практиковали тестирование N (10, 15, 20) лет назад и наблюдают/практикуют его сейчас в сильно изменившемся виде.
по результатам наблюдений, известных тенденций и прочая они экстраполируют это на M лет вперед.

читателям, которые смотрят по сторонам и не видят отличий от того, что было написано в книгах лет 20 назад (тем же Канером) все эти прогнозы кажутся сказками. потому я тут перевожу байты на объяснение этого контекста.

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