Перейти к содержимому

Фотография

Похвалите/поругайте подход к организации тестирования на проекте.


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 16

#1 EugeneL

EugeneL

    Активный участник

  • Members
  • PipPip
  • 101 сообщений

Отправлено 13 ноября 2017 - 09:08

Добрый день, уважаемые коллеги.

 

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

 

1. Разработка осуществляется по итерациям. Т.к. процесс разработки идет активно, я планирую включать в scope
а) задачи текущей итерации;

б) задачи улучшения средств тестирования;

в) неохваченные (в плане тестирования) задачи из прошедших итераций.

 

2. Процесс примерно я представляю так:

а) выяснение требований в рамках конкретной User Story;

б) ручное тестирование User Story с документированием; на выходе этого шага я хочу получить тест-кейс и проверенную User Story;

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

 

3. Предоставление информации о тестировании.

Я планирую предоставлять матрицу прослеживаемости (Traceability Matrix) и отчет о тестировании (Test Results Report).

Еще, планирую составить план тестирования и план проекта по автоматизации тестирования (или этот второй -- лишний?).

 

4. Состав команды.

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

 

В качестве инструментов я планирую использовать:

1. Тест-кейсы держать в Google Docs;

2. Баг-трекер: Jira. Плагинов нет, но, быть может, что-то добудем.

3. В качестве инструментов автоматизации, использовать Java+Cucumber+(Webdriver/RestAssured). Почему именно Cucumber? Для него есть плагин, который позволяет получить матрицу прослеживаемости и список выполненных тестовых сценариев.

 

В заключение, хотел бы спросить Вашего совета:

1. Как Вы считаете, достаточно ли будет Traceability Matrix и Test Result Report (составленный по методологии ISTQB)?

2. Подскажите, есть ли средства, которые позволяли бы хранить информацию о тестовых сценариях выполненных/проваленных сценариях, связях тестовых сценариев с дефектами?

3. Есть ли средства, которые могут облегчить составление отчетности?

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

5. Подскажите, какие метрики лучше использовать для определения прогресса тестирования? Я бы хотел использовать покрытие функционала, но в этом случае трудно определить итоговый объем работ, т.к. это - набор User Story из Jira.

 

Заранее большое спасибо.


  • 0

#2 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 13 ноября 2017 - 10:02

 

 

3. В качестве инструментов автоматизации, использовать Java+Cucumber+(Webdriver/RestAssured). Почему именно Cucumber? Для него есть плагин, который позволяет получить матрицу прослеживаемости и список выполненных тестовых сценариев.

Кукумбер использовать если будут только приёмочные тесты, и ничего более сложного. Нормальное тестирование надо выполнять без него, просто Java+TestNG+RestAssured+WebDriver


  • 0

#3 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 13 ноября 2017 - 11:32

А цель то всей этой движухи какая?

 

Семенченко на комяке рассуждает о стратегиях тестирования.


  • 0

#4 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 13 ноября 2017 - 11:40

 

 

 

3. В качестве инструментов автоматизации, использовать Java+Cucumber+(Webdriver/RestAssured). Почему именно Cucumber? Для него есть плагин, который позволяет получить матрицу прослеживаемости и список выполненных тестовых сценариев.

Кукумбер использовать если будут только приёмочные тесты, и ничего более сложного. Нормальное тестирование надо выполнять без него, просто Java+TestNG+RestAssured+WebDriver

 

«Если примешь за постулат существование “нормального тестирования”, следовательно, все остальное тестирование будет называться ненормальным…»  А. Лупан

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


  • 0

#5 Spock

Spock

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 772 сообщений
  • ФИО:Роман

Отправлено 13 ноября 2017 - 12:28

 

«Если примешь за постулат существование “нормального тестирования”, следовательно, все остальное тестирование будет называться ненормальным…»  А. Лупан

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

ну если сильно не докапываться, то под "нормальным тестированием" наверное я имею ввиду что-то типа "регрессионного"


  • 0

#6 EugeneL

EugeneL

    Активный участник

  • Members
  • PipPip
  • 101 сообщений

Отправлено 13 ноября 2017 - 14:00

А цель то всей этой движухи какая?

 

Целей несколько:

 

1. Уменьшить количество дефектов, приходяхщих с Production Environment.

Понимаю, что с автоматизированным тестированием цель слабо корреллирует, но это -- идея Solution Architecht'a, и так или иначе тестовые скрипты писать надо будет. С другой стороны, я до этого по канбану (о смысловом дрифте понятия "канбан" я в курсе, прошу не придираться) работал, и справлялся. Риски примерно осознаю.

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

 

