Сообщений в теме: 8

[Tanya]

В компании принято решение внедрить автоматизированное тестирование. Проведен Research, выбран Tool.

Что дальше? Из опыта нескольких компаний знаю, что тестировщики сразу садятся что-то кодировать.

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

Хотелось получить какую-либо информацию на эту тему.

[Mike]

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

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

Затем надо прикинуть временные рамки, ресурсы, риски и составить примерный план (примерно на пол-года вперёд). В план надо заложить время на написание framework/выработку подхода к написанию тестов каждого типа (приёмочных, функциональных, и т.п.) - этот этап можно назвать "Разработка прототипа".

Когда готов прототип теста того или иного типа, надо сесть с тест-дизайнером и отобрать тест-кейсы на автоматизацию.

Ну, и можно приступать к кодированию тестов (не забыв составить план).

[Tanya]

Да, попробовали - небольшой тестовый пример, получилось, приняли решение - Да, внедряем.

И - начальство попросило подготовить ДЕТАЛЬНЫЙ ДОКУМЕНТ ПРОЦЕССА, описывающий, как мы будем автоматизировать.

Вот - мучаюсь. (не люблю писать подобного рода документы).
Когда что-то родится - выложу, может у кого будут комментарии.

(просто уверена, что эти вопросы уже многие для себя решили, и, возможно, есть статьи на эту тему).

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

[Mike]

Не понимаю, что значит "документ процесса". Описание методологии разработки тестов? Описание того, что будут делать ваши тесты? (принципы отбора тест-кейсов на автоматизацию, описание типов проверок)? Думаю, что методология - это чистая беллетристика, а не документ. См., например, соседнюю тему (мою статью по model-based автоматизации) - вполне сносный образчик жанра. Вряд-ли начальству нужен такой документ (хотя для Вас и ваших коллег пригодилось бы описать подход к разработке тестов). А вот подход к отбору тестов на автоматизацию - вешь чрезвычайно индивидуальная. Никаких "общих" документов тут быть не может - для каждого проекта нужна своя стратегия автоматизации. К тому-же, такие документы обычно конфеденциальны (так как содержат много конкретики о проекте) - вряд-ли кто поделится.

[I_G]

Рекоммендую почитать на stickyminds.com
Вот, например, есть даже документ, вполне может подойти для описания процесса: "Test Automation Guidelines" www.stickyminds.com/s.asp?F=S8254_ART_2

[Boltick]

Не понимаю, что значит "документ процесса". Описание методологии разработки тестов? Описание того, что будут делать ваши тесты? (принципы отбора тест-кейсов на автоматизацию, описание типов проверок)? Думаю, что методология - это чистая беллетристика, а не документ. См., например, соседнюю тему (мою статью по model-based автоматизации) - вполне сносный  образчик жанра. Вряд-ли начальству нужен такой документ (хотя для Вас и ваших коллег пригодилось бы описать подход к разработке тестов). А вот подход к отбору тестов на автоматизацию - вешь чрезвычайно индивидуальная. Никаких "общих" документов тут быть не может - для каждого проекта нужна своя стратегия автоматизации. К тому-же, такие документы обычно конфеденциальны (так как содержат много конкретики о проекте) - вряд-ли кто поделится.

Я проснулся через 4 года и решил ответить :) Извните, что с таким опазданием... Но...

По моему "документ процесса" -- это обычный стандарт написания автоматизированных тестов (архитектура, обозначения и т.д.). Пишется он для улучшения улучшения сопровождаемости. Очень полезная вещь.

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

Спасибо
Алексей

[Luceus]

Официально в команде ТА (автоматизированное тестирование) я недавно. Оказалось, что на каждом проекте имеется свой набор библиотек и каждый программист пишет как ему вздумается. Пришли к выводу, что необходимо на данном этапе выработать подобный документ, в котором бы описывались следующие моменты:
1. Разработка и поддержка единой библиотеки (разбиение набора функций и процедур на несколько категорий)
2. Разработка документации по библиотеки функций
3. Разработка правил по оформлению кода, комментариев
4. Выработка основных принципов по разработке функций и процедур
5. Разработка и описание единого подхода в автоматизации тест кейсов
6. и др.

Что бы я посоветовал. Конечно, этот документ должен быть разработан и у вас. Основные моменты, которые мы описали у себя, я привел выше.

Успехов.

[Galina]

Официально в команде ТА (автоматизированное тестирование) я недавно. Оказалось, что на каждом проекте имеется свой набор библиотек и каждый программист пишет как ему вздумается. Пришли к выводу, что необходимо на данном этапе выработать подобный документ, в котором бы описывались следующие моменты:
1. Разработка и поддержка единой библиотеки (разбиение набора функций и процедур на несколько категорий)
2. Разработка документации по библиотеки функций
3. Разработка правил по оформлению кода, комментариев
4. Выработка основных принципов по разработке функций и процедур
5. Разработка и описание единого подхода в автоматизации тест кейсов
6. и др.

Что бы я посоветовал. Конечно, этот документ должен быть разработан и у вас. Основные моменты, которые мы описали у себя, я привел выше.

Успехов.

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

[KaNoN]

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

Это скорее некий сопутствующий документ (но от этого не менее важный). Такой документ, как правило, привязан только к конкретно выбранному тулу. Если брать процессы, то непосредственно в автоматизации можно выделить такие стадии:

1) Разработка фреймворка - подразумевается некоторая база, сам фреймворк дорабатывается уже на более поздних стадиях, но начинает разрабатываться именно здесь. На данной стадии надо определить принцип организации фреймворка (фактически его тип), описать компоненты и типы компонентов фреймворка, а также критерии, по которым тот или иной компонент относится к тому или иному типу. Опять же, это зависит от возможностей выбранного тула. Если есть поддержка классов, то нужно выделить критерии, по которым некоторую функциональность выделить в классы, или просто описать архитектуру системы. В-общем, это некоторая система правил формирования компонентов фреймворка. На данной стадии немаловажным моментом является структура файлов. То есть нужно определить, по какому принципу будет производиться разбиение на файлы. Также на данно стадии определяется и формат самих файлов. Как раз на этой стадии формируются кодинг-стандарты - документ, о котором говорилось выше. Также здесь определяются роли участников команды
2) Разработка тесткейсов - подразумевается непосредственная реализация автоматизированных тесткейсов. По данному пункту надо определить, как будут устроены скрипты, какие требования к ним предъявлять, а также процедура распределения тесткейсов для автоматизации между участниками команды (проще говоря, как каждый из автоматизаторов будет решать, какой тесткейс ему автоматизировать). Это один из ключевых моментов, поскольку он декламирует процесс взаимодействия автоматизаторов на данном (ключевом) этапе. Также здесь можно указать условия, при которых написанный тесткейс можно передавать на следующую стадию
3) Ревью кода - здесь описываются критерии оценки качества кода, а также процесс распределения тесткейсов на ревью (то есть определяется, кто должен проводить ревью и как к нему эти тесткейсы попадают) и порядок действий (то есть, что делать, если какие-то условия не удовлетворены, если все в порядке). Ну и непосредственно здесь надо определить, каким критериям должен удовлетворять автоматизированный тесткейс, чтобы он считался окончательно завершенным и готовым к использованию
4) Пробное тестирование - этап, заключающийся в первых испытаниях написанных тесткейсов. Здесь надо указать правила распределения тесткейсов между участниками команды автоматизаторов, описать критерии корректно пройденного тесткейса, а также выработать процедуру обработки ошибок (в каком порядке проверять, в случае возникновения ошибки)

Вот примерно набросок, что должно содержаться в документе, описывающем процесс автоматизации