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

[Alice]

Здравствуйте!
Столкнулась с проблемой разделения общего плана тестирования на два : для ручного и автоматизированного тестирования. Насколько детально нужно автоматизировать процесс, а что оставить для ручного тестирования? Нигде не удалось найти четкую инфу на эту тему.
Подозреваю, что просто вопрос опыта, не могли бы что-нибудь посоветовать?

[KaNoN]

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

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

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

[Alice]

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

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

т.е. я правильно поняла, что нужно, по возможности, автоматизировать все, что получится?

[KaNoN]

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

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

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

т.е. я правильно поняла, что нужно, по возможности, автоматизировать все, что получится?

100% - это идеальный вариант, к которому надо стремиться. Ручную работу нужно свести к минимуму.

[Alice]

Общий принцип понятен. Спасибо! ;-)))

[100% - это идеальный вариант, к которому надо стремиться. Ручную работу нужно свести к минимуму.

суть ясен ход к чему стремиться, будем стараться ;-).

[Yury]

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

Я бы перевёл это высказывание следующим образом: "В условиях организации, в которой работает KaNoN, для тех проектов, с которыми он работает, он считает что 80-90% функционала - достаточно неплохое решение (кстати, он ничего не говорит о реальной степени автоматизации).

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

Yury

[Alice]

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

Я бы перевёл это высказывание следующим образом: "В условиях организации, в которой работает KaNoN, для тех проектов, с которыми он работает, он считает что 80-90% функционала - достаточно неплохое решение (кстати, он ничего не говорит о реальной степени автоматизации).

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

Yury

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

[KaNoN]

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

Я бы перевёл это высказывание следующим образом: "В условиях организации, в которой работает KaNoN, для тех проектов, с которыми он работает, он считает что 80-90% функционала - достаточно неплохое решение (кстати, он ничего не говорит о реальной степени автоматизации).

Если на то пошло, то я работаю в аутсорсинговой компании, соответственно проектов достаточно много и они разнообразны, но факт, что функционал автоматизируется на 80-90% - это зачастую норма, хотя в некоторых случаях просто времени и ресурсов не хватает даже на подобный показатель. И если говорить о функциональном тестировании, то покрытие - это основной показатель. Что по вашему мнению реальный объем автоматизации?

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

Большинство приложений по многим параметрам и используемым подходам схожи. Соответственно то, что я указал, во многом подходит для большого круга приложений. А перебор или недобор с автоматизацией - это больше по финансовой части и это решают совсем другие люди

[KaNoN]

По моим подсчетам, автоматизация, покрывающая 80-90% функционала - достаточно неплохое решение.

Я бы перевёл это высказывание следующим образом: "В условиях организации, в которой работает KaNoN, для тех проектов, с которыми он работает, он считает что 80-90% функционала - достаточно неплохое решение (кстати, он ничего не говорит о реальной степени автоматизации).

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

Yury

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

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

[Yury]

Если на то пошло, то я работаю в аутсорсинговой компании, соответственно проектов достаточно много и они разнообразны, но факт, что функционал автоматизируется на 80-90% - это зачастую норма ...

Не могли бы Вы, всё-таки, привести процент автоматизированных тест кейсов для пары ваших последних проектов?

... хотя в некоторых случаях просто времени и ресурсов не хватает ...

А то может сложиться представление, что Вы проповедуете один подход, а сами используете совсем другой.

Юрий

[KaNoN]

Если на то пошло, то я работаю в аутсорсинговой компании, соответственно проектов достаточно много и они разнообразны, но факт, что функционал автоматизируется на 80-90% - это зачастую норма ...

Не могли бы Вы, всё-таки, привести процент автоматизированных тест кейсов для пары ваших последних проектов?

От 75% за последние 4 проекта. И то 75% - было только в одном из проектов, где заказчики сами попросили не автоматизировать определенную часть приложения, достаточно существенную.

... хотя в некоторых случаях просто времени и ресурсов не хватает ...

А то может сложиться представление, что Вы проповедуете один подход, а сами используете совсем другой.

Те цифры, что я называл, это данные, на которые я обычно ориентируюсь. 100% покрытия достичь трудно, ведь практически всегда найдется какая-нибудь сложная графика или вывод на печать и т.п. Другое дело, что при планировании автоматизации я исхожу из того расчета, что нужное количество людей у нас найдется. В нашей компании это выполнимо, а вот в других компаниях как - этого я сказать не могу. "Автотестер" - это не такой уж распространенный "зверь" в наших широтах. Тем не менее, планировать активность нужно по максимальной планке, раз решение для автоматизации уже принято.

[Darkus]

У меня вопрос был по банковским системам документооборота.

