Первые 15 минут у нового провайдера )

Сегодня от "провайдера N" приходил ко мне мастер подключать интернет+ТВ.
У меня уже есть качественный доступ в интернет-услугам, но вот захотелось посмотреть , что у других - тем более предоставляется тестовый доступ на 1й месяц.
Схема подключения - через коаксиальный кабель, модем и ТВ-тюнер (для телека). Подключение заняло минут 15 , не больше. Мастер ушел. Начался тестовый период в прямом смысле слова =)

Интернет

Единственное, что можно сразу проверить  - это соответствует ли реальная скорость обмена данными.

В тарифном плане (ТП) заявленная скорость подключения - 15 мегабит . Ну хорошо, пусть "до 15 мегабит"... Несколько повторных тестов на разных онлайн-тестерах ни разу  не показали больше 7.5 Mbit/s

http://www.speedtest.net/my-result/2952653119

В сравнении с имеющимся текущим провайдером , с его "практически честными" 20 мегабитами , новый провайдер явно не впереди.

Телевидение

Пока это обычное IP-телевидение , никакое не HDTV. Три пакета каналов в том числе и все федеральные.

Качество показа в плане "мурашек" :) хорошее, цифра все-таки ) Но один неприятный момент сразу бросился в глаза - картинка не умещается на экране. Например, логотипы каналов полностью не влезают. Игры с настройками самого ТВ (неплохой телек LG линейки 2012 года) не помогли. 

В аналоговом варианте - те же каналы смотрятся гораздо приятнее.

То есть, получается, вопросы к качеству цифрового контента. Буду еще разбираться с этим , может, как-то решается все-таки.

Личный кабинет

Личный кабинет (ЛК) - это самое приятное для тестирование. Это , как обычно, веб-портальчик для управления своим сотрудничеством с провайдером.

Управление услугами

Баг вылез еще до того , как успел  толком оценить функциональность и удобство .

На скрине видим, что получается, если несколько раз кликнуть на развернутом пункте в списке меню:

Хорошо, что такие клики не приводят к реальному изменению списка услуг :) и обновление страницы восстанавливает dom.

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

Обратная связь

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

Создал сообщение, попытался приаттачить скриншот - "файл не выбран".. попытался еще раз - опять "файл не выбран".

Ну хорошо - отправил без скриншота. В итоге файлы все-таки ушли - два одинаковых )

Тут же решил проверить форму "дополнить сообщение" - и там ошибки. Сабмит формы завершается следующим:

...хотя дополнительные сообщения при этом добавляются ...

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

то видно , что попасть отсюда можно только на главный сайт провайдера или явно выйти из ЛК. Как попасть на главную страницу ЛК - непонятно.

Пробую урезать url до корневого: https://office.operanorN.ru/ - и вижу форму с логином - то есть надо опять логиниться, хотя сессия от старого жива и продолжает жрать ресурсы сервера (бд, очистка старых сессий и так далее)... "Удобно" , ничего не скажешь.

Справедливости ради скажу, что саппорт отвечает очень шустро )

Дальше ковырять пока не стал. Но чувствую, что впереди еще будет много "интересного".

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

масдай

Вчера утром windows-7 на домашнем компьютере в очередной самообновилась, после чего запуск любого невиндового приложения приводил к ошибке 0x000005 Так как сразу было ясно , что виной всему очередной непротестированный ms-патч, то удаление всех обновлений этого утра и последующая перезагрузка с запретом дальнейших апдетов решили проблему. Не первый раз уже подобные казусы случаются а масдаевскими патчами. Поэтому становится очень интересно, в чем именно состоит технология тестирования обновлений в Microsoft ? Тестируются ли они ? Ведь бывало даже так, что ось даже не загружалась после очередного обновления. Такое сложно им отловить ? Или быть может эдакое неявное краудсорсерское тестирование и есть технология тестирования апдейтов в MS? Эта организация славится своими спецами в области qa, красивыми и живыми докладами на эту тему, различными best practice по организации процесса контроля качества ПО, но ежедневные наблюдения почему-то подсказывают, что "не все в порядке в датском королевстве"... Ведь неслучайно хакеры/исследователи радостно потирают ручки , если вдруг им удается выяснить , что на исследуемом хосте крутится именно MS windows ?

