« Я тестер ! »

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

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

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

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

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

Для сглаживания последствий придумано несколько алгоритмических решений, суть которых:

Как можно применить указанное выше:

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

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

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

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

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

----------------