Я считаю, что к банковским системам документооборота, относиться нужно весьма отвественно.
Если один и тот же тест может сделать человек или машина, то в данном случае лучше оставновиться на последнем решении.
Ввиду того, что если мы можем понизить риск "человеческого фактора" (например, невнимательность при вводе данных, анализ полученных результатов), то предположительно, разработка автоматических тестов себя оправдает (легче один -два раза сделать ревью кода этих тестов и потом гонять их до нужной стабильности программы ).
Лично я бы сделал так - разработал тестовый дизайн с привлечением банковских специалистов (учесть типовые прохождения документов, контроль полученных данных после выполнения обработок и т.п.). Затем разбил полученные тест кейсы на автоматизированный и ручные тесты.
В автоматизированные вынес те, где нужно вводить много данных, выполнять длительные цепочки операций, где получается много результатов, которые нужно проанализировать.
Обязательно внёс туда же типовые случаи, которые должны давать ошибку (в спешке при ручном тестировании чаще проверяют те случаи, когда не должно быть ошибок).
После написания кода тестов, провёл ревью этого кода(можно даже программистов привлечь).
А на ручное тестирование оставил бы те части, которые не требуют внимательного ввода данных и которые действительно сложно автоматизировать. И рекомендовал бы эти тесты проводить время от времени сменяя людей, чтобы "глаз не натирался".
Повторюсь, что банковская система - это особый случай...

[Galina]

По моему скромному мнению, 100%-я автоматизация тестирования не должна превращаться в самоцель. Главная задача тестирования – находить дефекты. А если более конкретно – добиться определенного уровня качества программы до момента сдачи заказчику.
А вот как добиться этого самого качества? Зависит от проекта, от ресурсов (от их скилс), от временных рамок и т.п.

Начинать автоматизацию стоит с наиболее часто повторяющихся тестов и самой «постоянной» части функционала (не меняющейся во времени) – это аксиома. Часто это бывают smoke tests, которые прогоняют для каждой сборки.
Если автоматизируется функциональное тестирование, то тестов, написанных для ручного тестирования, обычно хватает для написания автотеста (зависит, конечно же, от качества тест дизайна).

[Alice]

Все-таки думаю, насколько подробно нужно проводить тест. При вводе данных - ставить проверку на некорректные данные, на максимальные и т.п.? можно ли сделать не тяжеловесную цепочку, чтобы она охватила все или проверять цепочку с основными данными, а работу с данными оставить для ручного тестирования?
Мне кажется, что если это прописывать автоматически, то при ручном тестировании этому могут и не уделять внимание, а это довольно важный момент.

[ShortLegged]

Все-таки думаю, насколько подробно нужно проводить тест. При вводе данных - ставить проверку на некорректные данные, на максимальные и т.п.? можно ли сделать не тяжеловесную цепочку, чтобы она охватила все или проверять цепочку с основными данными, а работу с данными оставить для ручного тестирования?
Мне кажется, что если это прописывать автоматически, то при ручном тестировании этому могут и не уделять внимание, а это довольно важный момент.

Вы можете разнести проверку основного flow и проверку ошибок по разным тест кейсам. После этого, принять решение о необходимости автоматизации каждого тест кейса. Как мне кажется у Вас проблемы из-за того, что Вы пытаетесь свалить в одну кучу тест дизайн и автоматизацию.

[Darkus]

Хорошо, давайте попробуем посмотреть на эту проблему с другой точки зрения.
Вот вы сделали тест дизайн, в котором куча большая тестовых случаев.

Сколько раз вы будете прогонять ваши тесты? <1-2> раза и потом они никому не нужны будут? Тогда автоматизация сразу под вопрос большой попадает.
Это раз.

Распишите по каждому конкретному тест-кейсу - сколько времени вам нужно, чтобы прогнать его вручную. Далее решите, что считать приемлимым временем выполнения теста вручную = t1.

Например, выведите среднее время прохождения вашего тест -кейса (сумма времени прохождения всех тестов на их количество).

Выделите все тесты у которых время выполнения вручную > t1.

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

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

Теперь посмотрите на те тесты, время которых <t1. Есть ли среди них те, которые безусловно критичные. Какие из них можно было бы быстро закодировать. Вот ещё получился объём тест кейсов, которые можно автоматизировать - критичные и легко подвергающиеся автоматизации.
Это три.


Можете по-своему поиграть с этими метриками: время на автоматизацию, время ручного прогона, критичность ошибки. Дополните их своими - например - обязательные тесты, которые попросил клиент.


Всё вышенаписанное считать сугубо личной рекомендацией, а не правилом :)

[Alice]

Всё вышенаписанное считать сугубо личной рекомендацией, а не правилом :)

Спасибо! Как раз это и интересовало :)))

[Alice]

Все-таки думаю, насколько подробно нужно проводить тест. При вводе данных - ставить проверку на некорректные данные, на максимальные и т.п.? можно ли сделать не тяжеловесную цепочку, чтобы она охватила все или проверять цепочку с основными данными, а работу с данными оставить для ручного тестирования?
Мне кажется, что если это прописывать автоматически, то при ручном тестировании этому могут и не уделять внимание, а это довольно важный момент.

Вы можете разнести проверку основного flow и проверку ошибок по разным тест кейсам. После этого, принять решение о необходимости автоматизации каждого тест кейса. Как мне кажется у Вас проблемы из-за того, что Вы пытаетесь свалить в одну кучу тест дизайн и автоматизацию.

В общем-то вопрос в основном по тест дизайну. Общие принципы для автоматизированного тестирования. Чем отличие от ручного.

[ShortLegged]

В общем-то вопрос в основном по тест дизайну. Общие принципы для автоматизированного тестирования. Чем отличие от ручного.

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

Если непонятно, будут ли тест кейсы автоматизированы, возможно имеет смысл подготовить некоторый промежуточный вариант, в любом случае, его можно будет в дальнейшем доработать.