Хабр не выдержал хабраэффекта )

Универсальное резюме :)

Автотесты на автотесты ?

Зачастую процесс автоматизации тестирования со временем обрастает набором своих собственных вспомогательных библиотек, надстроек, эмуляторов, заглушек и т.д., которые используются в конечных автотестах. Эти "библиотеки" могут решать совершенно разные задачи , но все их объединяет одна банальная вещь - это код, а код очень часто содержит баги.

Наверное, почти любой тестер скажет - "Хорошо, когда разработчики пишут unit-тесты на свои библиотеки".. Кто-то при этом дополнит " а если не пишут, то давайте напишем мы..." Для чего? Конечно же для того, чтобы итоговый продукт был более качественным. Это все банально и понятно.  Но когда дело касается кода тестерских либ, то тут повсеместно наблюдается весьма странная вещь  - код этих библиотек довольно редко обкладывается тестами.

Попробуем разобраться, почему так происходит...

1. многим тестировщикам просто в голову не приходит , что их код это тоже код и он тоже может содержать ошибки
2. кто по вдумчивее скажет: тестерский код часто меняется, не решает бизнес-задач пользователя, денег не несет и потому риски багов  в нем ничтожны - да, это аргумент
3. кто-то понимает , что "по-хорошему надо бы обложить тестами", но не делает этого ввиду нехватки времени, желания , а порой отсутствия такой активности как таковой в группе тестирования, отсуствия такого прецедента....

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

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

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

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

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

uml для описания тест-кейсов

Уже довольно продолжительное время приходится заниматься дизайном тестов для ПО из сферы телекомуникаций.
Как правило тест-кейсы направлены на проверку взаимодействия абонента, сетевого оборудования , ААА-серверов и т.д.
Для описания тестовых случаев мною обычно применялся классический способ - текстовое описание предусловий, последовательности действий, результата.
С некоторых пор стал замечать, что описанным классическим способом тестовым случаям не хватает наглядности, а само описание текстом последовательности пакетов, действий с БД и так далее - довольно утомительное занятие, при котором сам дизайнер нет-нет да оставит что-то между строк как само собой разумеещееся.
Все это приводит к появлению риска неполного или неправильного понимания описания тестировщиком, увеличивает число уточняющих вопросов к дизайнеру при выполении теста. Для решения этой "проблемы" решил попробовать uml-диаграммы. А точнее activity-диаграммы.
Например:
 
На мой взгляд, гораздо нагляднее и лаконичнее, чем расписанная по пунктам последовательность действий, пакетов , ответов...
И чем сложнее тестовый-случай (взять хотя бы сценарий использования Cisco SSG , личного кабинета с какой-нибудь турбокнопкой ) , тем оправданнее становится применение подобных схем. Текстовое описание входных данных , к которым прикрепляется подобная activity-диаграмма делают тест-кейсы подобного рода более наглядными и понятными конечному тестировщику.
Конечно же возникает вопрос способа рисования такой диаграммы.
Лично я не использую никаких десктопных приложений в стиле "перенеси и брось", а просто компиллирую uml-код в изображение.

Вот код для картинки, которая помещена выше:

@startuml
title 
Тест-кейс "Неверный пароль"
end title

participant User
participant NAS
participant Radiusd
participant DB

User    -> NAS: Start internet session with username = 'ivan' and password='007'
NAS     -> Radiusd: Access Request 
Radiusd -> DB: User authentication (check username and password)
DB      -> Radiusd: Incorrect password
Radiusd -> NAS: Access Reject
NAS     -> User: failed to establish internet connection

