tестирование dot com
Шрифт:
браНа: возвращение загулявшего сына".
Неудивительно, что мы прочувствуем всю боль релиз-инженеров, ко-
гда соединим четыре рисунка вместе и увидим
• удрученного великана, стоящего на коленях над
• стариком,
• гладящим промокшую болонку
• в окружении заспанных курсантов-суворовцев.
Остается
стить, что их не совмещали по мере написания, используя...
Вариант 2. Благодарный
Чтобы избежать проблем, когда в один момент происходит мас-
сированная интеграция кодов разных авторов, как в Варианте 1,
программисты производят интеграцию постоянно по мере напи-
Цикл разработки ПО
99
сания нового кода (т.е. стадия 1 и стадия 2 цикла разработки кода
сливаются в одну стадию), что дает возможность выявить несты-
ковки между кодами разных авторов на раннем этапе.
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. Попросите релиз-инженеров, чтобы те создали на интра-
нете динамически обновляемую страничку с информацией
о
• версии и
• подверсии, т.е. билде (об этом позже),
каждого внутреннего тестировочного веб-сайта.
В завершение кодирования поговорим еще о паре вещей.
Хотя и спеки, а иногда даже и сами идеи для спеков — ребятки
не без греха, большинство багов зачинается именно при написа-
нии кода. При кодировании появляется присущий только этой
стадии и одновременно самый простой в нахождении вид бага —