2. До настоящего момента тестированием занимались либо программисты, либо сейлсы либо менеджеры по работе с клиентом. Отдел тестирования также решили создать, чтобы тестированием продукта занимались тестировщики, а не первый попавшийся человек из команды. Сейчас разработчиков - примерно 10 человек, тестирвщиков планируют нанять еще 3-ех. Т.е. удастся избежать ситуации, когда команда тестирования становится "узким местом".

 

3. Инициатива с тестированием исходит от Solution Architecht'a, поэтому нужно будет убедить бизнес, что команда тестирования нужна. Убеждать планирую с помощью отчетности (например, показать, что количество дефектов с продуктива уменьшилась, или, например, карту покрытия функционала тестами) и путем выполнения п. №1.

 

P.S. спасибо за ссылку на презентацию, чуток позже гляну.


  • 0

#7 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 13 ноября 2017 - 14:20

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

1. надо ли вам тест-кейсы вообще?
2. файлы для обработки приходят от клиентов?
Предположу, что узкое место - подготовка тестовых данных.
  • 1

#8 EugeneL

EugeneL

    Активный участник

  • Members
  • PipPip
  • 101 сообщений

Отправлено 13 ноября 2017 - 16:02

 

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

1. надо ли вам тест-кейсы вообще?
2. файлы для обработки приходят от клиентов?
Предположу, что узкое место - подготовка тестовых данных.

 

1. В классическом виде, я не думаю. Т.к. кейсы будут отличаться только параметрами файлов с документами. В перспективе хотел использовать чек-лист use-case-ов, и нотацию Геркина как living documentation.

2. Да. Модель очень похожа на 1С-франчайзи: есть базовая версия, которая была внедрена клиентам фирмы. Но пара клиентов захотели внести изменения в базовую версию. Наша команда работает над версиями, которые модифицируются под крупных клентов.

 

Кстати, сейчас подготовка тестовых данных достаточно трудоемка. Есть несколько идей, как это оптимизировать. Пока, самые легкие решения:

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

- добавить timestamp c миллисекундами в поле-ключ тестовых данных (это труднее, т.к. придется работать с файлами из тестовых скриптов, и дольше).

Пока я склоняюсь к первому варианту.

 

В воздухе витает идея перейти на микросервисную архитектуру, тогда можно было бы ограничиться SOAP/REST запросами в Soap UI/Java + Rest Assured, но эта миграция находится на уровне концепции: даже PoC нет.


  • 0

#9 Little_CJIOH

Little_CJIOH

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 515 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 13 ноября 2017 - 16:43

Вообще из п.1 и п.2 у вас вытекают метрики.
К сожалению врят-ли кто документировал кто и сколько времени тратил на тестирование.

И хорошо если из баг-трекера удастся поднять статистику багов  при тестировании/на проде.


  • 1

#10 tjupka

tjupka

    Активный участник

  • Members
  • PipPip
  • 81 сообщений

Отправлено 20 ноября 2017 - 12:46

 

А цель то всей этой движухи какая?

 

Целей несколько:

 

1. Уменьшить количество дефектов, приходяхщих с Production Environment.

Понимаю, что с автоматизированным тестированием цель слабо корреллирует, но это -- идея Solution Architecht'a, и так или иначе тестовые скрипты писать надо будет. С другой стороны, я до этого по канбану (о смысловом дрифте понятия "канбан" я в курсе, прошу не придираться) работал, и справлялся. Риски примерно осознаю.

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

 

2. До настоящего момента тестированием занимались либо программисты, либо сейлсы либо менеджеры по работе с клиентом. Отдел тестирования также решили создать, чтобы тестированием продукта занимались тестировщики, а не первый попавшийся человек из команды. Сейчас разработчиков - примерно 10 человек, тестирвщиков планируют нанять еще 3-ех. Т.е. удастся избежать ситуации, когда команда тестирования становится "узким местом".

 

3. Инициатива с тестированием исходит от Solution Architecht'a, поэтому нужно будет убедить бизнес, что команда тестирования нужна. Убеждать планирую с помощью отчетности (например, показать, что количество дефектов с продуктива уменьшилась, или, например, карту покрытия функционала тестами) и путем выполнения п. №1.

 

P.S. спасибо за ссылку на презентацию, чуток позже гляну.

 

 

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

В зависимости от ИХ целей можно определять пропорцию разработчиков на тестировщика.

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

Кстати, к написанию авто-тестов удобно привлекать самих же разработчиков.

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


  • 0

https://tjupka.blogspot.ru - из опыта тестировщика