@enduml

Код успешно компиллируется plantuml-ем, о возможностях и особенностях которого расскажу в отдельной статье...

Неплохой фаззер

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

Фаззер: uniofuzz



Написан на python. Довольно прост и в то же время универсален -  умеет генерировать рандомные файлы, фаззить tcp-соединения, пайпы и т.д.(см -help)

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

"Почти" - потому что пришлось научить ее фаззить udp вместо tcp и немного "поиграться" с длиной содержимого пакета.

Патч прост:
 
235c235
<               sock=socket.socket(socket.AF_INET, socket.SOCK_STREAM)
---
>               sock=socket.socket(socket.AF_INET, socket.SOCK_DGRAM)

Пример фаззинга (2 пакета в секунду) в сетевом соединении:

./uniofuzz.py -n -i 0.5 -ip 127.0.0.1 -port 12345 -s 9999

Утилита проста и эффективна, код открыт и прямолинеен - допилить под свои нужды - не проблема.

Кому нужен ISO или история обесценивания

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

Водительские права? Пожалуйста - полиционер сам за тебя все кнопки нажмет при сдаче теории, разыграв спектакль "самостоятельная сдача экзамена в гибдд".
Талон техосмотра - пожалуйста! Гарантирует ли эта бумаженция то, то твое корыто не развалится по среди мкад и не пришибет кого-нибудь отвалившимся на ходу колесом? Нет. Это лишь повод заработать.

И так везде. В том числе и в сфере сертификации систем качества производства ПО.
Есть такие замечательные международный стандарты ISO 900x , в которых даны исчерпывающие рецепты того, какой должна быть идеальная СМК - расписаны ее компоненты, документы, процессы, роли. Есть и родной наш ГОСТ, в котором не меньше полезной информации для тех, кто действительно хочет вывести качество своего продукта на высокий и даже международный уровень. В общем, все есть - изучай, инвестируй, внедряй и получай результат. Но что получается на практике? Как грибы после дождя расплодились сертифицирующие органы, направо и налево раздающие красивые "сертификаты соответствия", за круглые суммы и в сжатые сроки, даже не ступая ногой на территорию предприятия. Эти разноцветные бумажки попадают в стеклянные рамочки топ-манагеров, на главные страницы сайтов софтверных фирм - вот , дескать, смотрите все ! Вот почему наш софт на 200% дроже остальных! А на деле -  в лучшем случае вся СМК состоит из одного лишь выходного контроля  в виде отдельчика или группки тестирования, которые с переменным успехом сдерживают лавину проблем, которые уходят корнями во все отделы и даже в кабинет  в топ-манеджеру , у которого на стене красивая рамочка.

Обесценивание повсюду -  во всех , за микроскопическми исключениями сферах.

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

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

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

Верю , однако, что здоровый прагматизм победит нездоровый. И это уже местами начинает прорастать и побеждать...

Показательный пример -  на собеседованиях (по крайней мере ИТ-специалистов ) все реже смотрят на диплом (если , конечно, это не диплом физтеха или мехмата МГУ :),  а все больше на опыт, на способность мыслить...  Заказчиков все сложнее заманить "бумажкой в рамке" им нужно реальное качество... Мы обесценили все эти лейблы, мы перестаем их замечать.. Проблема лишь в том, что весь остальной мир на полном серьезе учится, получает честные дипломы и сертифицируется не понарошку ...

Грабли от HTML5

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

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

Баг такой:

1. клиент положил  в корзину товар
2. перешел в корзину
3. и решил накрутить количество, зажав кнопку увеличения 
4. накручивал-накручивал так несколько секунд, пока не надоело, и отпустил...

После этого значение в поле "само"  некоторое время начало прыгать, и  содержимое страницы тоже постоянно перерисовываться. Попросили разобраться с этой "мистикой".

