Есть такая поговорка: "С кем поведешься, от того и наберешься". Это к рассмотрению ситуации, когда в отдел, например, тестирования приходит новый сотрудник. Он начинает общаться с коллегами и в процессе работы начинает говорить, писать (описывая ситуации, возникающие во время тестирования) так, как принято среди тестировщиков. Это нормально. То же самое происходит и в отделе, например, разработки документации. В пределах одного отдела все друг друга понимают практически без проблем (опустим ситуации, когда новый сотрудник совсем новый:)). Но вот когда коммуникации затрагивают несколько отделов такого понимания может и не быть. Ничего удивительного. Просто одни привыкли называть так, а другие- иначе. И оба варианта используются сотрудниками различных отделов различных организаций, то есть никто ничего нового не выдумывал. Хорошо, если ситуаций, где можно найти такие варианты различий, не много. (ну, допустим, характер софта такой). А если только в пределах одного направления разработки таких вариантов масса? Да к тому же существует разбивка как минимум на 3 отдела (документации, разработки, тестирования), а часто больше чем на 3. Наложим на все это распределенную на несколько стран разработку. Соответственно добавляются варианты, которые предлагаются иностранным языком. Но ведь английский русских разработчиков и английский разработчиков, например, из индии- 2 большие разницы. В итоге получаем столько определений одних и тех же вещей, с которыми не так-то просто и разобраться, не говоря уже о том, что временных задержек на это не должно быть вообще. Не трудно представить, сколько лишнего времени уходит на то, чтобы разобраться с баг репортом, понять суть бага. Чтобы избегать таких ситуаций, необходимо вывести некий глоссарий и в соответствии с ним называть вещи своими "уникальными" именами. За основу можно взять общепринятые понятия, которые наиболее часто встречаются уже (в переписке, в системе баг репорта и тд), на данный момент. Если разработка распределенная- то на английском языке. Как правило, наборы готовых требований к разрабатываемому софту уже содержат большинство понятий и определений. Этим стоит воспользоваться и принять за основу.
К чему это все? Коммуникации должны быть эффективными. С точки зрения тестирования это своевременный, точный, однозначный отчет\репорт о положении дел. Если это баг репорт- то он должен быть абсолютно понятен всем участникам разработки. Не должно быть отсылки бага обратно автору за подробностями. Пусть вновь пришедшие сотрудники сделают несколько репортов под присмотром более опытных. Пусть в открытом доступе хранится некий глоссарий, который можно использовать, редактировать. Это сэкономит кучу времени в будущем.
среда, 30 сентября 2009 г.
вторник, 29 сентября 2009 г.
Расстановка приоритетов тест кейсов
Процесс тестирования предполагает своевременное донесение до необходимого количества заинтересованных лиц текущего состояния разрабатываемого софта. Я думаю, что всем понятно, что заказчик меньше всего ждет программу с идеальным интерфейсом, бантиками и т.д., но не выполняющую своих прямых обязанностей. Так же как и руководители разработки ожидают, что внедрение нового\ изменение существующего функционала не вредит, не портит основной функционал, ядро системы. Поэтому при составлении тест плана необходимо четко расставлять приоритеты тестирования тех или иных областей тестируемого приложения ввиду ограниченного срока разработки ПО и, соответственно, его тестрования.
В зависимости от вида тестирования (модульное, системное, интеграционное) приоритеты могут изменяться, но суть- есть вещи, которые должны быть протестированы в первую очередь, и есть вещи, тестирование которых может (и должно) быть отложено, остается той же.
Сначала необходимо определить критичные области приложения (такие как, например, ядро системы, основной функционал, ради которого и ведется вся разработка). Эти области должны быть протестированы в первую очередь насколько это представляется возможным. Затем произвести разбивку по важным, средним и маловажным областям. При этом нужно пользоваться набором требований к ПО, которые чаще всего отражают критичные и важные области. Проще всего это сделать, уже имея дерево сгруппированных тест кейсов (расстановка приоритетов упоминалась в "правилах написания тест кейсов"). Достаточно будет пройтись по нему и расставить уровни критичноти "части" приложения, тестируемой\проверяемой тем или иным тест кейсом. Для большей точности это можно сделать с руководителем разработчиков. Который попутно сможет также рассказать о таких моментах, как "в следующий билд должен войти такой-то и такой-то функционал, поэтому это нужно включить в первоочередные проверки." Здесь можно дополнительно проставить такой параметр, как "близость релиза" чтоли. Ведь общая задача- поставить в срок то, что нужно, и заданного качества. Поэтому будет ошибочно тестировать области приложения одинакового уровня критичности, но вперед ту, которая будет релизиться позже.
Таким образом выстраиваем список тест кейсов, в котором будет указано когда (в какой последовательности) будет тестироваться тот или иной функционал. Соответственно, зная "скорость", можно определиться со временем.
В зависимости от вида тестирования (модульное, системное, интеграционное) приоритеты могут изменяться, но суть- есть вещи, которые должны быть протестированы в первую очередь, и есть вещи, тестирование которых может (и должно) быть отложено, остается той же.
Сначала необходимо определить критичные области приложения (такие как, например, ядро системы, основной функционал, ради которого и ведется вся разработка). Эти области должны быть протестированы в первую очередь насколько это представляется возможным. Затем произвести разбивку по важным, средним и маловажным областям. При этом нужно пользоваться набором требований к ПО, которые чаще всего отражают критичные и важные области. Проще всего это сделать, уже имея дерево сгруппированных тест кейсов (расстановка приоритетов упоминалась в "правилах написания тест кейсов"). Достаточно будет пройтись по нему и расставить уровни критичноти "части" приложения, тестируемой\проверяемой тем или иным тест кейсом. Для большей точности это можно сделать с руководителем разработчиков. Который попутно сможет также рассказать о таких моментах, как "в следующий билд должен войти такой-то и такой-то функционал, поэтому это нужно включить в первоочередные проверки." Здесь можно дополнительно проставить такой параметр, как "близость релиза" чтоли. Ведь общая задача- поставить в срок то, что нужно, и заданного качества. Поэтому будет ошибочно тестировать области приложения одинакового уровня критичности, но вперед ту, которая будет релизиться позже.
Таким образом выстраиваем список тест кейсов, в котором будет указано когда (в какой последовательности) будет тестироваться тот или иной функционал. Соответственно, зная "скорость", можно определиться со временем.
понедельник, 28 сентября 2009 г.
Правила работы с багами (баг репортами).
В этом посте хочу поделиться с некоторыми устоявшимися у нас правилами и требованиями, которые необходимо соблюдать при постинге багов в багтрекнговые системы, при верификации фиксов и т.д. Не говорю, что они подойдут всем и во всем, но столкнувшись с проблемами, я решил превентировать их в будущем введением именно такого регламента.
Вообще каждая багтрекинговая система содержит в себе достаточно всяких требований, условий и так далее. Но иногда, в чем я убедился, этого не совсем достаточно, особенно для новичков в тестировании.
Работа с дефектами:
1. Вся работа с дефектами должна быть в соответствии с требованиями TFS (Напомню, что это наш основной инструмент). 1. Каждый дефект репорт в багтрекинговой системе: 1) имеет уникальный номер ID; заголовок (краткий, но максимально информативный для поиска и ориентации по нему); важность; срочность; ссылки на связанные дефекты, ТС, требования (обязательно для дефектов требований, спека), документацию (при необходимости); описание (что, где и когда именно не работает(работает неправильно));набор шагов для воспроизведения (необходимо указывать максимально короткую последовательность из возможных, то есть проводить доподлинное выявление дефекта, его локализацию), если существуют другие способы появления этого же дефекта- необходимо их указать (например, в комментариях); к какому приложению и\или его области дефект относится, в каком билде найдет, в какой билд вошел фикс; статус (в каком состоянии он находится, кто в данный момент времени над ним работает, кто автор, кто ответственные);комментарии, историю изменений. 2) описывает уникальное состояние приложения (на данный момент времени). 3) должен содержать максимальное количество (уникальной) информации о дефекте (xml, скрины, графические файлы и тд).
Остановлюсь на заголовке подробнее. Правильный заголовок должен отражать суть дефекта, быть таким, чтобы по нему можно было найти дефект поиском, в то же время- кратким и емким. Если это исключение, значит пишем, что "исключение при...", а не "появляется сообщение с исключением..". Второй вариант допустим при дефекте вывода не того сообщения, которое должно быть, например.
2. При проверке фикса, помимо самого дефекта должно проверяться минимальное окружение (метод эд хок). Этим пунктом хотелось бы предотвратить ситуации, когда дефект пофиксен, но существует аналогичный\похожий дефект (или даже не один), которые легко находятся. Но не перебором граничных, "интересных" значений, например, а включением мозга. При котором строятся попытки, варианты того, в каких случаях можно еще получить схожее поведение программы и добиться получения дефекта.
3. Недопустимо повторение дефектов в системе багтрекинга. Перед постингом необходимо убедиться в отсутствии такового же дефекта в системе, используя поиск. При необходимости- открыть заново с соответствующим комментарием.
4. Каждый дефект репорт должен содержать описание только одного дефекта. при отклонениях должен быть создан другой репорт (за исключением некоторых случаев, которые будут оговариваться отдельно). Здесь имеется ввиду то, что нельзя запихивать несколько дефектов в один репорт. Не путать с одним дефектом и несколькими путями (возможностями) его проявления.
5. В сложных ситуациях когда дефект "мигрирует" или "изменяется" (либо из одной области приложения в другую, либо изменяется поведение и тд) нужно закрыть старый дефект (с комментарием) и открыть новый. Иногда встречаются такие ситуации, когда шаги для воспроизведения дефекта становятся мало похожи на первоначальное описание.
6. Верификацию фикса проводит автор дефекта. Ad hok ("вокруг этого дефекта")- можно тестировать не обязательно автору. Довольно противоречивый пункт. Однако есть мнение, что никто кроме автора не знает сам дефект лучше, какие-то подробности, нюансы (хотя они должны бить прокомментированы).
7. При нахождении дефекта необходимо проверить все возможные способы его получения и смежные области. То есть необходимо подумать и проверить- где этот дефект или его влияние) могут быть найдены еще.
8. При описании дефекта следует иметь ввиду, что при проверке фикса следует проверять все возможные (логически реализуемые) варианты проявления дефекта (в зависимости от ОС, окружения и тд.). Но не следует перегружать описание дефекта перечислением этих вариантов. Достаточно указать на достаточно(!) различные варианты.
9. Количество шагов для воспроизведения должно быть минимальным, но достаточным (дефект должен быть максимально локализован).
10. Необходимо проводить регулярные bug review, bug status review.
11. Описание дефектов необходимо дополнять достаточным количеством скриншотов.
12. Как правило каждый дефект имеет свое влияние на выполнение\невыполнение ТС\TS и др. Поэтому должен содержать ссылки на зависимые элементы.
13. Что нужно проверять при проверке фикса\новой фичи: 1. проверять, что то, что сделали (написали\пофиксили) разработчики, работает вообще. 2. проверять, что то, что сделали (написали\пофиксили) разработчики, работает корректно. 3. проверять, что то, что сделали (написали\пофиксили) разработчики, не ломает существующий, корректно работающий функционал.
14. Проверка фикса (и не только): 1. В первую очередь производится попытка воспроизведения бага (по описанным шагам). 2. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.). 3. Проверка этих областей. 4. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)). 5. Проверка этих методов. Минимальное свободное тестирование (сугубо специфично): 6. Проверка работы с некорректными данными (например, сохранение, поиск по ним). 7. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт). 8. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными обязательными полями). 9. Если, например, тестируется установка дистрибутива или импорт данных, имеет смысл использовать виртуальные машины для одновременной проверки разного функционала или параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и бытрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).
А так же читаем про управление дефектами на http://software-testing.ru/library/testing/bug-tracking?layout=default
Вообще каждая багтрекинговая система содержит в себе достаточно всяких требований, условий и так далее. Но иногда, в чем я убедился, этого не совсем достаточно, особенно для новичков в тестировании.
Работа с дефектами:
1. Вся работа с дефектами должна быть в соответствии с требованиями TFS (Напомню, что это наш основной инструмент). 1. Каждый дефект репорт в багтрекинговой системе: 1) имеет уникальный номер ID; заголовок (краткий, но максимально информативный для поиска и ориентации по нему); важность; срочность; ссылки на связанные дефекты, ТС, требования (обязательно для дефектов требований, спека), документацию (при необходимости); описание (что, где и когда именно не работает(работает неправильно));набор шагов для воспроизведения (необходимо указывать максимально короткую последовательность из возможных, то есть проводить доподлинное выявление дефекта, его локализацию), если существуют другие способы появления этого же дефекта- необходимо их указать (например, в комментариях); к какому приложению и\или его области дефект относится, в каком билде найдет, в какой билд вошел фикс; статус (в каком состоянии он находится, кто в данный момент времени над ним работает, кто автор, кто ответственные);комментарии, историю изменений. 2) описывает уникальное состояние приложения (на данный момент времени). 3) должен содержать максимальное количество (уникальной) информации о дефекте (xml, скрины, графические файлы и тд).
Остановлюсь на заголовке подробнее. Правильный заголовок должен отражать суть дефекта, быть таким, чтобы по нему можно было найти дефект поиском, в то же время- кратким и емким. Если это исключение, значит пишем, что "исключение при...", а не "появляется сообщение с исключением..". Второй вариант допустим при дефекте вывода не того сообщения, которое должно быть, например.
2. При проверке фикса, помимо самого дефекта должно проверяться минимальное окружение (метод эд хок). Этим пунктом хотелось бы предотвратить ситуации, когда дефект пофиксен, но существует аналогичный\похожий дефект (или даже не один), которые легко находятся. Но не перебором граничных, "интересных" значений, например, а включением мозга. При котором строятся попытки, варианты того, в каких случаях можно еще получить схожее поведение программы и добиться получения дефекта.
3. Недопустимо повторение дефектов в системе багтрекинга. Перед постингом необходимо убедиться в отсутствии такового же дефекта в системе, используя поиск. При необходимости- открыть заново с соответствующим комментарием.
4. Каждый дефект репорт должен содержать описание только одного дефекта. при отклонениях должен быть создан другой репорт (за исключением некоторых случаев, которые будут оговариваться отдельно). Здесь имеется ввиду то, что нельзя запихивать несколько дефектов в один репорт. Не путать с одним дефектом и несколькими путями (возможностями) его проявления.
5. В сложных ситуациях когда дефект "мигрирует" или "изменяется" (либо из одной области приложения в другую, либо изменяется поведение и тд) нужно закрыть старый дефект (с комментарием) и открыть новый. Иногда встречаются такие ситуации, когда шаги для воспроизведения дефекта становятся мало похожи на первоначальное описание.
6. Верификацию фикса проводит автор дефекта. Ad hok ("вокруг этого дефекта")- можно тестировать не обязательно автору. Довольно противоречивый пункт. Однако есть мнение, что никто кроме автора не знает сам дефект лучше, какие-то подробности, нюансы (хотя они должны бить прокомментированы).
7. При нахождении дефекта необходимо проверить все возможные способы его получения и смежные области. То есть необходимо подумать и проверить- где этот дефект или его влияние) могут быть найдены еще.
8. При описании дефекта следует иметь ввиду, что при проверке фикса следует проверять все возможные (логически реализуемые) варианты проявления дефекта (в зависимости от ОС, окружения и тд.). Но не следует перегружать описание дефекта перечислением этих вариантов. Достаточно указать на достаточно(!) различные варианты.
9. Количество шагов для воспроизведения должно быть минимальным, но достаточным (дефект должен быть максимально локализован).
10. Необходимо проводить регулярные bug review, bug status review.
11. Описание дефектов необходимо дополнять достаточным количеством скриншотов.
12. Как правило каждый дефект имеет свое влияние на выполнение\невыполнение ТС\TS и др. Поэтому должен содержать ссылки на зависимые элементы.
13. Что нужно проверять при проверке фикса\новой фичи: 1. проверять, что то, что сделали (написали\пофиксили) разработчики, работает вообще. 2. проверять, что то, что сделали (написали\пофиксили) разработчики, работает корректно. 3. проверять, что то, что сделали (написали\пофиксили) разработчики, не ломает существующий, корректно работающий функционал.
14. Проверка фикса (и не только): 1. В первую очередь производится попытка воспроизведения бага (по описанным шагам). 2. Во вторую- анализ областей, в которых вероятно возникновение этого бага.(Например, если был обнаружен баг с фильтром, работающим при вызове какого-то меню, то имеет смысл проверить все схожие типы меню, работающих по такому же принципу.). 3. Проверка этих областей. 4. Анализ возможности вызова повторения бага другими методами (отличающимися от описанного в баг репорте (Например, если был обнаружен баг при удалении записи, имеет смысл проверить удаление группы записей и т.п.)). 5. Проверка этих методов. Минимальное свободное тестирование (сугубо специфично): 6. Проверка работы с некорректными данными (например, сохранение, поиск по ним). 7. Повторяющиеся действия (например, попытка удаления уже удаленного объекта, двойной импорт). 8. Проверка вывода обязательных сообщений (например, при сохранении с незаполненными обязательными полями). 9. Если, например, тестируется установка дистрибутива или импорт данных, имеет смысл использовать виртуальные машины для одновременной проверки разного функционала или параллельной проверки при различных условиях (пример- при тестировании импорта\экспорта удобнее и бытрее на одной машине произвести импорт, затем экспорт, а на другой- импорт этих экспортированных данных; с последующей одновременной проверкой данных).
А так же читаем про управление дефектами на http://software-testing.ru/library/testing/bug-tracking?layout=default
пятница, 25 сентября 2009 г.
Правила написания скриптов автотестов (TestComplete)
В дополнение к предыдущему посту, и для совместного (параллельного) использования этих постов.
Обращаю сразу внимание, что правила в этом посте специфичны для конкретного проекта, конкретной организации и конкретных инструментов автоматизации и тестирования вообще. Поэтому основные мысли уловить можно, но перед использованием в других проектах\компаниях эти правила следует заточить под свою спецтфику. У нас инструмент автотестрования- TestComplete 6.52. Багтрекинг - TFS. ОС- Vista, WinSserv2003, WinSserv2008. Виртуализация- VMWare. MS VisualStudio2008.
Итак сами правила:
1. Правила создания тест кейсов. Без комментариев :)
2. Инструкция к тесткомплиту. Без комментариев :) Хорошо, что есть на русском и на английских языках.
3. Структура: нумерация и название ТС, идентичны ручным ТС. Иначе не поймешь, что проверяет тот или иной скрипт.
4. Порядок выполнения может быть изменен. Так как часто создаются опреджеленные наборы скриптов, а не прогоняются все сразу.
5. Структура: первый проект (ТС) содержит скрипт (назовем его "Reference"), содержащий функции и методы, испотльзуемые в других ТС. Тут следует прокомментировать: оптимальным вариантом представлялось такая организация- тест кейс=проект (project) тесткомплита, набор тест кейсов=(project suite) съют. сам скрипт (script)= набор функций (function).
Каждый ТС (проект) содержит несколько скриптов: Первый- ссылка на скрипт "Reference" первого проекта.
6. Структура: первый проект (ТС) содержит скрипт ("Reference"), содержащий функции и методы, используемые в других ТС.
7. Структура: остальные ТС (все кроме первого) содержат основные скрипты ТСа ("Main" и "Local _Reference"), и "ссылку" на скрипт ("Reference") скрипт (выглядит эта ссылка просто как скрипт). Таким образом у нас имеется 3 скриптовых элемента в каждом проекте: 1)одно хранилище ("Reference") функций и методов, используемых в различных скриптах, находящееся (физически) в первом проекте и вызываемое из других проектов (ссылки); 2)"Main" скрипт в каждом проекте, в котором находятся наборы функций, необходимых для выполнения тест кейса; и 3)"Local _Reference" скрипт, в котором находятся "локальные" функции, которые сделаны для того, чтобы не загромождать "Main" скрипт, облегчать процесс "понимания" скрипта, облегчать модификацию и т.д. Поясню зачем это нужно: при выполнении тестирования часто приходится повторять одни и те же действия по многу раз. Ясно, что иметь одинаковое описание этих действий (функцию или ее часть) во множестве скриптов совершенно неэффективно, тем более подумайте о процессе модификации такой функции при необходимости. Поэтому эта функция выносится в отдельное место (скрипт "Reference", или вообще в отдельную библиотеку, но пока не будем усложнять) и вызывается при необходимости. Таким образом, когда нужно будет исправить скрипт в этом месте работы, мы правим только одну вызываемую функцию и все. Далее: основной скрипт проекта ("Main") содержит основные функции проверки- например, 3 штуки: открыть форму, внести изменения, сохранить. Логично предположить, что 1 и 3 действия будут проделываться многократно при тестировании (хотя я заносил в скрипт "Reference" функции уже при однократном повторении). Поэтому выносим их. 2 действие выносить смысла нет, так как, допустим!, вносим какие-то уникальные изменения, для данной конкретной проверки.
Однако расписывать эту функцию прямо в мейн скрипте не стоит- потом сложно будет разбираться в этом нагромождении (как правило функции содержат в себе множество вызовов других функций). Поэтому выносим ее в скрипт "Local _Reference".
8. Структура: При написании функций и методов необходимо четко обозначать конечные действия: необходимо оценивать специфику работы приложения в контексте того или иного скрипта (функции). Например, при редактировании свойств на одной из вкладок свойств какого-либо класса, возможны 2 различных направления продолжения действий: либо сохранить\отменить, либо перейти на другую вкладку и редактировать свойства там. В таком случае эффективнее, с точки зрения процесса, будет писать функцию редактирования свойств, которая будет лишь "редактировать" свойства, но не сохранять\отменять или переходить на другие вкладки, оставляя возможность выбора дальнейших действий и, соответственно, возможность использования этой функции в максимальном количестве скриптов.
9. Структура: все функции и методы должны иметь уникальные имена. В скрипте функций ("Reference")- "говорящее название" (например, function DeleteChildClass()). в основном скрипте ("Main")- неполный номер ТС после названия функции. (например, function DeleteChildClass11231(), где А0011231- номер ТС). Это нужно для того, чтобы не путать фукнкции из "Local _Reference" и "Reference" скриптов. А это возможно, потому что один скрипт может содержать в себе одинаковые проверки, но с, допустим, различными данными: в одном случае это будет стандартная проверка (вызов из "Reference"), в другом- специфическая (вызов из "Local _Reference"). Действия почти одни и те же, имена функций похожи, но обязаны различаться.
10. В функции первым комментом должно идти описание того, что эта функция делает. (например, "// Создание "testclass""). Чтобы не ломать голову читая сам скрипт.
11. В "Main" скрипте также должно быть описание того, что этот ТС делает ("// создание класса ").
12. Все скрипты, обращающиеся к другим скриптам должны иметь ссылки на них в начале скрипта. Особенность инструмента. Собственно, без этого ссылки работать не будут.
13. Все функции должны иметь структуру "try-catch". Весь набор скриптов не должен останавливаться при выпадании исключения приложения.
14. Скрипт должен быть написан в соответствии с ручным ТС. То есть с выделением и обозначением шагов (групп шагов), предустановок и постустановок. (допускается copy\paste описания шага из ручного ТС).
15. Отправляемые в лог сообщения и ошибки должны быть понятны всем участникам разработки. Не забываем, что результаты прогонов автотестов будут смотреть все желающие.
16. Функции в скрипте должны быть разграничены: "\\***". Просто для облегчения восприятия. Отлично работает "сворачивание".
17. Скрипт должен безопасно работать с приложением (метод "terminate()" недопустим в обычных тестах).
18. Верификация "внешнего" вида (GUI) должна быть сведена к минимуму. Тестирование основано на описании состояний системы.
19. Чем большее количество свойств системы верифицируется- тем лучше
20. Необходимо учитывать связанность выполнения съюта тесткомплитом. тем не менее должна быть возможность собирания отдельных съютов для тестирования тех или иных задач.
21. Обращение к процессам и их объектам должно осуществляться через переменные ("w1 = p1.QAdminForm; w2 = w1.treeViewClass;").
22. Скрипты и функции должны писаться с учетом того, что каждый из них может быть (и будет ) использован в другом скрипте или функции. Поэтому необходимо предусматривать варианты их апргрейда с выявлением зависимых ТС и их составляющих (методами занесения ошибок в лог, верификацией (в том числе дополнительной)). так же необходимо предусматривать обратную связь при внесении изменений. тесткомплит поддерживает ссылки на функции и ТС. таким образом при модификации и внесении изменений необходимо вносить их в целое дерево внутренней структуры. Начинать необходимо с внесения обязательных изменений (с решением и модификации или создании новых функций), двигаться строго в направлении от "ствола" дерева к его "ветвям". каждый случай должен обсуждаться отдельно. Идеальный вариант- определенный известный набор скриптов обращается к модифицированной функции, при этом не падают остальные скрипты и ТС. таким образом получаем минимальные затраты на модификацию. все функции в скрипте "Reference" должны быть актуальными в любой момент времени и соответствовать описанию работы приложения.
23. После выполнения каждого скрипта должны быть выполнены соответствующие действия по возврату к исходному сосоянию (за исключением оговоренных случаев).
24. Все имена объектов и значения свойств, используемых в методах и функциях- из Object Brouser Тestcomplete методом copy\paste. Так как не все символы видимы в Object Brouser. (такие как пробел). Хотя тут нужно пинать разработчиков.
25. Координатный клик допустим только в исключительных случаях.
26. Структура скрипта должна быть удобна для понимания и выделения отдельных методов и вызовов функций.
27. BuiltIn.Delay() допустим только в исключительных случаях. Пользуемся методами Wait...
28. В названии объекта (к которому обрщаемся) должно быть указано максимальное количество постоянных неизменяемых символов. Есть вероятность появления похожих по названию объектов.
29. Не допускается пропуск верификации отдельных функций, если они многократно проверены предыдущими скриптами в съюте. так как из этих скриптов могут быть собраны в будущем другие съюты.
30. При удалении, модификации объектов метаданных, должна быть проведена дополнительная верификация работы с "нужным" объектом, где должны отразиться эти изменения (сугубо специфично).
31. При блокировке выполнения скрипта, в лог должна отправляться ошибка с указанием номера бага.
32. Недопустимо многократное повторение одних и тех же шагов. Необходимо использовать стандартные операторы, функции, методы, циклы языка JScript.
33. Все новые скрипты должны добавляться в VSS (потом TFS). в конце дня- check in.
34. Приоритеты: сначала поддержка скриптов в актуальном состоянии, потом - создание новых скриптов.
35. При модификации скрипта, уже работавшего ранее, связанной с изменением в приложении, должно быть не более трех сохранений до получения рабочего скрипта. (количество прогонов после каждого сохранения не ограничено). если после 3го изменения и сохранения скрипт не работает-необходимо проинформировать руководителя тестировщиков (автоматизаторов).
36. При "ссылочном" методе поиска функции, в которую необходимо внести изменения- необходимо убедиться в ее неактуальности; в том, что именно в нее должны быть внесени изменения.
37. copy\paste кода скрипта недопустим! скорость создания скриптов обеспечивается использованием уже написанных функций, а не копированием кода.
38. Допускается клонирование проектов, с незамедлительным внесением изменений в названия проекта, скриптов, функций, объектов и код скриптов. Рабочий скрипт (если таковой присутствует необходимо очищать от старого скопированного кода). Добавление новых проектов или элементов проектов к TFS- только после внесения описанных выше изменений.
39. Все дополнительные приложения, вызываемые из скрипта, должны быть приведены к общему виду (например, во весь экран, масштаб 100%), а затем сравнены с эталоном.
40. Все скрипты должны использовать только БД, созданную для автоматизированного тестирования. каждый вечер она автоматически бэкапится.
41. Лучше чаще использовать возможности Object Brouser (свойства и методы), чем Recorder.
42. Необходимо учитывать расположение исполняемых файлов, для запуска приложения. оптимальный вариант- использование установщика приложения и запуск из директории установки.
43. Скрипт должен отправлять в лог такие сообщения\ошибки, чтобы были понятны причина возникновения исключения и его "местоположение" (во время выполнения). То есть, если, например, сравниваются свойства какого-либо объекта, и какое-то свойство имеет значение, не соответствующее ожидаемому, то сначала в лог должна отправиться ошибка с указанием на различие, а потом уже автоматическая ошибка, что ТС fails.
44. Структура скрипта должна предусматривать возможность запуска и выполнения скрипта под различными ОС (XP, Vista, Serv 03, 08) (первоначально- Vista и XP); То есть методы и функции должны быть написаны с учетов всех соответствующих различий в ОСах- необходимо максимально стремиться к унификации функций относительно различных ОС, в тех случаях, где это невозможно- должны быть написаны различные функции под все необходимые ОС, и взависимости от вида ОС, должны выбираться те или иные функции, методы, переменные и т.д.
45. В скрипте должно содержаться максимально допустимое количество проверок свойств приложения. (У каждого объекта существует несколько свойств, пригодных для верификации, обычно существует большое количество таких объектов в любой момент времени).
46. В случаях, когда невозможно избежать применения схожих (повторяющихся) действий при работе с приложением, необходимо применять различные концептуальные подходы к описанию и, соответственно, к выполнению этих действий. Для более полного охвата тестируемого функционала и методов работы с ним.
47. При выборе объектов, например, в дереве (tree) должен использоваться метод Select(), а не Click() там, где это возможно.
48. Необходимо учитывать, что на разных ОСях, на виртуалках и при удаленном доступе могут быть задержки выполнения скрипта. Поэтому необходимо использовать "Wait*" методы при написании скрипта там, где это возможно.
Как-то так. Хотя подозреваю, что большинство пунктов необходимо комментировать дополнительно, объясняя суть, необходимость использования. Подождем уточненной статистики..
Обращаю сразу внимание, что правила в этом посте специфичны для конкретного проекта, конкретной организации и конкретных инструментов автоматизации и тестирования вообще. Поэтому основные мысли уловить можно, но перед использованием в других проектах\компаниях эти правила следует заточить под свою спецтфику. У нас инструмент автотестрования- TestComplete 6.52. Багтрекинг - TFS. ОС- Vista, WinSserv2003, WinSserv2008. Виртуализация- VMWare. MS VisualStudio2008.
Итак сами правила:
1. Правила создания тест кейсов. Без комментариев :)
2. Инструкция к тесткомплиту. Без комментариев :) Хорошо, что есть на русском и на английских языках.
3. Структура: нумерация и название ТС, идентичны ручным ТС. Иначе не поймешь, что проверяет тот или иной скрипт.
4. Порядок выполнения может быть изменен. Так как часто создаются опреджеленные наборы скриптов, а не прогоняются все сразу.
5. Структура: первый проект (ТС) содержит скрипт (назовем его "Reference"), содержащий функции и методы, испотльзуемые в других ТС. Тут следует прокомментировать: оптимальным вариантом представлялось такая организация- тест кейс=проект (project) тесткомплита, набор тест кейсов=(project suite) съют. сам скрипт (script)= набор функций (function).
Каждый ТС (проект) содержит несколько скриптов: Первый- ссылка на скрипт "Reference" первого проекта.
6. Структура: первый проект (ТС) содержит скрипт ("Reference"), содержащий функции и методы, используемые в других ТС.
7. Структура: остальные ТС (все кроме первого) содержат основные скрипты ТСа ("Main" и "Local _Reference"), и "ссылку" на скрипт ("Reference") скрипт (выглядит эта ссылка просто как скрипт). Таким образом у нас имеется 3 скриптовых элемента в каждом проекте: 1)одно хранилище ("Reference") функций и методов, используемых в различных скриптах, находящееся (физически) в первом проекте и вызываемое из других проектов (ссылки); 2)"Main" скрипт в каждом проекте, в котором находятся наборы функций, необходимых для выполнения тест кейса; и 3)"Local _Reference" скрипт, в котором находятся "локальные" функции, которые сделаны для того, чтобы не загромождать "Main" скрипт, облегчать процесс "понимания" скрипта, облегчать модификацию и т.д. Поясню зачем это нужно: при выполнении тестирования часто приходится повторять одни и те же действия по многу раз. Ясно, что иметь одинаковое описание этих действий (функцию или ее часть) во множестве скриптов совершенно неэффективно, тем более подумайте о процессе модификации такой функции при необходимости. Поэтому эта функция выносится в отдельное место (скрипт "Reference", или вообще в отдельную библиотеку, но пока не будем усложнять) и вызывается при необходимости. Таким образом, когда нужно будет исправить скрипт в этом месте работы, мы правим только одну вызываемую функцию и все. Далее: основной скрипт проекта ("Main") содержит основные функции проверки- например, 3 штуки: открыть форму, внести изменения, сохранить. Логично предположить, что 1 и 3 действия будут проделываться многократно при тестировании (хотя я заносил в скрипт "Reference" функции уже при однократном повторении). Поэтому выносим их. 2 действие выносить смысла нет, так как, допустим!, вносим какие-то уникальные изменения, для данной конкретной проверки.
Однако расписывать эту функцию прямо в мейн скрипте не стоит- потом сложно будет разбираться в этом нагромождении (как правило функции содержат в себе множество вызовов других функций). Поэтому выносим ее в скрипт "Local _Reference".
8. Структура: При написании функций и методов необходимо четко обозначать конечные действия: необходимо оценивать специфику работы приложения в контексте того или иного скрипта (функции). Например, при редактировании свойств на одной из вкладок свойств какого-либо класса, возможны 2 различных направления продолжения действий: либо сохранить\отменить, либо перейти на другую вкладку и редактировать свойства там. В таком случае эффективнее, с точки зрения процесса, будет писать функцию редактирования свойств, которая будет лишь "редактировать" свойства, но не сохранять\отменять или переходить на другие вкладки, оставляя возможность выбора дальнейших действий и, соответственно, возможность использования этой функции в максимальном количестве скриптов.
9. Структура: все функции и методы должны иметь уникальные имена. В скрипте функций ("Reference")- "говорящее название" (например, function DeleteChildClass()). в основном скрипте ("Main")- неполный номер ТС после названия функции. (например, function DeleteChildClass11231(), где А0011231- номер ТС). Это нужно для того, чтобы не путать фукнкции из "Local _Reference" и "Reference" скриптов. А это возможно, потому что один скрипт может содержать в себе одинаковые проверки, но с, допустим, различными данными: в одном случае это будет стандартная проверка (вызов из "Reference"), в другом- специфическая (вызов из "Local _Reference"). Действия почти одни и те же, имена функций похожи, но обязаны различаться.
10. В функции первым комментом должно идти описание того, что эта функция делает. (например, "// Создание "testclass""). Чтобы не ломать голову читая сам скрипт.
11. В "Main" скрипте также должно быть описание того, что этот ТС делает ("// создание класса ").
12. Все скрипты, обращающиеся к другим скриптам должны иметь ссылки на них в начале скрипта. Особенность инструмента. Собственно, без этого ссылки работать не будут.
13. Все функции должны иметь структуру "try-catch". Весь набор скриптов не должен останавливаться при выпадании исключения приложения.
14. Скрипт должен быть написан в соответствии с ручным ТС. То есть с выделением и обозначением шагов (групп шагов), предустановок и постустановок. (допускается copy\paste описания шага из ручного ТС).
15. Отправляемые в лог сообщения и ошибки должны быть понятны всем участникам разработки. Не забываем, что результаты прогонов автотестов будут смотреть все желающие.
16. Функции в скрипте должны быть разграничены: "\\***". Просто для облегчения восприятия. Отлично работает "сворачивание".
17. Скрипт должен безопасно работать с приложением (метод "terminate()" недопустим в обычных тестах).
18. Верификация "внешнего" вида (GUI) должна быть сведена к минимуму. Тестирование основано на описании состояний системы.
19. Чем большее количество свойств системы верифицируется- тем лучше
20. Необходимо учитывать связанность выполнения съюта тесткомплитом. тем не менее должна быть возможность собирания отдельных съютов для тестирования тех или иных задач.
21. Обращение к процессам и их объектам должно осуществляться через переменные ("w1 = p1.QAdminForm; w2 = w1.treeViewClass;").
22. Скрипты и функции должны писаться с учетом того, что каждый из них может быть (и будет ) использован в другом скрипте или функции. Поэтому необходимо предусматривать варианты их апргрейда с выявлением зависимых ТС и их составляющих (методами занесения ошибок в лог, верификацией (в том числе дополнительной)). так же необходимо предусматривать обратную связь при внесении изменений. тесткомплит поддерживает ссылки на функции и ТС. таким образом при модификации и внесении изменений необходимо вносить их в целое дерево внутренней структуры. Начинать необходимо с внесения обязательных изменений (с решением и модификации или создании новых функций), двигаться строго в направлении от "ствола" дерева к его "ветвям". каждый случай должен обсуждаться отдельно. Идеальный вариант- определенный известный набор скриптов обращается к модифицированной функции, при этом не падают остальные скрипты и ТС. таким образом получаем минимальные затраты на модификацию. все функции в скрипте "Reference" должны быть актуальными в любой момент времени и соответствовать описанию работы приложения.
23. После выполнения каждого скрипта должны быть выполнены соответствующие действия по возврату к исходному сосоянию (за исключением оговоренных случаев).
24. Все имена объектов и значения свойств, используемых в методах и функциях- из Object Brouser Тestcomplete методом copy\paste. Так как не все символы видимы в Object Brouser. (такие как пробел). Хотя тут нужно пинать разработчиков.
25. Координатный клик допустим только в исключительных случаях.
26. Структура скрипта должна быть удобна для понимания и выделения отдельных методов и вызовов функций.
27. BuiltIn.Delay() допустим только в исключительных случаях. Пользуемся методами Wait...
28. В названии объекта (к которому обрщаемся) должно быть указано максимальное количество постоянных неизменяемых символов. Есть вероятность появления похожих по названию объектов.
29. Не допускается пропуск верификации отдельных функций, если они многократно проверены предыдущими скриптами в съюте. так как из этих скриптов могут быть собраны в будущем другие съюты.
30. При удалении, модификации объектов метаданных, должна быть проведена дополнительная верификация работы с "нужным" объектом, где должны отразиться эти изменения (сугубо специфично).
31. При блокировке выполнения скрипта, в лог должна отправляться ошибка с указанием номера бага.
32. Недопустимо многократное повторение одних и тех же шагов. Необходимо использовать стандартные операторы, функции, методы, циклы языка JScript.
33. Все новые скрипты должны добавляться в VSS (потом TFS). в конце дня- check in.
34. Приоритеты: сначала поддержка скриптов в актуальном состоянии, потом - создание новых скриптов.
35. При модификации скрипта, уже работавшего ранее, связанной с изменением в приложении, должно быть не более трех сохранений до получения рабочего скрипта. (количество прогонов после каждого сохранения не ограничено). если после 3го изменения и сохранения скрипт не работает-необходимо проинформировать руководителя тестировщиков (автоматизаторов).
36. При "ссылочном" методе поиска функции, в которую необходимо внести изменения- необходимо убедиться в ее неактуальности; в том, что именно в нее должны быть внесени изменения.
37. copy\paste кода скрипта недопустим! скорость создания скриптов обеспечивается использованием уже написанных функций, а не копированием кода.
38. Допускается клонирование проектов, с незамедлительным внесением изменений в названия проекта, скриптов, функций, объектов и код скриптов. Рабочий скрипт (если таковой присутствует необходимо очищать от старого скопированного кода). Добавление новых проектов или элементов проектов к TFS- только после внесения описанных выше изменений.
39. Все дополнительные приложения, вызываемые из скрипта, должны быть приведены к общему виду (например, во весь экран, масштаб 100%), а затем сравнены с эталоном.
40. Все скрипты должны использовать только БД, созданную для автоматизированного тестирования. каждый вечер она автоматически бэкапится.
41. Лучше чаще использовать возможности Object Brouser (свойства и методы), чем Recorder.
42. Необходимо учитывать расположение исполняемых файлов, для запуска приложения. оптимальный вариант- использование установщика приложения и запуск из директории установки.
43. Скрипт должен отправлять в лог такие сообщения\ошибки, чтобы были понятны причина возникновения исключения и его "местоположение" (во время выполнения). То есть, если, например, сравниваются свойства какого-либо объекта, и какое-то свойство имеет значение, не соответствующее ожидаемому, то сначала в лог должна отправиться ошибка с указанием на различие, а потом уже автоматическая ошибка, что ТС fails.
44. Структура скрипта должна предусматривать возможность запуска и выполнения скрипта под различными ОС (XP, Vista, Serv 03, 08) (первоначально- Vista и XP); То есть методы и функции должны быть написаны с учетов всех соответствующих различий в ОСах- необходимо максимально стремиться к унификации функций относительно различных ОС, в тех случаях, где это невозможно- должны быть написаны различные функции под все необходимые ОС, и взависимости от вида ОС, должны выбираться те или иные функции, методы, переменные и т.д.
45. В скрипте должно содержаться максимально допустимое количество проверок свойств приложения. (У каждого объекта существует несколько свойств, пригодных для верификации, обычно существует большое количество таких объектов в любой момент времени).
46. В случаях, когда невозможно избежать применения схожих (повторяющихся) действий при работе с приложением, необходимо применять различные концептуальные подходы к описанию и, соответственно, к выполнению этих действий. Для более полного охвата тестируемого функционала и методов работы с ним.
47. При выборе объектов, например, в дереве (tree) должен использоваться метод Select(), а не Click() там, где это возможно.
48. Необходимо учитывать, что на разных ОСях, на виртуалках и при удаленном доступе могут быть задержки выполнения скрипта. Поэтому необходимо использовать "Wait*" методы при написании скрипта там, где это возможно.
Как-то так. Хотя подозреваю, что большинство пунктов необходимо комментировать дополнительно, объясняя суть, необходимость использования. Подождем уточненной статистики..
четверг, 24 сентября 2009 г.
Правила написания тест кейсов
Как и предполагал в предыдущих постах, выкладываю эти нехитрые правила. Своим созданием они обусловлены были достаточно большой вероятностью появления в нашей организации тестировщиков с небольшим опытом, либо без такового вообще. Поэтому постарался адаптировать простые истины под нашу специфику:
1. у каждого тест кейса (ТС) уникальное имя и ID (Без этого никуда- ибо различать и не путать тест кейсы необходимо, а при наборе их в тестран такие вещи не исключение. Не забываем, что на один юз кейс может быть написано достаточно много очень похожих тест кейсов, но проверяющих совсем разные вещи или работающих в разных условиях. Необходимо их различать.) Напомню, что нумерацию тест кейсов я вводил на стадии формирования дерева юз кейсов. Делалось это примерно так: Уникальный номер тест кейса состоит из буквы (С- клиент(client), A -администратор (admin))и семи цифр. Если в указанном ниже номере присутствует менее семи цифр, необходимо добавить нужное количество нулей в конец номера. Например, тест кейс, где производится верификация количества попыток логина при неправильном пароле (первый в списке), имеет номер C1111100, второй C1112100:
1. Общие тесты приложения:
1.1 Логин:
1.1.1 Некорректный:
1.1.1.1 Некорректный пароль:
1.1.1.1.1 Количество попыток;
1.1.1.2 Корректный пароль:
1.1.1.2.1 Количество попыток;
В моем случае основной состав дерева был уже сформирован, когда пришло время браться за нумерацию. Поэтому прикинуть необходимое количество цифр для номера труда не составило. Однако необходимо помнить о вероятных перестановках структуры дерева и практически 99%ных добавлениях новых тест кейсов, и предусмотреть возможные перекомбинации номеров.
2. Должен быть указан приоритет ТС (поговорим отдельно), цель (цель проверки- что именно проверяем), источник информации(спек, список требований (ссылки на требования в системе управления требованиями), и т.д.), категория (например, функциональный, юзабилити, стресс и др.), тип (ручной, автоматический), версия.
3. Предустановки- обязательны. (как правило, каждый ТС должен быть доступен для выполнения как в составе съюта, так и в составе произвольного набора ТС; так и в отдельности от других ТС). Соответственно должны (могут) быть описаны действия по завершению ТС, но не входящие в его тело- "постустановки" (особенно для автоматизированного тестирования).
4. Версия ТС- обязательна для заполнения и отслеживания. Формируется от "0.01". Версии изменения самих шагов (непринципиальные): +0.01. Версии изменения последовательности шагов (наряду с изменениями внутри некоторых шагов): +0.1 (с округлением: 0.14->0.20).Версии глобальных изменений (или крупных и многочисленных изменений в соответствии с предыдущим вариантом) +1.00 (1.23->2.00).
5.нумерация шагов- по порядку. Без комментариев :)
6. Действие (Action)- конкретное описание конкретного действия (необходимо предусматривать возможность разностороннего получения одного и того же результата (в минимальных отступлениях, например, контекстное меню и выбор меню из тулбара), и предоставлять выбор при выполнении ТС. Для более полного охвата функционала от итерации к итерации тестирования.) Необходимо помнить, что чрезмерный разброс действий- крайне недопустим. Так же необходимо учитывать то обстоятельство, что по ручным ТС пишутся автоматические скрипты (TS). Поэтому необходимо учитывать инвариантность выполнения ТС скриптом. (То есть если в некотором скрипте была описана последовательность действий через, например, контекстное меню, то- в другом логично реализовать это через вызов меню из тулбара, и наоборот.). В отдельных случаях (например, при тестировании в ТС конкретно вызова функции\метода из меню тулбара) должна быть описана именно эта последовательность действий и никакая другая. Так же это должно быть отражено в названии и, главное, в цели самого ТС.
7. Ожидаемый результат (Result)- конкретное описание состояния приложения или конкрентой его части. должно включать в себя не только описание текущего объекта(ов), но и окружающую среду. Например, при тестировании ввода текста в ворде должно быть описано не только то, что текст введен, но и то, что он имеет стандартный формат, не выделен, не курсив и т.д., а также, что ворд имеет стандартный вид (отображены стандартные кнопки\панели, и не имеет "специальных" "отклонений", которые могут быть вызваны дополнительными действиями пользователи или машины).
8. В Любом корректном ТС должно быть не более 10-12 шагов. Отдельные исключительные случаи оговариваются отдельно.
9. При написании ТС необходимо руководствовавться всей доступной информацией для отражения последних (и возможных!) изменений приложения. Необходимо закладывать на будущее вероятность изменений приложения и заранее обдумывать принцип построения ТС для последующей модификации (если таковая понадобиться) при наименьших временных и ресурсных затратах.
10. Шаги в ТС должны быть описаны четко и понятно даже для неподготовленного человека, но тем не менее должны быть описаны в соответствии с принятым глоссарием, который формируется параллельно. При принятии решений о переименовании того или иного объекта или действия все ТС должны быть модифицированы централизованно.
11. Модификация ТС осуществляется централизовано и только при необходимости внесения критичных изменений. (нет необходимости перебирать все ТС ради изменения названия кнопки). Некритичные изменения должны накапливаться, хранится в общем доступе и отслеживаться. Количество накапливаемых изменений ограничено и должно быть регулярно согласовано.
12. Поиск шагов(слов, действий) в ТС должен осуществляться автоматическими средствами поиска (например, ctrl+F). Здесь есть, конечно, некая зависимость от среды, где хранятся ТС.
13. При нахождении нужного места(шага) необходимо убедиться в его неактуальности и потребности изменений. (так как в ТС могут быть описаны специфические вызовы функций (например, вызов старого функционала)).
14. Недопустим Copy\Paste и последующее сохранение ТС (при создании нового или модификации существующего ТС). Допустим вариант: создание, Copy\Paste, внесение изменений в атрибуты ТС (номер, название, цель, и тд), внесение изменений в тело ТС, и только потом сохранение. Хотя выгоднее писать каждый ТС с нуля, все мы помним о времени.
15. Все ТС должны быть структурированы и сгруппированы по тестируемому функционалу.
16. Допускается создание необходимого количества съютов, для регрессионного тестирования. Вопрос должен обсуждаться индивидуально для каждого случая. Помня о времени, затрачиваемом на разработку вообще и на тестирование в частности, правильнее будет собрать набор только из ТС, которые необходимо протестировать, а не из всех подряд.
17. ТС должны писаться в соответствии с расстановкой приоритетов- в начале должны быть описаны ТС "приемочного" типа. Таким образом будет производится дымовое тестирование приложения. Нет смысла тестировать неработоспособное приложение. Затем пишутся ТС, покрывающие основной функционал приложения и другие.
18. Все баги, дефекты, недочеты должны быть сколлекционированы (баги в систему багтрекинга, по недочетам, неточностям- отсылка писем, сообщений, вопросов). ТС должен быть написан, даже если существует баг, непозволяющий его выполнить на данный момент. При этом в ТС ставится пометка, что он bloked by #### (номер бага) и незакончен для редактирования(в системе багтрекинга этому багу проставляются номера ТС, на которые он влияет, чтобы после фикса бага не искать их; теем не менее должен быть проведен автоматический поиск по ТС, так как на момент постинга бага в систему окончательно не известно- все ли ТС тестирующие эту область написаны.Могут быть написаны новые ТС.). Как только баг пофиксен- ТС должен быть закончен и включен в исполняемые съюты.
19. план написания ТС- пополняемый и изменяемый. При открытии новых областей, которые должны быть протестированы, в начале корректируется план, вносятся изменения, характеризующие изменения и дополнения в съютах. А затем уже непосредственно пишутся и вносятся в систему новые ТС, изменяется старая структура. Все действия должны быть согласованы. Например, в тфс это делалось просто линками между соответствующими объектами тфс.
20. Все существенные изменения должны быть задокументированиы автором изменений и хранится в связке с каждым ТС, который был модифицирован. То есть должны быть: дата , автор, характер изменений (или сами изменения). Можно взять за основу комментарий к чекину, но чекинить за один раз придется по одному модифицированному ТС.
21. Все ТС должны быть в актуальном состоянии. Допускается "запаздывание" актуализации при неясном окончательном функционале. Не допускается начало работ по актуализации ТС при неясном окончательном функционале. Никому не нужна лишняя бесполезная работа.
22. Все баги должны быть покрыты ТС-ами. Все требования должны быть покрыты ТС-ами. Весь описанный функционал должен быть покрыт ТС-ами. В идеале :)
23. Все результаты выполнения тестирования должны хранится в системе учета и хранения результатов. Или в любом доступном, подходящем месте.
24. Необходимо исключать повторение действий, уже описанных в других ТС. Там, где это невозможно, допустимо описывать необходимые действия в предустановках или в теле ТС. (например, приложение находится в таком-то состоянии, открыто такое-то окно, с такими-то свойствами, то есть без указания конкретных действий).
25. Сначала должны быть описаны положительные ТС, потом отрицательные. Допускается одновременное внесение в план обоих типов ТС.
Все эти правила написаны для того, чтобы минимизировать время, затрачиваемое на объяснение простых истин, чтобы исключить ненужные рабочие активности, и чтобы в результате получить базу работоспособных, легкомодифицируемых тест кейсов.
1. у каждого тест кейса (ТС) уникальное имя и ID (Без этого никуда- ибо различать и не путать тест кейсы необходимо, а при наборе их в тестран такие вещи не исключение. Не забываем, что на один юз кейс может быть написано достаточно много очень похожих тест кейсов, но проверяющих совсем разные вещи или работающих в разных условиях. Необходимо их различать.) Напомню, что нумерацию тест кейсов я вводил на стадии формирования дерева юз кейсов. Делалось это примерно так: Уникальный номер тест кейса состоит из буквы (С- клиент(client), A -администратор (admin))и семи цифр. Если в указанном ниже номере присутствует менее семи цифр, необходимо добавить нужное количество нулей в конец номера. Например, тест кейс, где производится верификация количества попыток логина при неправильном пароле (первый в списке), имеет номер C1111100, второй C1112100:
1. Общие тесты приложения:
1.1 Логин:
1.1.1 Некорректный:
1.1.1.1 Некорректный пароль:
1.1.1.1.1 Количество попыток;
1.1.1.2 Корректный пароль:
1.1.1.2.1 Количество попыток;
В моем случае основной состав дерева был уже сформирован, когда пришло время браться за нумерацию. Поэтому прикинуть необходимое количество цифр для номера труда не составило. Однако необходимо помнить о вероятных перестановках структуры дерева и практически 99%ных добавлениях новых тест кейсов, и предусмотреть возможные перекомбинации номеров.
2. Должен быть указан приоритет ТС (поговорим отдельно), цель (цель проверки- что именно проверяем), источник информации(спек, список требований (ссылки на требования в системе управления требованиями), и т.д.), категория (например, функциональный, юзабилити, стресс и др.), тип (ручной, автоматический), версия.
3. Предустановки- обязательны. (как правило, каждый ТС должен быть доступен для выполнения как в составе съюта, так и в составе произвольного набора ТС; так и в отдельности от других ТС). Соответственно должны (могут) быть описаны действия по завершению ТС, но не входящие в его тело- "постустановки" (особенно для автоматизированного тестирования).
4. Версия ТС- обязательна для заполнения и отслеживания. Формируется от "0.01". Версии изменения самих шагов (непринципиальные): +0.01. Версии изменения последовательности шагов (наряду с изменениями внутри некоторых шагов): +0.1 (с округлением: 0.14->0.20).Версии глобальных изменений (или крупных и многочисленных изменений в соответствии с предыдущим вариантом) +1.00 (1.23->2.00).
5.нумерация шагов- по порядку. Без комментариев :)
6. Действие (Action)- конкретное описание конкретного действия (необходимо предусматривать возможность разностороннего получения одного и того же результата (в минимальных отступлениях, например, контекстное меню и выбор меню из тулбара), и предоставлять выбор при выполнении ТС. Для более полного охвата функционала от итерации к итерации тестирования.) Необходимо помнить, что чрезмерный разброс действий- крайне недопустим. Так же необходимо учитывать то обстоятельство, что по ручным ТС пишутся автоматические скрипты (TS). Поэтому необходимо учитывать инвариантность выполнения ТС скриптом. (То есть если в некотором скрипте была описана последовательность действий через, например, контекстное меню, то- в другом логично реализовать это через вызов меню из тулбара, и наоборот.). В отдельных случаях (например, при тестировании в ТС конкретно вызова функции\метода из меню тулбара) должна быть описана именно эта последовательность действий и никакая другая. Так же это должно быть отражено в названии и, главное, в цели самого ТС.
7. Ожидаемый результат (Result)- конкретное описание состояния приложения или конкрентой его части. должно включать в себя не только описание текущего объекта(ов), но и окружающую среду. Например, при тестировании ввода текста в ворде должно быть описано не только то, что текст введен, но и то, что он имеет стандартный формат, не выделен, не курсив и т.д., а также, что ворд имеет стандартный вид (отображены стандартные кнопки\панели, и не имеет "специальных" "отклонений", которые могут быть вызваны дополнительными действиями пользователи или машины).
8. В Любом корректном ТС должно быть не более 10-12 шагов. Отдельные исключительные случаи оговариваются отдельно.
9. При написании ТС необходимо руководствовавться всей доступной информацией для отражения последних (и возможных!) изменений приложения. Необходимо закладывать на будущее вероятность изменений приложения и заранее обдумывать принцип построения ТС для последующей модификации (если таковая понадобиться) при наименьших временных и ресурсных затратах.
10. Шаги в ТС должны быть описаны четко и понятно даже для неподготовленного человека, но тем не менее должны быть описаны в соответствии с принятым глоссарием, который формируется параллельно. При принятии решений о переименовании того или иного объекта или действия все ТС должны быть модифицированы централизованно.
11. Модификация ТС осуществляется централизовано и только при необходимости внесения критичных изменений. (нет необходимости перебирать все ТС ради изменения названия кнопки). Некритичные изменения должны накапливаться, хранится в общем доступе и отслеживаться. Количество накапливаемых изменений ограничено и должно быть регулярно согласовано.
12. Поиск шагов(слов, действий) в ТС должен осуществляться автоматическими средствами поиска (например, ctrl+F). Здесь есть, конечно, некая зависимость от среды, где хранятся ТС.
13. При нахождении нужного места(шага) необходимо убедиться в его неактуальности и потребности изменений. (так как в ТС могут быть описаны специфические вызовы функций (например, вызов старого функционала)).
14. Недопустим Copy\Paste и последующее сохранение ТС (при создании нового или модификации существующего ТС). Допустим вариант: создание, Copy\Paste, внесение изменений в атрибуты ТС (номер, название, цель, и тд), внесение изменений в тело ТС, и только потом сохранение. Хотя выгоднее писать каждый ТС с нуля, все мы помним о времени.
15. Все ТС должны быть структурированы и сгруппированы по тестируемому функционалу.
16. Допускается создание необходимого количества съютов, для регрессионного тестирования. Вопрос должен обсуждаться индивидуально для каждого случая. Помня о времени, затрачиваемом на разработку вообще и на тестирование в частности, правильнее будет собрать набор только из ТС, которые необходимо протестировать, а не из всех подряд.
17. ТС должны писаться в соответствии с расстановкой приоритетов- в начале должны быть описаны ТС "приемочного" типа. Таким образом будет производится дымовое тестирование приложения. Нет смысла тестировать неработоспособное приложение. Затем пишутся ТС, покрывающие основной функционал приложения и другие.
18. Все баги, дефекты, недочеты должны быть сколлекционированы (баги в систему багтрекинга, по недочетам, неточностям- отсылка писем, сообщений, вопросов). ТС должен быть написан, даже если существует баг, непозволяющий его выполнить на данный момент. При этом в ТС ставится пометка, что он bloked by #### (номер бага) и незакончен для редактирования(в системе багтрекинга этому багу проставляются номера ТС, на которые он влияет, чтобы после фикса бага не искать их; теем не менее должен быть проведен автоматический поиск по ТС, так как на момент постинга бага в систему окончательно не известно- все ли ТС тестирующие эту область написаны.Могут быть написаны новые ТС.). Как только баг пофиксен- ТС должен быть закончен и включен в исполняемые съюты.
19. план написания ТС- пополняемый и изменяемый. При открытии новых областей, которые должны быть протестированы, в начале корректируется план, вносятся изменения, характеризующие изменения и дополнения в съютах. А затем уже непосредственно пишутся и вносятся в систему новые ТС, изменяется старая структура. Все действия должны быть согласованы. Например, в тфс это делалось просто линками между соответствующими объектами тфс.
20. Все существенные изменения должны быть задокументированиы автором изменений и хранится в связке с каждым ТС, который был модифицирован. То есть должны быть: дата , автор, характер изменений (или сами изменения). Можно взять за основу комментарий к чекину, но чекинить за один раз придется по одному модифицированному ТС.
21. Все ТС должны быть в актуальном состоянии. Допускается "запаздывание" актуализации при неясном окончательном функционале. Не допускается начало работ по актуализации ТС при неясном окончательном функционале. Никому не нужна лишняя бесполезная работа.
22. Все баги должны быть покрыты ТС-ами. Все требования должны быть покрыты ТС-ами. Весь описанный функционал должен быть покрыт ТС-ами. В идеале :)
23. Все результаты выполнения тестирования должны хранится в системе учета и хранения результатов. Или в любом доступном, подходящем месте.
24. Необходимо исключать повторение действий, уже описанных в других ТС. Там, где это невозможно, допустимо описывать необходимые действия в предустановках или в теле ТС. (например, приложение находится в таком-то состоянии, открыто такое-то окно, с такими-то свойствами, то есть без указания конкретных действий).
25. Сначала должны быть описаны положительные ТС, потом отрицательные. Допускается одновременное внесение в план обоих типов ТС.
Все эти правила написаны для того, чтобы минимизировать время, затрачиваемое на объяснение простых истин, чтобы исключить ненужные рабочие активности, и чтобы в результате получить базу работоспособных, легкомодифицируемых тест кейсов.
среда, 23 сентября 2009 г.
Проект одного тестировщика часть 4
Итак- конвейер заработал. Автотесты прогонялись, тест кейсы писались, скрипты автотестов совершенствовались, дополнялись и увеличивались в количестве. Конечно, это происходило не так быстро как хотелось бы, ведь были еще и задачи в рамках ручного тестирования, и в рамках других направлений. Поэтому, как и считается, лучше иметь выделенного тестировщика, который будет заниматься автотестами и только ими (ну может быть за редким исключением). Потому что даже просто переключиться между задачами по
кодированию и, например, по ручному тестрованию одного из множества приложений- осуществить быстро практически невозможно, на это в любом случае необходимо время. Необходимо помнить об этом и во время планирования работ отдела тестрования, но.. опять я забегаю вперед...
Примерно к этому моменту у нас появился TFS от всем известной конторы. Перенос багов, зарепорченных в старую систему, решено было не делать. Просто какое-то время использовались обе системы, а когда непофиксенных остались единицы (в старой системе)- перенес их ручками. Все проекты ТестКомплита перенес туда же- на хранение и отслеживание изменений в tfs. Очень удобно иметь систему, в которой можно залинковать все тестовые артефакты друг на друга. Есть встроенная система управления требованиями. Они линкуются на задачи, баги. Эти в свою очередь - на тест кейсы (скрипты автотестов) и т.д. Таким образом всегда можно увидеть почему те или иные автотесты не выполняются успешно; то есть посмотреть, какие баги необходимо пофиксить\задачи выполнить, для успешного прохождения тестрана, и, сответственно, для закрытия итерации разработки (если таковые венчаются успешным тестрованием). На основе этой же системы был организован билд сервер, который автоматически собирал билды после каждого чекина. Таким образом у нас уже имелся некоторый набор билдов, который можно было хранить и при необходимости на него ссылаться. Решено было хранить только релизные (итерационные) билды (итерация - каждую неделю). По поводу необходимости- в баг репорте ставится ссылка на билд, в котором найден этот баг, и при необходимости всегда можно на этот баг посмотреть. А также плезно всегда иметь под рукой версии, которые были отданы (здесь обычно пишут- заказчику, но у нас все гораздо сложнее)(зарелизены).
К этому моменту уже длительное время было ясно, что одному ворочать все это дело невозможно. Поэтому на начальство регулярно сыпались заявления, типа "сделаю по максимуму, но вот если бы у нас были еще тестировщики, мы бы такого наваяли, что ух...".
Когда стало ясно, что расширению быть, встал вопрос- как организовать свою работу так, чтобы и уделять время обучению новичков, введению их в курс дела, ответам на море вопросов, и успевать справляться с текущими делами. Были недолгие раздумия и воспоминания чего же мне было нужно самому, чтобы максимально быстро освоиться в новой компании и влиться в процесс разработки. Как результат- решил написать правила и регламенты по основным деятельностям в области тестирования. Лучше потратить немного времени на описание процесса, нежели несколько раз рассказать это нескольким людям, а потом еще и пересказывать по мере необходимости. Всегда проще и быстрее ткнуть туда, где можно прочитать. А потом при необходимости задать вопросы, причем в нужное (оговоренное) время. Потом получилась очень приличная экономия. Эти правила в
ближайшее время и выложу сюда. Но они будут достаточно специфичными, заточенными под конкретную организацию и конкретные инсрументы, хотя в их полезности не сомневаюсь. Может кому и сгодится. А вообще эти посты в первую очередь для меня самого и моих коллег:)
Правила разместил в общем доступе- в нашей вики. Там же разместил и список линков на инет источники, которые на мой взгляд содержат полезную информацию. Так как по тестированию вообще и по его частностям написано уже не мало литературы, решил не повторяться и создать на базе тфс библиотеку тестировщика, в которую вошли (и пополняются) произведения, подходящие под нашу специфику. В том числе и журналы по
тестрованию ПО, коих сейчас выпускается в достаточном количестве. Некоторые линки: http://it4business.ru/forum/forum192.html
http://software-testing.ru/
http://www.qatutor.com/
http://javascript.ru/tutorial/basic/types
http://alexeybulat.blogspot.com/2008/05/dynat.html
http://openquality.ru/news/
http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB46
http://blogs.msdn.com/micahel/archive/2004/06/09/151778.aspx
http://www.satisfice.com/blog/
http://www.satisfice.com/kaner/
http://bugsclock.blogspot.com/
http://www.protesting.ru/
http://www.stsc.hill.af.mil/crosstalk/2002/04/leishman.html
http://www.context-driven-testing.com/
http://www.stickyminds.com/testandevaluation.aspObjectType=MIXEDTA&function=Search&newtopcat=SWTST
http://googletesting.blogspot.com/
http://www.linuxtopia.org/online_books/javascript_guides/javascript_faq/index.htm
http://blog-of-roman.blogspot.com/2008/07/cmmi.html
http://pankratov.org.ua/
http://blogs.msdn.com/imtesty/default.aspx
http://zibsun.livejournal.com/
кодированию и, например, по ручному тестрованию одного из множества приложений- осуществить быстро практически невозможно, на это в любом случае необходимо время. Необходимо помнить об этом и во время планирования работ отдела тестрования, но.. опять я забегаю вперед...
Примерно к этому моменту у нас появился TFS от всем известной конторы. Перенос багов, зарепорченных в старую систему, решено было не делать. Просто какое-то время использовались обе системы, а когда непофиксенных остались единицы (в старой системе)- перенес их ручками. Все проекты ТестКомплита перенес туда же- на хранение и отслеживание изменений в tfs. Очень удобно иметь систему, в которой можно залинковать все тестовые артефакты друг на друга. Есть встроенная система управления требованиями. Они линкуются на задачи, баги. Эти в свою очередь - на тест кейсы (скрипты автотестов) и т.д. Таким образом всегда можно увидеть почему те или иные автотесты не выполняются успешно; то есть посмотреть, какие баги необходимо пофиксить\задачи выполнить, для успешного прохождения тестрана, и, сответственно, для закрытия итерации разработки (если таковые венчаются успешным тестрованием). На основе этой же системы был организован билд сервер, который автоматически собирал билды после каждого чекина. Таким образом у нас уже имелся некоторый набор билдов, который можно было хранить и при необходимости на него ссылаться. Решено было хранить только релизные (итерационные) билды (итерация - каждую неделю). По поводу необходимости- в баг репорте ставится ссылка на билд, в котором найден этот баг, и при необходимости всегда можно на этот баг посмотреть. А также плезно всегда иметь под рукой версии, которые были отданы (здесь обычно пишут- заказчику, но у нас все гораздо сложнее)(зарелизены).
К этому моменту уже длительное время было ясно, что одному ворочать все это дело невозможно. Поэтому на начальство регулярно сыпались заявления, типа "сделаю по максимуму, но вот если бы у нас были еще тестировщики, мы бы такого наваяли, что ух...".
Когда стало ясно, что расширению быть, встал вопрос- как организовать свою работу так, чтобы и уделять время обучению новичков, введению их в курс дела, ответам на море вопросов, и успевать справляться с текущими делами. Были недолгие раздумия и воспоминания чего же мне было нужно самому, чтобы максимально быстро освоиться в новой компании и влиться в процесс разработки. Как результат- решил написать правила и регламенты по основным деятельностям в области тестирования. Лучше потратить немного времени на описание процесса, нежели несколько раз рассказать это нескольким людям, а потом еще и пересказывать по мере необходимости. Всегда проще и быстрее ткнуть туда, где можно прочитать. А потом при необходимости задать вопросы, причем в нужное (оговоренное) время. Потом получилась очень приличная экономия. Эти правила в
ближайшее время и выложу сюда. Но они будут достаточно специфичными, заточенными под конкретную организацию и конкретные инсрументы, хотя в их полезности не сомневаюсь. Может кому и сгодится. А вообще эти посты в первую очередь для меня самого и моих коллег:)
Правила разместил в общем доступе- в нашей вики. Там же разместил и список линков на инет источники, которые на мой взгляд содержат полезную информацию. Так как по тестированию вообще и по его частностям написано уже не мало литературы, решил не повторяться и создать на базе тфс библиотеку тестировщика, в которую вошли (и пополняются) произведения, подходящие под нашу специфику. В том числе и журналы по
тестрованию ПО, коих сейчас выпускается в достаточном количестве. Некоторые линки: http://it4business.ru/forum/forum192.html
http://software-testing.ru/
http://www.qatutor.com/
http://javascript.ru/tutorial/basic/types
http://alexeybulat.blogspot.com/2008/05/dynat.html
http://openquality.ru/news/
http://www.sqaforums.com/postlist.php?Cat=0&Board=UBB46
http://blogs.msdn.com/micahel/archive/2004/06/09/151778.aspx
http://www.satisfice.com/blog/
http://www.satisfice.com/kaner/
http://bugsclock.blogspot.com/
http://www.protesting.ru/
http://www.stsc.hill.af.mil/crosstalk/2002/04/leishman.html
http://www.context-driven-testing.com/
http://www.stickyminds.com/testandevaluation.aspObjectType=MIXEDTA&function=Search&newtopcat=SWTST
http://googletesting.blogspot.com/
http://www.linuxtopia.org/online_books/javascript_guides/javascript_faq/index.htm
http://blog-of-roman.blogspot.com/2008/07/cmmi.html
http://pankratov.org.ua/
http://blogs.msdn.com/imtesty/default.aspx
http://zibsun.livejournal.com/
вторник, 22 сентября 2009 г.
Проект одного тестировщика часть 3
Следующей задачей решил поставить себе описание стратегии тестирования (в первом приближении). В первом потому, что очень много вопросов организации процесса тестирования были на тот момент без ответа. И поиск этих ответов мог занять достаточно продолжительное время. Поэтому оптимальным виделось набросать
примерный вариант, а потом по мере необходимости дополнять и корректровать его. Разместил в вики для удобного доступа всем желающим. Вглядело это примерно так:
1. Этап подготовки, включающий в себя создание выделенного тестового окужения. На данном этапе ограничился лишь выделением БД, которые больше никем использоваться не будут, а также необходимо было решить вопрос их восстановления на начальный уровень. (Все остальные задачи, такие как выделение тестовых машин, серверов и др. решались позже). Напомню, что при работе приложения с БД, при автоматизированном тестировании необходимо иметь стабильные, зафиксированные данные для обеспечения возможности верификации. Этот вопрос решил созданием 2 баз- основная и ее бекап, и добавил политики безопасности, чтобы работать с ними никто кроме меня не мог. Запуск автотестов решено было организовать в ночь, чтобы не занимать мою тестовую машину днем, а также чтобы не слишком грузить сервер в течение дня, потому как выполнение автотестов требует до 60% процессора. Таким образом оставалось лишь сделать автоматическое восстановление базы с ее бекапа, и, так как это тоже требовало времени (в моем случае около 2 часов), рассчитать время запуска восстановления. Чтобы оно завершилось к моменту запуска автотестов. Что и было с успехом выполнено.
2. Написание тест кейсов по первым пунктам тест плана. Вернее сначала был написан сам тест план. Это было сделано следующим образом. Документация на тот момент уже имелась, работоспособное приложение- тоже. Поэтому решено было для начала выделить области приложения, которые будут содержать тесты одной функциональной группы. То есть сгруппировал юз кейсы (именно юз кейсы) по функциональным признакам. Юз кейсы писал используя спек и приложение. Таким образом получилось дерево юз кейсов. Примерный вид:
1. Общие тесты приложения
1.1 Логин:
1.1.1 Корректный;
1.1.2 Некорректный;
Далее производилось необходимое уточнение, более мелкая разбивка. А потом на каждый юз кейс осталось написать необходимое количество тест кейсов. Что и было сделано. Тут же следует отметить, что когда было готово дерево юз кесов (ну почти готово, так как изменения все равно впоследствии вносились), решено было задать номера юз кейсов, как на примере. Таким образом выстроилась система нумерации тест кейсов, что позволило избежать путаницы в будущем и оптимально разбить группы по номерам. Причем это было сделано так, что просто по номеру сразу можно было определить принадлежность конкретного тест кейса к той или иной группе, и при невыполнении его сразу прикинуть какой функционал неработоспособен. Во время написания тест кейсов возник стандартный вопрос- где их лучше всего хранить. Причем сразу заинтересовала возможность хранить где-нибудь рядом и результаты их выполнения. Но так как ТестКомплит предоставляет
отличный лог выполнения, который можно и экспортировать и отсылать на мыло автоматически, решено было хранить результаты все же отдельно от тест кейсов. (Обращу внимание, что ручного тестирования в больших количествах не предполагалось). Также хотелось сделать хранение в свободном доступе, с возможностью редактирования, журналирования. В результате остановился на той же вики. Были проблемы при размещении там таблиц, но они быстро решились установкой необходимых плагинов. А тест кейс у меня представляет собой таблицу с набором необходимых полей и их значений:
Имя: Название тест кейса
ID: С1312000
Приоритет: 1
Цель: верификация меню.
Источник: спек, требования...
Категория: Functional
Предустановки: Приложение запущено.
Type: Manual
Version 0.01
Исполнительная часть:
Action Expected Result
3. В итоге на некоторый момент имелся набор тест кейсов. Не забываем, что чем раньше будет введено в эксплуатацию автоматическое тестирование, тем лучше (это в моем конкретном случае). Поэтому решил выделить некоторую группу тест кейсов и написать по ним скрипты автотестов. О порядке формирования такой группы напишу отдельно, скажу сразу, что нужно было определиться с функционалом, который необходимо тестировать именно в первую очередь. Какие-то вещи могут и подождать. По мере написания скриптов вырабатывались некие правила, стандарты, о которых тоже напишу отдельно. Это включало в себя "стандартизацию" скриптовых элементов и вынесение этих элементов в отдельное хранилище для облегчения и укорения последующей модификации и ускорения написания новых скриптов. Это хранилище потом планировалось оформить в библиотеку длл. Затем была отладка скриптов, тестирование, анализ результатов, подготовка к автоматическому запуску.
Так же при написании необходимо было учесть, что прогоняться автотесты планировалось на нескольких ОС, что накладывало свой отпечаток. Отмечу, что разные Windows имеют разные особенности в таких моментах, как пути до вроде бы стандартных папок и каталогов, и самое главное- различные пути до объектов на форме приложения. Поэтому приходится придумывать решения, которые позволяют обойти такие моменты.
Еще один немаловажный фактор- я заранее знал, что интерфейсы наших приложений будут переделаны. Не уточнялось только- когда это будет. Тем не менее тестировать существующую реализацию тоже необходимо. Соответственно решено было писать скрипты так, чтобы при переделках интерфейса минимизировать апдейт скриптов ибо время-деньги, лень и т.д. Какое-то время раздумывал над возможностью такой реализации. Потом
принял рещение использовать Model Based Testing - тестирования, основанного на описаниях состояний системы и их изменениях (абстрагируемся от GUI). Это позволило мне иметь в каждый конкретный момент времени большинство работающих скриптов и минимизировать время на отладку остальных из-за изменений приложения.
В общем итоге - такой набор позволил мониторить состояние основных функций софта в каждый конкретный момент времени, что позволило постепенно переключаться на другие пункты тест плана, и другие задачи.
примерный вариант, а потом по мере необходимости дополнять и корректровать его. Разместил в вики для удобного доступа всем желающим. Вглядело это примерно так:
1. Этап подготовки, включающий в себя создание выделенного тестового окужения. На данном этапе ограничился лишь выделением БД, которые больше никем использоваться не будут, а также необходимо было решить вопрос их восстановления на начальный уровень. (Все остальные задачи, такие как выделение тестовых машин, серверов и др. решались позже). Напомню, что при работе приложения с БД, при автоматизированном тестировании необходимо иметь стабильные, зафиксированные данные для обеспечения возможности верификации. Этот вопрос решил созданием 2 баз- основная и ее бекап, и добавил политики безопасности, чтобы работать с ними никто кроме меня не мог. Запуск автотестов решено было организовать в ночь, чтобы не занимать мою тестовую машину днем, а также чтобы не слишком грузить сервер в течение дня, потому как выполнение автотестов требует до 60% процессора. Таким образом оставалось лишь сделать автоматическое восстановление базы с ее бекапа, и, так как это тоже требовало времени (в моем случае около 2 часов), рассчитать время запуска восстановления. Чтобы оно завершилось к моменту запуска автотестов. Что и было с успехом выполнено.
2. Написание тест кейсов по первым пунктам тест плана. Вернее сначала был написан сам тест план. Это было сделано следующим образом. Документация на тот момент уже имелась, работоспособное приложение- тоже. Поэтому решено было для начала выделить области приложения, которые будут содержать тесты одной функциональной группы. То есть сгруппировал юз кейсы (именно юз кейсы) по функциональным признакам. Юз кейсы писал используя спек и приложение. Таким образом получилось дерево юз кейсов. Примерный вид:
1. Общие тесты приложения
1.1 Логин:
1.1.1 Корректный;
1.1.2 Некорректный;
Далее производилось необходимое уточнение, более мелкая разбивка. А потом на каждый юз кейс осталось написать необходимое количество тест кейсов. Что и было сделано. Тут же следует отметить, что когда было готово дерево юз кесов (ну почти готово, так как изменения все равно впоследствии вносились), решено было задать номера юз кейсов, как на примере. Таким образом выстроилась система нумерации тест кейсов, что позволило избежать путаницы в будущем и оптимально разбить группы по номерам. Причем это было сделано так, что просто по номеру сразу можно было определить принадлежность конкретного тест кейса к той или иной группе, и при невыполнении его сразу прикинуть какой функционал неработоспособен. Во время написания тест кейсов возник стандартный вопрос- где их лучше всего хранить. Причем сразу заинтересовала возможность хранить где-нибудь рядом и результаты их выполнения. Но так как ТестКомплит предоставляет
отличный лог выполнения, который можно и экспортировать и отсылать на мыло автоматически, решено было хранить результаты все же отдельно от тест кейсов. (Обращу внимание, что ручного тестирования в больших количествах не предполагалось). Также хотелось сделать хранение в свободном доступе, с возможностью редактирования, журналирования. В результате остановился на той же вики. Были проблемы при размещении там таблиц, но они быстро решились установкой необходимых плагинов. А тест кейс у меня представляет собой таблицу с набором необходимых полей и их значений:
Имя: Название тест кейса
ID: С1312000
Приоритет: 1
Цель: верификация меню.
Источник: спек, требования...
Категория: Functional
Предустановки: Приложение запущено.
Type: Manual
Version 0.01
Исполнительная часть:
Action Expected Result
3. В итоге на некоторый момент имелся набор тест кейсов. Не забываем, что чем раньше будет введено в эксплуатацию автоматическое тестирование, тем лучше (это в моем конкретном случае). Поэтому решил выделить некоторую группу тест кейсов и написать по ним скрипты автотестов. О порядке формирования такой группы напишу отдельно, скажу сразу, что нужно было определиться с функционалом, который необходимо тестировать именно в первую очередь. Какие-то вещи могут и подождать. По мере написания скриптов вырабатывались некие правила, стандарты, о которых тоже напишу отдельно. Это включало в себя "стандартизацию" скриптовых элементов и вынесение этих элементов в отдельное хранилище для облегчения и укорения последующей модификации и ускорения написания новых скриптов. Это хранилище потом планировалось оформить в библиотеку длл. Затем была отладка скриптов, тестирование, анализ результатов, подготовка к автоматическому запуску.
Так же при написании необходимо было учесть, что прогоняться автотесты планировалось на нескольких ОС, что накладывало свой отпечаток. Отмечу, что разные Windows имеют разные особенности в таких моментах, как пути до вроде бы стандартных папок и каталогов, и самое главное- различные пути до объектов на форме приложения. Поэтому приходится придумывать решения, которые позволяют обойти такие моменты.
Еще один немаловажный фактор- я заранее знал, что интерфейсы наших приложений будут переделаны. Не уточнялось только- когда это будет. Тем не менее тестировать существующую реализацию тоже необходимо. Соответственно решено было писать скрипты так, чтобы при переделках интерфейса минимизировать апдейт скриптов ибо время-деньги, лень и т.д. Какое-то время раздумывал над возможностью такой реализации. Потом
принял рещение использовать Model Based Testing - тестирования, основанного на описаниях состояний системы и их изменениях (абстрагируемся от GUI). Это позволило мне иметь в каждый конкретный момент времени большинство работающих скриптов и минимизировать время на отладку остальных из-за изменений приложения.
В общем итоге - такой набор позволил мониторить состояние основных функций софта в каждый конкретный момент времени, что позволило постепенно переключаться на другие пункты тест плана, и другие задачи.
пятница, 18 сентября 2009 г.
Проект одного тестировщика часть 2
Продолжая, вспоминаю, "как все начиналось".
Поставил себе несколько целей на начальном этапе:
1. Побыстрее перезнакомиться со всеми разработчиками и
изменить их (существующее на тот момент) отношение к тестированию вообще и тестировщикам в частности. Благо некоторые из них все прекрасно понимали, некоторые получали команды сверху типа "оказывать всяческое содействие", ну а с некоторыми мы ходили пить пиво. Тут стоит упомянуть, что для этого необходимо было заранее заручиться 100% поддержкой сверху. Ибо если начальство не заинтересовано в
организации тестирования, если оно не видит в этом смысла или не может подсчитать ROI- ничего хорошего от внедрения процесса тестирования не получится.
2. Второй задачей было собрать максимум информации о разрабатываемом софте. Тут без начальства тоже не обошлось. Но и активное общение приносило свои плоды. В итоге информация появлялась, и можно было разбираться непосредственно с софтом, логикой его работы. Это был еще, конечно, далеко не спек, но намного лучше, чем ничего. Примерно на этом этапе попутно решили создавать базу знаний на вики, в которую и решено было поместить прототип спецификации. К слову, там же решено было создать и базу знаний отдела тестирования, но об этом позже.
3. Уделять достаточно времени на ручное тестирование отдельных модулей приложений. Здесь можно долго сокрушаться об отсутствии внутренних релизов, о внедрении которых напишу позже, но тем не менее разработка велась. Велась в бардаке... с элементами SCRUM. Поэтому периодически поступали задачи протестировать тот или иной функционал. И эти задачи должны были быть выполнены в независимости от остальных факторов. То есть бралась существующая документация по реализации задачи, брался ее разработчик, выяснялся "смысл жизни" (имею ввиду как оно должно работать и чего не должно делать) и проводилось тестирование. Тут сразу всплыл и пункт 4.
4. Необходимо было определиться с багтрекинговой системой, попутно воюя со всеми, кто желал получить в результате тестирования файлик с багами. В этом направлении повезло в том, что в организации использовалась самописная система постановки, учета, выполнения задач для сотрудников, которая вполне сгодилась на первое время. Сгодилась потому, что все необходимые атрибуты дефект репорта вполне в ней
нашлись и могли использоваться. Однако для объективной оценки возможностей и невозможностей этой самописной сисемы была попытка использовать Bugzilla для сравнения. То есть мы решили поднять у себя багзиллу и посмотреть на разницу между этими двумя системами. Про поднятие багзиллы можно очень долго рассказывать с использованием русских и английских идиоматических выражений в больших количествах. В принципе в инете есть описание сего процесса, есть решения сложностей, так что углубляться не стоит. В итоге на второй день поднял багзиллу и отдал на сравнение разному начальству. Тут имеет смысл сказать о том, что ни одна из этих двух систем не воспринималась как основная, на которой мы будем вести весь учет
дефектов и т.д. Все потому, что на гаризонте уже маячил TFS со всеми его хвалеными возможностями и реалиями. И все потом планировалось завязывать на него.
После сравнения мне сказали, что багзилла бедна функционально по сравнению со своей системой и мы ее юзать не будем. Сомнительно конечно, но... всегда сложнее переходить на что-то новое, чем использовать старое, проверенное, пусть даже и устаревшее. Идем дальше.
5. Так как задумывалось регрессионное тестирование проводить в автоматическом режиме, необходимо было подобрать оптимальный инструмент для этого дела. Сразу скажу, что решение об использовании автоматизации принималось без меня. Но оно вполне обосновано, если учесть, что клиентских приложений второго типа (см.
предыдущий пост) планировалось великое множество. Про выбор средств автоматизации написано достаточно много, есть тренинги. Чем я с удовольствием и воспользовался. Итак- на входе были следущие требования в инструменту: бесплатный или максимально дешевый (дело было в разгар кризиса, который наложил свой
отпечаток :( ), обладал возможностью проведения тестирования Win приложений, web приложений, нагрузочного тестирования. Напомню, что требовалось тестировать: связка клиент-сервис-БД и 2 типа приложений (в первом
можно создавать второй). Здесь куча всяческих ограничений, которые необходимо было учесть при выборе, которые при необходимости опишу позже. Также должна была быть возможность интеграции с VSS (и TFS в будущем), а также с Visual Studio 2008.Наверное не все вспомнил, но пусть так будет. В результате бесплатные инструменты как-то отпали по мере ознакомления, а из доступных платных остались TestComplete и
QTP. Триальные версии обоих были успешно установлены и сравнивал уже непосредственно "в деле". К слову, у обоих достаточно понятная документация, некоторые вещи даже на русском языке есть, помог форум на ресурсе
it4business.ru Это позволило достаточно быстро разобраться и пробовать применять инструменты в необходимых направлениях. По итогам выбран был TestComplete 6*.
Завершилась эта задача намного позже, чем остальные. Все помнят простую истину- нельзя автоматизировать
то, чего нет.
Итак- в результате решения этих задач имелось то, что нужно тестировщику для работы, а именно: сам софт (я собирал сборки у себя, тогда, когда мне это было нужно); документация к нему (вики+отдельные доки); багтрекер; источники информации (я знал что, где, когда, у кого спросить\посмотреть\найти); одновременно с этим я уже мог планировать процессы и выстравать ряд задач по внедрению этих процессов. Здесь же
необходимо отметить, что к этому времени я уже мог пойти к начальству и обсудить те или иные предложения, идеи, возможности того или иного софта и т.д. Не спросить, а именно обсудить, приводя доводы "за" и "против", высказывая свое мнение и выслушивая остальные точки зрения. Ведь задача стояла не получить максимально быстро рабочий процесс, а получить оптимальный рабочий процесс, полностью подходящий именно
для этой организации. Но и не забывая про то, что всему есть свои пределы, включая сроки. А в этом контексте появились совсем другие задачи, которые вышли на первый план, и которые нужно было решать одновременно с набором текущих задач, список которых постоянно пополнялся...
Поставил себе несколько целей на начальном этапе:
1. Побыстрее перезнакомиться со всеми разработчиками и
изменить их (существующее на тот момент) отношение к тестированию вообще и тестировщикам в частности. Благо некоторые из них все прекрасно понимали, некоторые получали команды сверху типа "оказывать всяческое содействие", ну а с некоторыми мы ходили пить пиво. Тут стоит упомянуть, что для этого необходимо было заранее заручиться 100% поддержкой сверху. Ибо если начальство не заинтересовано в
организации тестирования, если оно не видит в этом смысла или не может подсчитать ROI- ничего хорошего от внедрения процесса тестирования не получится.
2. Второй задачей было собрать максимум информации о разрабатываемом софте. Тут без начальства тоже не обошлось. Но и активное общение приносило свои плоды. В итоге информация появлялась, и можно было разбираться непосредственно с софтом, логикой его работы. Это был еще, конечно, далеко не спек, но намного лучше, чем ничего. Примерно на этом этапе попутно решили создавать базу знаний на вики, в которую и решено было поместить прототип спецификации. К слову, там же решено было создать и базу знаний отдела тестирования, но об этом позже.
3. Уделять достаточно времени на ручное тестирование отдельных модулей приложений. Здесь можно долго сокрушаться об отсутствии внутренних релизов, о внедрении которых напишу позже, но тем не менее разработка велась. Велась в бардаке... с элементами SCRUM. Поэтому периодически поступали задачи протестировать тот или иной функционал. И эти задачи должны были быть выполнены в независимости от остальных факторов. То есть бралась существующая документация по реализации задачи, брался ее разработчик, выяснялся "смысл жизни" (имею ввиду как оно должно работать и чего не должно делать) и проводилось тестирование. Тут сразу всплыл и пункт 4.
4. Необходимо было определиться с багтрекинговой системой, попутно воюя со всеми, кто желал получить в результате тестирования файлик с багами. В этом направлении повезло в том, что в организации использовалась самописная система постановки, учета, выполнения задач для сотрудников, которая вполне сгодилась на первое время. Сгодилась потому, что все необходимые атрибуты дефект репорта вполне в ней
нашлись и могли использоваться. Однако для объективной оценки возможностей и невозможностей этой самописной сисемы была попытка использовать Bugzilla для сравнения. То есть мы решили поднять у себя багзиллу и посмотреть на разницу между этими двумя системами. Про поднятие багзиллы можно очень долго рассказывать с использованием русских и английских идиоматических выражений в больших количествах. В принципе в инете есть описание сего процесса, есть решения сложностей, так что углубляться не стоит. В итоге на второй день поднял багзиллу и отдал на сравнение разному начальству. Тут имеет смысл сказать о том, что ни одна из этих двух систем не воспринималась как основная, на которой мы будем вести весь учет
дефектов и т.д. Все потому, что на гаризонте уже маячил TFS со всеми его хвалеными возможностями и реалиями. И все потом планировалось завязывать на него.
После сравнения мне сказали, что багзилла бедна функционально по сравнению со своей системой и мы ее юзать не будем. Сомнительно конечно, но... всегда сложнее переходить на что-то новое, чем использовать старое, проверенное, пусть даже и устаревшее. Идем дальше.
5. Так как задумывалось регрессионное тестирование проводить в автоматическом режиме, необходимо было подобрать оптимальный инструмент для этого дела. Сразу скажу, что решение об использовании автоматизации принималось без меня. Но оно вполне обосновано, если учесть, что клиентских приложений второго типа (см.
предыдущий пост) планировалось великое множество. Про выбор средств автоматизации написано достаточно много, есть тренинги. Чем я с удовольствием и воспользовался. Итак- на входе были следущие требования в инструменту: бесплатный или максимально дешевый (дело было в разгар кризиса, который наложил свой
отпечаток :( ), обладал возможностью проведения тестирования Win приложений, web приложений, нагрузочного тестирования. Напомню, что требовалось тестировать: связка клиент-сервис-БД и 2 типа приложений (в первом
можно создавать второй). Здесь куча всяческих ограничений, которые необходимо было учесть при выборе, которые при необходимости опишу позже. Также должна была быть возможность интеграции с VSS (и TFS в будущем), а также с Visual Studio 2008.Наверное не все вспомнил, но пусть так будет. В результате бесплатные инструменты как-то отпали по мере ознакомления, а из доступных платных остались TestComplete и
QTP. Триальные версии обоих были успешно установлены и сравнивал уже непосредственно "в деле". К слову, у обоих достаточно понятная документация, некоторые вещи даже на русском языке есть, помог форум на ресурсе
it4business.ru Это позволило достаточно быстро разобраться и пробовать применять инструменты в необходимых направлениях. По итогам выбран был TestComplete 6*.
Завершилась эта задача намного позже, чем остальные. Все помнят простую истину- нельзя автоматизировать
то, чего нет.
Итак- в результате решения этих задач имелось то, что нужно тестировщику для работы, а именно: сам софт (я собирал сборки у себя, тогда, когда мне это было нужно); документация к нему (вики+отдельные доки); багтрекер; источники информации (я знал что, где, когда, у кого спросить\посмотреть\найти); одновременно с этим я уже мог планировать процессы и выстравать ряд задач по внедрению этих процессов. Здесь же
необходимо отметить, что к этому времени я уже мог пойти к начальству и обсудить те или иные предложения, идеи, возможности того или иного софта и т.д. Не спросить, а именно обсудить, приводя доводы "за" и "против", высказывая свое мнение и выслушивая остальные точки зрения. Ведь задача стояла не получить максимально быстро рабочий процесс, а получить оптимальный рабочий процесс, полностью подходящий именно
для этой организации. Но и не забывая про то, что всему есть свои пределы, включая сроки. А в этом контексте появились совсем другие задачи, которые вышли на первый план, и которые нужно было решать одновременно с набором текущих задач, список которых постоянно пополнялся...
четверг, 17 сентября 2009 г.
Проект одного тестировщика
Жили-были в одной компании программисты. Были там и хорошие программисты, были и с небольшим опытом). Писали эти программисты хитрую и сложную софтину, которая представляла из себя клиент-сервис-БД связку. И вот однажды, когда объем стало невозможно не только тестировать самим (как могли), но и каждый программист стал понимать и помнить только ту часть, над которой он работал последнее время, руководство приняло решение- нужен тестировщик. Лучше- несколько. Но для начала один. Желательно чтобы не просто с опытом, а с опытом автоматизации тестирования дабы автоматизировать все и вся, и чтоб все само потом...
Тут нужно прокомментировать особенность софта: клиентская часть представляла из себя: 1) толстого клиента, основная цель которого- создание прикладного ПО; и 2) толстого и веб клиентов, которые и представляли из себя это прикладное ПО, причем в неограниченном количестве приложений. Сервис представлял из себя сервис, через который работала вся эта прорва клиентов с другой прорвой-базами данных (реляционными и не реляционными, актуальными и не очень, популярными и редкими). Клиентов решили сделать кроссплатформными (Win\Unix). А создание клиентов типа 2) доступным для непрограммистов (по крайней мере на высокоуровневых языках).
И вот на этапе, когда по всем направлениям ведется разработка, сделаны достаточно большие наработки. И даже написано немного документов, описывающих реализацию, пришел тестировщик...
Я решил рискнуть. Да и проект показался мне интересным. Плюс ко всему был дан картбланш (ограниченный, конечно). Тем ценнее казался в перспективе полученный опыт организации тестирования в компании, создании отдела, автоматизации с нуля и т.д.
Что из этого всего получилось- в серии следующих постов. В двух словах- процесс запущен, работает, приносит результаты.
PS: Вообще думал написать статью, но опасаюсь ее размера. А "многа букаф", как известно, многие могут не осилить :) По частям и комментировать удобнее и обсуждать.
Тут нужно прокомментировать особенность софта: клиентская часть представляла из себя: 1) толстого клиента, основная цель которого- создание прикладного ПО; и 2) толстого и веб клиентов, которые и представляли из себя это прикладное ПО, причем в неограниченном количестве приложений. Сервис представлял из себя сервис, через который работала вся эта прорва клиентов с другой прорвой-базами данных (реляционными и не реляционными, актуальными и не очень, популярными и редкими). Клиентов решили сделать кроссплатформными (Win\Unix). А создание клиентов типа 2) доступным для непрограммистов (по крайней мере на высокоуровневых языках).
И вот на этапе, когда по всем направлениям ведется разработка, сделаны достаточно большие наработки. И даже написано немного документов, описывающих реализацию, пришел тестировщик...
Я решил рискнуть. Да и проект показался мне интересным. Плюс ко всему был дан картбланш (ограниченный, конечно). Тем ценнее казался в перспективе полученный опыт организации тестирования в компании, создании отдела, автоматизации с нуля и т.д.
Что из этого всего получилось- в серии следующих постов. В двух словах- процесс запущен, работает, приносит результаты.
PS: Вообще думал написать статью, но опасаюсь ее размера. А "многа букаф", как известно, многие могут не осилить :) По частям и комментировать удобнее и обсуждать.
Время для первого сообщения
Вот кажется и нашлось оно... время. Время для ведения блога.
Как известно: "Найди время, а не оправдания." Я нашел.)
Решил поделиться мыслями о тестировании ПО, но не только об этом. А также разбавить примерами из реального опыта одного тестировщика.
Подписаться на:
Сообщения (Atom)
Сообщения
