tестирование dot com

сливаются в одну стадию), что дает возможность выявить несты-

ковки между кодами разных авторов на раннем этапе.

3. РЕМОНТ БАГОВ...

происходит во время стадии "Тестирование и ремонт багов", по-

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

мисты работают над кодом для нового релиза.

Необходимость в замораживании кода вызвана тем, что продукт

(в данном случае код) должен быть в каком-то устойчивом виде,

чтобы его проверили.

Пример

Представьте следующую ситуацию:

1. Программист закончил работу над функциональностью А;

2. Тестировщик проверил, что функциональность А работает, и дал

добро на релиз;

3. За час до релиза программист вносит маленькое изменение в код,

которое в теории ничего не ломает...

а на практике приводит к тому, что функциональность В, связанная с А,

абсолютно перестает работать, т.е. получилось так, что тестировщик

попросту потерял время (а значит, и деньги компании), тестируя не

финальную версию продукта.

Из сказанного вытекают две принципиально важные для тести-

ровщика вещи. Перед началом тестирования нужно убедиться, что

• код заморожен (обычно релиз-инженеры посылают соот-

ветствующий е-мейл);

• версия продукта на внутреннем сайте, на котором вы будете

производить тестирование, является именно той версией,

которую вам нужно протестировать.

Пример

Допустим, что на интранете у нас есть два внутренних тестировочных

веб-сайта, недоступных для пользователей:

• www.everest.testshop.rs и

• www.elbrus.testshop.rs

Допустим также, что сайт

• www.everest.testshop.rs(по-простомуназываемый "Эверест") является

версией 1.0 и содержит функциональность А версии 1.0, а

• www.elbrus.testshop.rs(по-простомуназываемый "Эльбрус") является

версией 2.0 и содержит функциональность А версии 2.0.

100

Тестирование Дот Ком. Часть 1

Так вот в окне веб-браузера функциональность А может выглядеть аб-

солютно одинаково и на Эвересте, и на Эльбрусе, но ее бэк-энд будет

существенно различаться на этих двух сайтах.

Допустим, тестировщик собирается проверить функциональность А

версии 2.0, но ошибочно использует для тестирования Эверест (с вер-

сией 1.0), вследствие чего он не только впустую тратит время, но

и рискует дать добро на релиз непротестированного кода функцио-

нальности А версии 2.0.

Подобные ошибки возникают, как правило, по небрежности или

незнанию тестировщика и из-за "нелогичных" названий внутрен-

них веб-сайтов.

Пути предотвращения ситуации, когда тестировщик тестирует не

ту версию ПО:

1. Узнайте у релиз-инженера, как определить версию кода, и

используйте сие знание перед началом исполнения тести-

рования;

2. Посоветуйте, чтобы внутренние веб-сайты имели логич-

ные имена. Например, версия кода, переданного пользова-

телю, всегда должна быть на внутреннем сайте по адресу

www.old.testshop.rs, а версия для следующего релиза — на

www.main.testshop.rs;

3. Попросите релиз-инженеров, чтобы те создали на интра-

нете динамически обновляемую страничку с информацией

о

• версии и

• подверсии, т.е. билде (об этом позже),

каждого внутреннего тестировочного веб-сайта.

В завершение кодирования поговорим еще о паре вещей.

Хотя и спеки, а иногда даже и сами идеи для спеков — ребятки

не без греха, большинство багов зачинается именно при написа-

нии кода. При кодировании появляется присущий только этой

стадии и одновременно самый простой в нахождении вид бага —

синтаксический баг (syntax bug).

Прелесть синтаксических багов заключается в том, что они, явля-