Разбор был недолог: при каждом обновлении значения в поле "количество" на сервер слался асинхронный запрос (ajax) на получение пересчитанной корзины... сервер просто начинал давиться :) и ответы на запросы невпопад продолжали приходить в броузер еще некоторое время после того, как юзер устал накручивать ...

К чему это все я?

1. разработчикам - всяческие новые "плюшки" в стандартах не отменяют обдуманного их применения
2. тестировщикам - применяя и осваивая навороченные техники тестирования иногда можно просто "взять и сломать" по-старинке :)

Учим Test::Class контролировать зависшие тесты

Есть такой популярный модуль Test::Class -  реализация xUnit для Perl.

Довольно удачная реализация - есть все или почти все, что требуется для xUnit-фреймворка.

TestSuite можно описать с помощью класса (пакета) например так (код не постеснялся скопипастить прямо с cpan):

  package Example::Test;
  use base qw(Test::Class);
  use Test::More;

  # setup methods are run before every test method. 
  sub make_fixture : Test(setup) {
      my $array = [1, 2];
      shift->{test_array} = $array;
  };

  # a test method that runs 1 test
  sub test_push : Test {
      my $array = shift->{test_array};
      push @$array, 3;
      is_deeply($array, [1, 2, 3], 'push worked');
  };

  # a test method that runs 4 tests
  sub test_pop : Test(4) {
      my $array = shift->{test_array};
      is(pop @$array, 2, 'pop = 2');
      is(pop @$array, 1, 'pop = 1');
      is_deeply($array, [], 'array empty');
      is(pop @$array, undef, 'pop = undef');
  };

  # teardown methods are run after every test method.
  sub teardown : Test(teardown) {
      my $array = shift->{test_array};
      diag("array = (@$array) after test(s)");
  };

Вот только контролировать продолжительность тестов по таймауту этот фреймворк не умеет.

Чтобы решить эту проблему, не поручая такой контроль каким бы то ни было внешним утилитам, можно воспользоваться возможностями ООП и fork примерно так:

package TTL::Test::Class; use base qw(Test::Class); use Test::More; use POSIX ":sys_wait_h"; use constant DEFAULT_TIMEOUT => 60; # переопределяем метод запуска тестов sub runtests{ my $t = DEFAULT_TIMEOUT; my $pid = fork; my $child_ret_code; if( $pid > 0 ){ # parent process #child waiting loop my $ok_flag = 0; for(my $i=0; $i < $t; $i++){ if(waitpid($pid, WNOHANG)){ $child_ret_code = $?/256; ok($child_ret_code); $ok_flag = 1; last; }; sleep(1); }; if( not $ok_flag ){ diag "Killing test by its timetolive..."; kill TERM => $pid; return $ok_flag; }; return $child_ret_code; } elsif( $pid == 0 ) { #child exit $self->SUPER::runtests; } elsif ( not defined($pid) ) { #unsuccessfull fork die "Cannot fork child process: $!"; } } 1;

далее в сьюте меняем базовый класс на наш:

#use base qw(Test::Class);
use base qw(TTL::Test::Class);

Теперь каждый сьют будет принудительно завершен через нужный нам таймаут.
Мораль сей басни такова (с),  никакой готовый фреймфорк полностью не удовлетворит всем возможным нуждам при конкретном его применении.
Поэтому можно и нужно допиливать и улучшать.

О верификации и валидации

«Ты суслика видишь?
— Нет.
— И я нет. А он есть!»
("ДМБ")

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

Не всякий сходу сможет объяснить , в чем различие. Но оно есть и оно довольно существенно.

Неофициально эти термины можно расшифровать так:

Верификация - это проверка того, соответствует ли продукт (ПО, например) неким требованиям , которые считаются эталоном.

Валидация - это проверка применимости продукта в конкретных условиях, соответствует ли он им, может ли использоваться в этих условиях.

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

Анализ причины пропуска , как правило, не занимает много времени:

