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

вторник, октября 04, 2011

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

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

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


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

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


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

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


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



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

Из-под пера Maksim Grinevich

Тэги: , | 2 ответов, оставьте свой...

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

среда, сентября 21, 2011

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

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

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

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

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

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

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

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

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

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

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

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

Из-под пера Maksim Grinevich

Тэги: , , , , | 0 ответов, оставьте свой...

Боец тестирования банковского ПО в Минске, Гродно или Бресте будет успешно принят на работу

пятница, марта 25, 2011


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

Ко мне в команду нужны бойцы невидимого фронта тестирования.

Требования:
- быть готовым за очень короткие сроки овладеть большим объемом информации
- знать, что такое функциональное тестирование (и чем оно отличается, скажем, от нагрузочного)
- разговаривать с компьютером на «ты»

Плюсом будет:
- знание любого скриптового языка
- знание SQL
- опыт тестирования
- огромное желание стать тестировщиком
- знание правил бухгалтерского учета

Если ты студент(ка) или не имеешь опыта работы, но безумно трудолюбив(а) и талантлив(а) – пиши, возможно именно для тебя осталось место!

Писать на colvir[гав]yatester.ru или нашему HR - ohaetckaya[гав]colvir.ru

О компании.


Кстати, знание английского вовсе не требуется – совещаемся и пишем по-русски J

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

Из-под пера Maksim Grinevich

| 0 ответов, оставьте свой...

Никогда не говори никогда и другие 10 никогда...

пятница, февраля 25, 2011

Десять фраз, которые не должны звучать из уст тестировщика:

1. Здесь багов нет - я гарантирую.
2. Всё равно, никто не использует Firefox!
3. Cem Kaner и James Bach вообще не понимают, о чем говорят.
4. Это срочно? Я тут просто в Farmville играю.
5. У меня на компьютере все работает!
6. Я только что написал в твиттере о дыре в нашей системе безопасности...
7. Использовать инструменты для тестирования? Я справлюсь без них!
8. На самом деле я отличный тестировщик, пока не трезв..
9. Ты прав, мне тоже кажется что сообщение об ошибке - это новая фича.
10. Если здесь остались баги, их найдут beta-пользователи...

Источник

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

Из-под пера Maksim Grinevich

Тэги: , , , , | 4 ответов, оставьте свой...

Подписаться на: Сообщения (Atom)