« Я тестер ! »

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

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

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

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

Ночная работа... Думаю, что нет никого из опытных ITишников, кто не работал бы ночью. Как переработка (или длительное пребывание на рабочем месте в течении 12-18 часов) отражается на вашей продуктивности?

Всем известны недостатки такой работы:

— усталость: закрываются глаза, голова не хочет думать, компьютеры тормозят сильнее, всю еду уже съели;

— давление начальства (ведь задерживаемся, чтобы сделать что-то быстрее, чем обычно);

— давление домашних (они хотят видеть нас дома «как обычно», а не позже на 3-4..10 часов)

— с каждым часом растущее желание — а не пошло оно всё лесом, я хочу домой/спать/есть/и т.д., подчеркнуть необходимое

— пропущенные дефекты в виду всего выше перечисленного...

Но ведь и плюсы у такой работы тоже есть:

Поэтому теперь у себя в коде стараюсь как можно больше всего выносить в Associated Function Libraries.

А так ли нужны test cases, когда нет времени на регрессионное тестирование вообще?

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

Я привык относится к тестированию более систематически — прочитал книги Канера и иже с ним, в подборке куча регулярно читаемых «светил» отрасли и т.д. (здесь умышленно не касаюсь практического опыта) — и считаю, что хорошо построенный процесс тестирования (читай всей разработки) приводит к хорошему результату.