• недорабатывают  с заказчиком менеджеры , не вытягивая из него максимум информации о будущих условиях и бизнес-процессах
• не до конца вникают аналитики (если они вообще есть)
• разработчикам не досуг - скомпилилось бы и прошли бы юнит-тесты (если он вообще есть)
• тестировщики с замыленными глазами тестовыми данными
• приемочные тесты поверхностны (заказчики часто довольно безответственно подходят к составлению таких тестов и их согласованию)

- все это может привести к неожиданностям при реальном использовании.

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

Проверяем локальный web на соответствие стандартам разметки

Всем , наверняка знакомы полезные валидирующие сервисы от w3c.org, с помощью которых можно быстро проверить url на соответствия, например, разметки (markup) стандартам.

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

Вот незамысловатая инструкция для linux debian (все то же самое можно проделать практически на любой другой десктопной или серверной ос):

#ставим пакет из репозитория
apt-get install w3c-markup-validator

#ставим нужные perl-библиотеки
cpan Bundle::W3C::Validator

#запускаем инсталлятор сервера
w3c-validator-install.sh  all

#пробуем запустить с дефолтными настройками (запущенный сервер будет "ждать" http на 5000-м порту)
w3c-validator-server.psgi

#дальше пробуем проверить локальный url и видим сообщение об ошибке:

#разрешаем в конфиге private-адреса: vim /home/someuser/.w3c-validator-server/config/validator.conf



Allow Private IPs = yes

далее перезапускаем сервер и натравливаем валидатор на локальный ресурс после этого правим разметку :)

To resolve this problem, it is best to upgrade to newer version of Internet Explorer

Уже довольно продолжительное время говорится об ущербности IE 6.0 и о том, что учитывать его "особенности" при web-разработке не стОит.

Наверное , это правильно.

Пару дней назад мне в тестирование попала новая функциональность , заодно с которой была переделана верстка.

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

Проблема зафиксирована, разработчики думают, что дальше делать...

Не знаю кто меня дернул за руку, что я полез из этого тестового IE 6 на поисковую страницу google и даже попробовать что-то там найти.. Начинаю, значит, вводить критерий поиска и получаю Access Violation по нулевому адресу.

IE приучил не обращать внимания на такие вещи , если они не повторяются... А когда повторяются, то становится уже интересно.  Этот баг повторился. OllyDbg показал на mshtml.dll - либа, отвечающая за рендеринг страниц.

Покопался  в том, что же такого криминального  в простенькой на вид страничке google.com...

Выяснилось, что причиной падения является хитрый cookie вида "search?client=heirloom-hp&hl=ru&gs_rn....&q=t" , который поисковик создает при каждой попытке поиска. Прежде , чем копать дальше и думать, чем такой баг может реально грозить, решил поискать , не сталкивался ли кто с такой проблемой до меня ... и точно, нашел... Ответ google-a убил желание копать дальше... "Обновите броузер".

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

..но почему-то не написал :)

Ретроспективка

А все-таки чертовски большой скачок совершило "тестирование" за последние лет 5-10.

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

Да и не было по большому счету такой ПРОФЕССИИ - "тестировщик". Этому не учили толком в наших ВУЗах, за это не давали сертификатов, и в конечном итоге за это платили смешные деньги. Такое положение дел было естественным для нашей страны, на годы отстающей от информационно-технологичного запада, сего Канером. Редко кто из кампаний-разработчиков софта выдвигал повышенные требования к качествую своих продуктов... хотя бы потому что не было таких требований со стороны рынка... Да, были такие "гиганты" типа CBOSS ( это не реклама :), которые с самого начала возвели качество во главу угла и где тестирование было организовано на отличном уровне даже много лет назад.. но это были исключения.

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

Кто остался?

Кто-то остался в профессии из-за малодушия, кто-то из-за понимания перспектив и настоящего призвания к этому делу, кто-то остался , найдя для себя приемлемые компромиссы и горизонты развития в тестировании...

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

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