Как можно автоматизировать проверку инсталляции

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

Обратная сторона качества

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

Том Демарко и Тимоти Листер. «Человеческий фактор: успешные проекты и команды»

Источник:  Форум портала для IT-менеджеров: www.it4business.ru

Инструментарий тестировщика

Думаю, у каждого it-шника есть свой набор излюбленных инструментов. Наверно у тестировщиков он самый разнообразный. Хочу поделиться своим, список далеко неполный, постараюсь перечислить основное. Я тестирую Win32 приложения, поэтому и инструментарий у меня соответствующий.

Генерация xml-документов с помощью VBScript

Многие програмы хранят данные/настройки и т. п. в xml-документах. Часто при тестировании необходимо проверить что программа корректно ведет себя на довольно большом объеме этих саммых данных. Для этого бывает достаточно просто сгенерировать «большой» xml-документ. В принципе, для этого существуют специальные утилиты, но мне это проще сделать с помощью VBScript :) Собственно, о том как это сделать, я и собираюсь рассказать.

Разработка сценариев тестирования

Решил поделиться схемой разработки testcase’ов, которой пользуюсь сам. Не претендую на полноту и уникальность, сейчас меня такой подход полностью устраивает. Возможно, кто-нибудь сможет извлечь из него что-то полезное и для себя. Собственно, процесс разработки сценариев тестирования состоит из четырех этапов:

1. Определение требований к ПО
2. Группировка требований по приоритету
3. Определение use-case’ов
4. Разработка сценариев тестирования на основе определенных use-case’ов

Непрерывная регрессия

Захотелось поговорить о регрессионном тестировании. Как к этому делу подходить. Вначале о том, что же с моей точки зрения представляет собой регрессионное тестирование (РТ). РТ – это тестирование, направленное на проверку того, что объект тестирования со временем не регрессирует по какому-то показателю качества. Т.е. в общем случае к РТ может относиться любой вид тестирования (функциональное, производительности, юзабилити и пр.). Но чаще всего речь идет о регрессионном функциональном тестировании, т.к. функциональность – наиболее важный показатель. Как следует из определения РТ, это некий набор тестов, который выполняется с некоторой периодичностью. И тут возникают следующие вопросы:

1. Как часто надо выполнять данные тесты?
2. Какие именно тесты необходимо включить в набор РТ?

Собственно, на эти вопросы я и постараюсь ответить.

Реальность — это убийство прекрасной теории бандой мерзких фактов.

Роберт Гласс. Факты и заблуждения профессионального программирования.

Дефект – это диагноз, или зачем тестировщику владеть инструментами администратора.

О дефектах в тестировании сказано много. Существуют различные определения дефекта. Я бы хотел предложить взглянуть на предмет несколько с иной стороны.

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

Тестировщик может понятия не иметь КАК лечить, но рассказать ЧТО лечить – это его работа. Идя к врачу, Вы ведь надеетесь не на то, что он Вам расскажет как у Вас что-то болит, а на то, что он поставит верный диагноз. Но для того чтобы поставить верный «диагноз», необходимо обладать солидным багажом знаний, и владеть соответствующими инструментами. Развивая аналогию с врачом, можно сказать что нормальный человек не пойдет к хирургу, который не разбирается в анатомии, терапевту, который не знает как измерить температуру и т.д. Другими словами, на тестирование поступает «больной», и общая задача команды – вылечить его. Тестировщикам нужно поставить диагноз, разработчикам – вылечить «заболевание».

Имея в своем арсенале набор утилит (те же Sysinternals, различные мониторы и т.д.) и знания рабочего окружения, можно намного эффективнее находить причины возникновения дефектов. А это, в свою очередь, экономит время при исправлении дефектов. И потом это просто интересно – докопаться до сути! Это вносит разнообразие в работу, тестировщик превращается в своего рода исследователя. Тут важно соблюсти «золотую середину», не углубляться в малоперспективные и сомнительные «исследования», особенно если время ограничено. Но если помнить об этом, то тестирование может стать более увлекательным и эффективным занятием. Думаю, от этого только все выиграют.

Итого:

1. Дефект – это диагноз. «Симптомы» только помогают понять его.

2. Чтобы поставить верный «диагноз», нужны инструменты и знания.

3. Не стоит слишком увлекаться исследованиями.

Синтаксис описания дефектов

Наткнулся в документе Administering & Using StarTeam 2008 (Borland) на интересное предложение по описанию дефектов. Предлагается использовать такой набор сокращений:

Shorthand	Description
1, 2, 3,…	Номер шага.
LClick	Левый клик мышкой.
RClick	Правый клик мышкой.
DClick	Двойной клик мышкой.
[ ]	Кнопка клавиатуры. For example: [F1] for Help or [F5] for Refresh.
< >	Кнопка диалогового окна. For example: Press <OK> or <Cancel>.
>	Разделитель пунктов меню. For example: Select File > Open or Topic > Tools > Reports.
//	Комментарий, не являющийся шагом выполнения сценария. For example: 3) LClick the field. // At this point my machine started to smoke.
EXP	Ожидаемый результат. For example: EXP: The focus moves to the next field.
ACT	Полученный результат. For example: ACT: The application crashes.

Описанный с помощью этих сокращений дефект, может выглядеть примерно так (пример взят из того же документа):

1. RClick the column headers in the upper pane.
2. Select Show Fields.
3. LClick Show Advanced Fields check box.
// The check box is activated.
4. LClick Show Advanced Fields check box.
// The check box is deactivated.
5. EXP: The standard fields appear in the Available Fields list box. 6. ACT: No fields appear in the Available Fields list box.

Такое описание легко читается и вызывает меньше возможных вопросов. По-моему очень удобный и простой синтаксис.

Чему учиться тестировщику

Решил поделиться некоторыми соображениями на тему обучения и развития тестировщиков. Все что я скажу это мое IMHO, так что относится к этому лучше критически.

На данный момент, я считаю, что в тестировании можно развиваться по одному из пяти основных направлений:

1. Автоматизация тестирования с использованием специализированных средств.

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

2. Инженерное направление.

Т.е. развитие в сторону системного администратора. Тестировщику довольно часто не хватает серьезных знаний по работе с какими-то технологиями (сужу по себе). В сложных проектах вводится даже отдельная должность – DBA (Database Administrator). Человек, который может создать и поддерживать необходимый стенд нужен не только в тестировании, но и в разработке.

3. Развитие по какому-то отдельному виду тестирования.

Например, нагрузочное тестирование (в т.ч. производительности). Настоящих специалистов в этой области мало, и они востребованы. На мой взгляд, интересное направление. А, например, специалисты в области безопасности вообще по-моему avis rara ;)

4. Руководство и управление.

Это развитие в сторону менеджмента тестирование. Разработка планов, управление рисками и т.д. и т.п. Т.е. тут надо будет изучать различные методологии, выбирать лучшее и адаптировать под конкретные проекты.

5. Qaulity Assurance

Иногда тестирование называют QA, это неправильно. QA – деятельность, направленная на контроль качества процессов создания ПО (а не самого ПО, как тестирование). Тоже интересное, но мало мне знакомое, направление :)

К тому же, например, автоматизация – это не только специализированные тулы. Писать полезные скрипты (на том же vbscript) может любой участник команды (начиная с менеджера). Так что нет предела совершенству, и полезные знания перечисленными направлениями не ограничиваются.