Будущее тестирования
#1
Отправлено 21 декабря 2008 - 11:49
Читать дальше...
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#2
Отправлено 21 декабря 2008 - 18:41
Мы тут регулярно пытаемся доказывать (в таком виде, как сами это понимаем), что тестированию уже давно не является "деятельностью по контролю". Зачем ждать 20 лет, если меняться надо было позавчера?Согласно его предсказанию, роли дизайнера и тестировщика должны сблизиться настолько, что разделить их будет невозможно. Качество программ будет обеспечиваться дизайном, необходимость в отдельной деятельности по контролю отпадёт. Но при этом и роль дизайнера претерпит соответствующие изменения.
#4
Отправлено 22 декабря 2008 - 07:21
Они говорят, что не нужны тестировщики, которые умеют только тестировать.Некторые Agile-методологии уже давно об этом говорят. Ох уж эти сказочки, ох уж эти сказочники...представитель Visual Studio Team тест-менеджер Amit Chatterjee недвусмысленно заявил, что через 10-20 лет тестировщики будут не нужны
А Amit Chatterjee действительно сказочник.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#5
Отправлено 22 декабря 2008 - 08:47
Он даже не очень сильно мечтает, он просто смотрит по сторонам и описывает то, что видит:
- 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 адресуйте ему.
#6
Отправлено 22 декабря 2008 - 09:23
Хм. А просто тесты уже никто не разрабатывает? Зайди сюда, проверь вот это, потом вот это, потом на таких данных, потом под такой настройкой и т.д. Дизайнеры сразу автоматизируют? А для проектов (которых очень много) где автоматизация вообще убыточна - в таких проектах как?- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.
Редактор портала www.it4business.ru
#8
Отправлено 22 декабря 2008 - 11:42
Да нет, вроде еще кто-то остался, даже в MS -- http://members.micro...aretesting.mspx .Хм. А просто тесты уже никто не разрабатывает? Зайди сюда, проверь вот это, потом вот это, потом на таких данных, потом под такой настройкой и т.д. Дизайнеры сразу автоматизируют? А для проектов (которых очень много) где автоматизация вообще убыточна - в таких проектах как?- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.
Кстати гугл (http://www.google.ru/search?q=SDET ) термин SDET в значении software _design_ engineers in test знает только в отношении к MS.
Я по малограмотности раньше считал, что SDET -- это software _development_ engineers in test, но теперь исправлюсь, буду знать оба значения.
В значении development такая должность есть за пределами MS (данные гугла) и подразумевают под ней чаще всего чистого автоматизатора.
Короче мутный товарищ этот SDET -- тестировщик будущего.
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#9
Отправлено 22 декабря 2008 - 12:26
Посмотреть webinar можно тут: http://www.utest.com...s_whittaker.htm
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#10
Отправлено 22 декабря 2008 - 14:37
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#11
Отправлено 22 декабря 2008 - 16:46
- SDET (software design engineers in test, пришедшие на смену STE) автоматизируют тестирование, делают ревью кода перед каждым check-in, обеспечивают определенный уровень покрытия кода (в дополнение к тому, что покрыто юнит тестами SDE) и тестовое покрытие, пишут необходимые тулы для тестирования и/или для разработки, помогают с data mining и прочая; вовлечены в дизайн продукта и его разработку. Это все может выглядеть загадочно, с точки зрения 'инженера в оффшоре', где основная задача - сплавить проект и быстро перейти к совершенно другому. Это выглядит намного более естественно если очевидно, что продукт нужно будет поддерживать и развивать лет 10 минимум.
Хм. А просто тесты уже никто не разрабатывает? Зайди сюда, проверь вот это, потом вот это, потом на таких данных, потом под такой настройкой и т.д. Дизайнеры сразу автоматизируют? А для проектов (которых очень много) где автоматизация вообще убыточна - в таких проектах как?
SDET и разрабатывает. иначе - какой смысл автоматизировать, если непонятно на что должны пойти основные усилия.
а про 100% автоматизацию никто и не говорит [пока]. Говорят про значительное уменьшение доли и роли ручного тестирования.
#12
Отправлено 22 декабря 2008 - 16:57
Да нет, вроде еще кто-то остался, даже в MS -- http://members.micro...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 :)
#13
Отправлено 22 декабря 2008 - 17:07
Кстати гугл (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, продажу и легкую смерть после этого.
#14
Отправлено 22 декабря 2008 - 17:56
--
Сергей Мартыненко
Блог 255 ступеней (байки для оруженосца)
facebook (Дети диаграммы Ганта)
ВебПосиделки клуба имени Френсиса Бэкона
#15
Отправлено 22 декабря 2008 - 18:14
Я вообщем без претензии на исследование рынка. Так у гугла спросил.Да нет, вроде еще кто-то остался, даже в MS -- http://members.micro...aretesting.mspx .
вы реальные позиции пытались искать? на данный момент их две.
Вашу мысль понял, спасибо что поделились информацией, у нас это все не так хорошо видно (или не туда смотрел).
Чубака — это вуки с планеты Киши, но живет Чубака на планете Эндо, а теперь вдумайтесь:
в этом же нет смысла. С какой стати Чубаке, вуки высотой два с половиной метра,
жить среди эвоков, которые чуть выше полуметра. В этом нет абсолютно никакого смысла.
#17
Отправлено 23 декабря 2008 - 06:21
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#18
Отправлено 23 декабря 2008 - 06:43
Коллеги, вы всё-таки не очень вникли в мысль Джеймса Виттейкера. 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.
что, собственно, только подтверждает все ранее сказанное.
где я ошибаюсь/не дочитал/..?
#19
Отправлено 23 декабря 2008 - 06:58
Да, Андрей, конечно ты прав -- SDET это уже шаг в том самом направлении. Но это ещё далеко не финал путешествия!
Тренинги для тестировщиков (тестирование производительности, защищенности, тест-дизайн, автоматизация):
Линейка тренингов по Selenium
#20
Отправлено 23 декабря 2008 - 07:25
Ошибка состоит в попытках "натянуть" существующие описанные "служебные обязанности" SDET на "тестировщика будущего".
не путайте, пожалуйста, описание настоящего с прогнозами.
я просто описываю ту версию настоящего, которая дает контекст для понимания, того откуда эти прогнозы берутся.
т.е. есть люди, которые наблюдали/практиковали тестирование N (10, 15, 20) лет назад и наблюдают/практикуют его сейчас в сильно изменившемся виде.
по результатам наблюдений, известных тенденций и прочая они экстраполируют это на M лет вперед.
читателям, которые смотрят по сторонам и не видят отличий от того, что было написано в книгах лет 20 назад (тем же Канером) все эти прогнозы кажутся сказками. потому я тут перевожу байты на объяснение этого контекста.
предсказать пути эволюции автопрома исходя только из прогресса ВАЗа можно, но выйдет плохо.
т.е. неплохо бы изучить что там Хонда с Тойотой делали, хотя бы.
Количество пользователей, читающих эту тему: 0
0 пользователей, 0 гостей, 0 анонимных