#11 Vasiliy

Vasiliy

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 959 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 20 ноября 2017 - 14:08

А зачем маркетингу тестирование вообще?
Мы, наверняка, с их точки зрения вообще лишние)
  • 2

#12 EugeneL

EugeneL

    Активный участник

  • Members
  • PipPip
  • 101 сообщений

Отправлено 21 ноября 2017 - 09:06

 

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

1. надо ли вам тест-кейсы вообще?
2. файлы для обработки приходят от клиентов?
Предположу, что узкое место - подготовка тестовых данных.

 

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

 

 

 

  • 0

#13 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 21 ноября 2017 - 09:11

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

Да, для таких случаев таблицы/чек-листы подходят лучше.
  • 1

#14 EugeneL

EugeneL

    Активный участник

  • Members
  • PipPip
  • 101 сообщений

Отправлено 21 ноября 2017 - 09:13

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

 

А зачем маркетингу тестирование вообще?
Мы, наверняка, с их точки зрения вообще лишние)

 

Удалось прояснить причины введения отдела тестирования:

1. Много багов на проде (18% от общего числа), клиенты начинают уходить.

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

 

Коллеги, подскажите, пожалуйста, в чем лучше всего рисовать Project Roadmap? Слышал, что MS Project и Gannter - удобные средства, но они, к сожалению, недоступны.


Сообщение отредактировал EugeneL: 21 ноября 2017 - 09:21

  • 0

#15 Freiman

Freiman

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 1 591 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 21 ноября 2017 - 09:21

1. Много багов на проде (18% от общего числа), клиенты начинают уходить.

Как считаются эти проценты? Насколько критичны эти баги для клиентов?

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

Вообще отделу маркетинга стоит напрячься. Если багов будет мало, а клиенты продолжат уходить.. :)

Коллеги, подскажите, пожалуйста, в чем лучше всего рисовать? Слышал, что MS Project и Gannter - удобные средства, но они, к сожалению, недоступны.

Что именно рисовать?
  • 0

#16 EugeneL

EugeneL

    Активный участник

  • Members
  • PipPip
  • 101 сообщений

Отправлено 21 ноября 2017 - 09:53

 

1. Много багов на проде (18% от общего числа), клиенты начинают уходить.

Как считаются эти проценты? Насколько критичны эти баги для клиентов?

 

Я посчитал. В багтрекере есть поле "Внешний/Внутренний". По приоритетам не смотрел, но гляну обязательно -- это хорошая идея.

 


Коллеги, подскажите, пожалуйста, в чем лучше всего рисовать? Слышал, что MS Project и Gannter - удобные средства, но они, к сожалению, недоступны.

Что именно рисовать?

 

Извините, смысл моего вопроса потерялся после нескольких правок.

От меня просят нарисовать что-то вроде Project Roadmap. C вехами/milestones, их содержанием и зависимостями, я уже определился. Теперь надо визуализировать, чтобы вышестоящему начальству показать.


  • 0

#17 SALar

SALar

    Профессионал

  • Members
  • PipPipPipPipPipPip
  • 2 298 сообщений
  • Город:Москва


Отправлено 21 ноября 2017 - 11:55

Извините, смысл моего вопроса потерялся после нескольких правок.

От меня просят нарисовать что-то вроде Project Roadmap. C вехами/milestones, их содержанием и зависимостями, я уже определился. Теперь надо визуализировать, чтобы вышестоящему начальству показать.

 

Для меня, но это именно для меня идеальным оказалась FlyingLogic. Летом я по ней тренинг проводил. А совсем недавно мы составили в ней план развития отдела.

 

PS. До плана преобразований (roadmap) рисуют дерево текущей реальности. Потому как иначе вы понадопускаете кучу ошибок.

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

 

1.б Не средств, Карл, не средств! Процессов. Ибо средства самая малозначащая часть процесса. А наиболее значимые - навыки персонала.

 

 

Jira - для 10 человек избыточна, а для одиннадцати стоит $2000. Что беспредел. На начальном этапе можно попробовать мантис или багзиллу. Только не надо их настраивать!

Я бы рекомендовал вам TrackStudio, но сами вы ее не настроите. Вот там можно очень неплохо сделать матрицы прослеживаемости. Хотя смотреть ее (матрицу) никто не будет. Да и отчет никто не смотрит. 


  • 0

-- 

Сергей Мартыненко

Блог 255 ступеней (байки для оруженосца)

facebook (Дети диаграммы Ганта)

ВебПосиделки клуба имени Френсиса Бэкона 

 



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных