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

Фотография

У нас проблема с автотестами? Что делать?


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

#1 SALar

SALar

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

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


Отправлено 13 сентября 2019 - 06:14

Небольшой чек лист, который нужно выполнить ДО внедрения процесса автоматизированного тестирования:

 

  • В компании отрисован основной бизнес процесс доставки и есть понимание где вы конкретно находитесь

  • В компании отрисован процесс доставки ценности заказчику или нескольким заказчика не принципиально. 

  • Поставлено управление задачами, это означает что все причастные переводят задачи в нужный статус. И задачи типизированы

  • В компании сформулированы цели тестирования.

  • Заголовки задач в трекере “причесаны”, иными словами, по заголовку можно понять что это за задача, да не умная девочка служанка должна понимать такой заголовок. Почитать тут.

  • Реестр задач управляем, в любой момент времени он отражает текущий статус и политику проекта/продукта

  • Реестр требований есть и он то же управляем

  • Существует трассируемость требований на задачи. 

  • Существует трассируемость требований на тесты. Да, мы знаем что и как покрыли. 

  • Существует трассируемость тестов на задачи, да мы знаем что протестировано, где и как.

  • Существуют матрица влияния компонент друг на друга

  • Задачи трассируются на компоненты, да мы всегда знаем почему мы пишем или удаляем код

  • Все стоит на версионном контроле.

  • Хорошо, вы особый случай, да текстуру весом 25 гб не надо класть в систему контроля версий. Кстати а сколько раз вы их уже того…. ?

  • Существует версионная политика, кто, как и зачем.
    Да есть понимание почему git flow плохая модель.

  • Существую стандраты: кодирования и прочего

  • У вас есть CI

  • Да! У вас конечно должна быть релизная политика, где в частности прописаны способы версионирования, всего чего надо.

  • У вас есть репозиторий для артефактов, откуда вы можете однозначно вынуть готовый к установке продукт. Рука сама стала писать yum…

  • У вас есть политика по маркировке артефактов. По разным критериям, статический анализ кода, кстати не забыт

  • Среда для развертки продукта поднимается по щелчку пальца. Да она то же на версионном контроле. Все как код!

  • Среда полностью автоматизировано проверяются на правильность. Да порты, да версия джавы, да этот ….

  • Продукт разворачивается по щелчку. Разумеется  с проверкой :) Поставить все могут а вот, что бы работало!

  • Продукт конфигурируется полностью автоматически под необходимую задачу. Кстати это относится и бизнес конфигурации! И это тоже проверятся в автоматически! Кто сказал про стык с платежными системами????

  •  У вас есть способ повторяемо и автоматически генерить все необходимые тестовые данные. Да это то же на версионном контроле. Да оно связано с артефактами продукта.

  • Я упомянул, что все выше указанное работает для любой версии продукта?

  • У вас прописан конвейер поставки, он обычно внутри релизной политики, но я вытащил наружу.

 

Поздравляем!

Вы готовы к написанию автотестов!

 

Еще нет. 

  • Интерфейсы, будь то GUI или API проектируются ДО того, как программист сядет писать код. Да, в соответствии со стандартом проектирования интерфейсов. Да, там прописана политика именования идентификаторов элементов управления ( для GUI).

  • Задачу на написание тестов тестировщик получает, как правило, раньше, чем программист получит задачу на написание кода.

И не надо начинать автоматизацию тестирования, с написания регрессионных тестов. Вот совсем не надо.

 

И т.д. и т.п.: https://docs.google....pwTLh73_M/edit#
 


  • 0

-- 

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

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

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

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

 


#2 Vasiliy

Vasiliy

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

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

Отправлено 13 сентября 2019 - 06:19

Сергей, а можно оффтопиком объяснить почему не надо начинать с регрессии?

Отдельной статьёй или топиком.

Я у тебя это уже давно встречаю, но не очень понимал всегда.


  • 0

#3 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 08:25

 

 

  • Существует трассируемость требований на тесты. Да, мы знаем что и как покрыли. 

  • Существует трассируемость тестов на задачи, да мы знаем что протестировано, где и как.

а вот это не оверкилл будет?

 

если тесты добавлены, прокодревьюены, то пусть и лежат/бегают себе?


  • 0

#4 SALar

SALar

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

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


Отправлено 13 сентября 2019 - 10:05

Сергей, а можно оффтопиком объяснить почему не надо начинать с регрессии?

Отдельной статьёй или топиком.

Я у тебя это уже давно встречаю, но не очень понимал всегда.

Василий, ты очень хороший специалист. Попробуй пройти путь сам.

 

Подсказки:

1) делаешь декомпозицию процессов рабочего центра тестирования. Не бери книгу Рекса Блэка. Там декомпозиция ... очень неполная. Можешь на посиделках эту тему поднять. За полтора часа сделаем лучше, чем у Блэка.

2) Выделяешь ключевой / главный процесс. Он там один. Оттуда выводишь цель тестирования. "Цель-1" в помощь. И Канер. 

3) определяешь метрики ключевого процесса тестирования. Не в одной, известной мне, книге нет, есть только на моих тренингах. "Цель-1" в помощь

 

И как бы все. Далее просто смотришь факты. Статистику. И все сразу станет ясно.


  • 0

-- 

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

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

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

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

 


#5 SALar

SALar

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

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


Отправлено 13 сентября 2019 - 10:08

 

 

 

  • Существует трассируемость требований на тесты. Да, мы знаем что и как покрыли. 

  • Существует трассируемость тестов на задачи, да мы знаем что протестировано, где и как.

а вот это не оверкилл будет?

 

если тесты добавлены, прокодревьюены, то пусть и лежат/бегают себе?

 

Как говорил величайший менеджер двадцатого столетия: «Меняться совершенно не обязательноВыживание - дело добровольное

Если вам платят за растрату денег фирмы, я ничего не могу с этим сделать.


  • 0

-- 

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

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

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

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

 


#6 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 11:00

 

Как говорил величайший менеджер двадцатого столетия: «Меняться совершенно не обязательноВыживание - дело добровольное

Если вам платыт за растрату денег фирмы, я ничего не могу с этим сделать.

а поподробнее можно? 

 

так ведь может эти две трассировки и есть та самая "растрата денег фирмы"?

 

хотя если та трассировка достигается простым "blame" из гита, то она уже как-бы и есть, бесплатно


  • 0

#7 SALar

SALar

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

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


Отправлено 13 сентября 2019 - 11:37

 

 

Как говорил величайший менеджер двадцатого столетия: «Меняться совершенно не обязательноВыживание - дело добровольное

Если вам платыт за растрату денег фирмы, я ничего не могу с этим сделать.

а поподробнее можно? 

 

так ведь может эти две трассировки и есть та самая "растрата денег фирмы"?

 

хотя если та трассировка достигается простым "blame" из гита, то она уже как-бы и есть, бесплатно

 

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


  • 0

-- 

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

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

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

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

 


#8 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 12:05

 

 

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

прям загадками говорите, ну точнее труизмами

 

вообще на любой вопрос можно ответить труизмом


  • 0

#9 Little_CJIOH

Little_CJIOH

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

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


Отправлено 13 сентября 2019 - 12:48

 

 

Как говорил величайший менеджер двадцатого столетия: «Меняться совершенно не обязательноВыживание - дело добровольное

Если вам платыт за растрату денег фирмы, я ничего не могу с этим сделать.

а поподробнее можно? 

 

так ведь может эти две трассировки и есть та самая "растрата денег фирмы"?

 

хотя если та трассировка достигается простым "blame" из гита, то она уже как-бы и есть, бесплатно

 

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


  • 0

#10 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 16:07

 

 

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

у кого-то есть эпики в джире, на эпиках тикеты, на тикетах ченджи с тестами - а у кого-то полная система трассировки и вообще управления требованиями до самих тестов

 

можно ли сказать что вторая система однозначно лучше? вроде все лучше видно, значит лучше?

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

 

а в первой системе используя "blame" можно трассировать до тикета и затем до эпика, и ресурсов на это уходит 0


  • 0

#11 Little_CJIOH

Little_CJIOH

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

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


Отправлено 13 сентября 2019 - 16:29

 

 

 

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

у кого-то есть эпики в джире, на эпиках тикеты, на тикетах ченджи с тестами - а у кого-то полная система трассировки и вообще управления требованиями до самих тестов

 

можно ли сказать что вторая система однозначно лучше? вроде все лучше видно, значит лучше?

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

 

а в первой системе используя "blame" можно трассировать до тикета и затем до эпика, и ресурсов на это уходит 0

 

Однозначно сказать нельзя, зависит от размера и критичности проекта. Если проект позволяет работать без требований - пожалуйста.
Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

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


  • 0

#12 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 16:46

 

 

Однозначно сказать нельзя, зависит от размера и критичности проекта. Если проект позволяет работать без требований - пожалуйста.
Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

ну вот у Гугла например - "аппликация" огромная, количество тестов просто несчетное. Но есть ли у них система управления требованиями, где все вот в тексте описано как где и что должно работать?

 

 

 

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

надо чтобы в коммитах был номер тикета, тогда при блейме даже и не особо важно кто коммитил - уже можно трассировать до тикета и эпика

 

 

 

Но если у вас 2000 автотестов, которые требуют непрерывного внимания 5 инженеров только на поддержку и при этом никто не может точно сказать где и как тестируется фича Х. То вероятно кто-то был неправ.

на мастере все тесты должны быть зелеными, тогда и поддержки надо 0, и никакого "непрерывного внимания"


  • 0

#13 Сергей

Сергей

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

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

Отправлено 13 сентября 2019 - 18:09

Неплохо. К сожалению доказать руководству и разработчикам, почему не надо начинать с регресса автоматизацию, особенно когда прописано в kpi, практически невозможно(.
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#14 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 18:26

 

 

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

может наоборот с разработчиками нет проблем, им вообще не нужно это регрессионное тестирование когда есть нормальные автотесты


  • 0

#15 Сергей

Сергей

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

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

Отправлено 13 сентября 2019 - 19:25

Нет ничего нормального)
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#16 Spock

Spock

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

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

Отправлено 13 сентября 2019 - 19:27

 

 

Нет ничего нормального)

если у кого нет ничего нормального - надо начинать с юнит-тестов тогда :)


  • 0

#17 Сергей

Сергей

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

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

Отправлено 13 сентября 2019 - 22:00

Реальность немного другая). Если следовать чеклисту SALar, то до автоматизации мало кто дойдёт). Автоматизировать можно и без CI). Так можно вечно из г-ща не вылезти.
Для чеклиста и поднятия кармы диру самое то. Наглядный пример внедрения базовых требований где нибудь в крупной конторе, позиционирующей себя мировым лидером в ит индустрии.
Автоматизируй все то что можно автоматизировать.
  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс



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

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