Видео моего доклада на SQA Days 2012 (+HD)


Промышленный подход к автоматизации тестирования

Буду рад прочитать отзывы и комментарии к выступлению.

Текст сообщения и комментарии...


Mindmaps о тестировании

Ух и хорошая же ссылка попалась мне на просторах сети.

Здесь куча очень толковых интеллект карт о тестировании.

Вот только малая часть того, что есть по ссылке:

Текст сообщения и комментарии...


Промышленный подход к автоматизации тестирования или Keyword-driven testing в жизни. SQA Days 2012


Оценка работы тестировщиков


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

Четкая и прозрачная фиксация ожиданий от группы тестирования.

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

Чтобы вы не сделали, умелые тестировщики, это все равно не будет иметь должного эффекта. ;) 
Сколько раз в умных книгах писали - главное договориться на берегу. Но, как ни крути, учиться на своих ошибках как-то ближе к телу.

А что до названия поста, то оценка работы тестировщиков в итоге сводится к одному - сделано ли то, что ожидалось :) В этом выражении можно слово "тестировщиков" заменить на программистов, аналитиков... Но есть одно НО: программисты производят в конечном итоге "код", аналитики - постановки, а вот результат работы тестировщиков - "нематериален".

Текст сообщения и комментарии...


Видео выступления на SQA Days 10 - Эффект Горизонта

Ну вот и дошло до меня видео моего выступления на SQA Days 10.
Качество звука не очень, а за кадром ещё и смех посторонний - но лучше это, чем вообще ничего :).

Отдельное спасибо Стасу Фомину за запись и оцифровку.

Смотрите, и, чур, помидорами не бросаться ;)


Текст сообщения и комментарии...


Эффект горизонта

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

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

Как же этот эффект проявляется в тестировании:
  • Неправильно выбираются тесты для автоматизации
  • Ошибки в выборе тестов для прогона при ограниченном времени
  • Ошибки при планировании тестирования
  • Ошибки в выборе средств тестирования(от багтреккера до документов) и автоматизации


Методы сглаживания эффекта или как с этим бороться?

Для сглаживания последствий придумано несколько алгоритмических решений, суть которых:
  1. Расширить уровень горизонта за счет поиска «интересных» мест и продвижения «тихих» или «громких» ходов (Quiescence search)
  2. Минимизировать потери при максимизации прибыли (Minimax| Maximin) и его уточнение с помощью отбрасывания более «слабых» уже найденных ходов (Alpha-beta pruning)


Теперь же о главном…

Как можно применить указанное выше:
  1. Расширяем просмотр «Шахов»: «Шахи» - ключевые моменты бизнес процессов, ситуации, в которых от приложения требуется особая «багоустойчивость»; рассмотрение возможных последствий в узлах процесса тестирования
  2. Расширяем просмотр «Атак»: рассматриваем варианты поведения системы в особенно «популярных» для пользователя местах; варианты развития событий после внесения изменений в процесс тестирования
  3. Расширяем просмотр «Потенциальных угроз»: где произошли изменения; где будут происходить изменения в будущем (активная разработка модуля)
  4. Определяем уровень доступного горизонта - определяем области, необходимого расширения горизонта  - строим свое дерево познания предметной области и процессов.


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



Текст сообщения и комментарии...


Тестирование оптимизации...

В процессе тестирования поставок клиентам часть задач (около 10%) связана с оптимизацией кода на SQL.
Понятно, что проверить во первых стоит проверить, не поломалась ли функциональность приложения и только затем перейти ко второй фазе - непосредственная проверка оптимизации.

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

Куча первая - проблемы БД:

  • фоновые процедуры (служебные job'ы и процедуры приложения, выполняемые в фоновом режиме)
  • "служебные" активности БД: пересчет индексов, высвобождение temp'овых таблиц, оптимизация хранения данных на жестком диске
Куча вторая - проблемы данных и процессов приложения:

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

Часть проблем, безусловно решается разными дополняющими и исключающими друг друга методами.. но возникает резонный вопрос:
Зачем все танцы с бубном, которые займут ещё и кучу времени, если мы изобретаем велосипед для нагрузочного тестирования?

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

Но тогда возникает резонный вопрос у заказчика - а был ли мальчик?  А исправили ли медленную работу ПО?

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

----------------
*Рассматриваем ситуации оптимизации процедур и функций в рамках произведения комплексных процессов: закрытия операционного дня банка; пересчет PnL и PV позиций; обработки 1000К сообщений для отправки и т.д. (код, а не бизнес-логика этапов процесса)

P.S.:  все хотел куда-нибудь серых человечков добавить :)

Текст сообщения и комментарии...