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

[Dananas]

Доброго дня всем!

 

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

Как вы справляетесь с проблемой регресса?

 

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

 

Апдейт: по предложениям:
1. Автоматизация тестов.
2. Автоматизация настройки окружения и данных.

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

4. Приоритизация проверок путем анализа риска (часть сценариев можно не гонять).

5. Уменьшение объема проверки путем выделения функциональных модулей (зачем проверять то, что никак не менялось).

6. Уменьшение регрессивного набора - путем его оптимизации (одним сценарием проверяем ту же кучку, что раньше проверяли 2-мя сценариями).

Сообщение отредактировал Dananas: 05 ноября 2015 - 15:35

[aid]

Значит надо не с пол плювка покрыть. Логично?

[Dananas]

Значит надо не с пол плювка покрыть. Логично?

Это крайне дорого и в конечном счете может быть не оправдано.

[aid]

Тогда дешево можно - пусть вы и ваш коллектив остаётся на неоплачиваемые переработки. Можно по субботам и воскресеньям работать. И тогда штат можно не расширять. Выгодно.

[Molechka]

С проблемой регресса — автотестами.

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

 

Как вариант, если регресс скучный и унылый:

1. Нанять начинающих, дешевую рабочую силу. Они полгода-год будут вполне удовлетворены постоянным регрессом, им навыки оттачивать итд.

2. Пускать к себе начинающих бесплатно, организовав мини-обучение. Тогда придется вложиться только в обучение: первый раз все подготовить, собрать граблей, отвечая в 100500 раз на один и тот же вопрос, переделать все обучение и дорабатывать, времени постепенно будет тратиться меньше. Будете что-то типа темы соседней "опен-сорс проекту нужны начинающие". Но учтите, там будет большой наплыв на месяц-два

[Vad1m198]

Можно еще автоматизировать настройку тестового стенда и создание тестовых данных. Автоматизация это не только тесты.

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

[SALar]

http://blog.shumoos.com/archives/268

 

Начните с автоматизации тестирования изменяемого / нового функционала. Когда сможете не отставать от программистов, и полностью автоматизируете тестирование нового функционала, тогда и только тогда можно начать покрывать тестами остальной код.

[Dananas]

Можно еще автоматизировать настройку тестового стенда и создание тестовых данных. Автоматизация это не только тесты.

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

А не тестировать все это как? Смок прогнать - им сыт не будешь. Какой-то конкретный набор функционала не проверять, а какой тогда? У нас на данный момент 70% функционала используется ежедневно. А 70% - это около недели регресса.

[Dananas]

http://blog.shumoos.com/archives/268

 

Начните с автоматизации тестирования изменяемого / нового функционала. Когда сможете не отставать от программистов, и полностью автоматизируете тестирование нового функционала, тогда и только тогда можно начать покрывать тестами остальной код.

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

[Vad1m198]

 

Можно еще автоматизировать настройку тестового стенда и создание тестовых данных. Автоматизация это не только тесты.

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

А не тестировать все это как? Смок прогнать - им сыт не будешь. Какой-то конкретный набор функционала не проверять, а какой тогда? У нас на данный момент 70% функционала используется ежедневно. А 70% - это около недели регресса.

 

Я ж написал как))

Согласно приоритетам. Новые и самые критичные(важные) фичи тестируются всегда(перед каждым релизом), а остальное если остается время. Но если между релизами Вы не успеваете протестировать даже новые и критические фичи, то решение одно - увеличивать штат. Автоматизация только усугубит положение. ИМХО

[Dananas]

Я к тому, что как мне расставить приоритеты, когда у меня все важное? Есть ли какие-нибудь методики и т.п.?

[Vad1m198]

Расставлять приоритеры не Ваша задача. У Вас ведь есть аналитики, проджект менеджеры? Вот они это должны делать. Вы можете составить список, и приоретизировать его сами ("как Вам кажется") и с этим списком прийти к менеджеру. А там уже менеджер скажет, что все ок, или исправит...

[Dananas]

В общем, по итогам что я вижу:
1. Автоматизировать.
2. Увеличить количество проверяющих.

3. Или уменьшить количество проверок.

+

4. Оптимизация текущей работы.

Как понять, какой вариант будет более продуктивным?

[Dananas]

Поразмыслил чуть:

Автоматизация - требует доп соглашений, пока отложу этот пункт.

 

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

 

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

 

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

1. Какая работа сколько времени съедает.

2. Могу ли я ее сократить (все ли участники процесса будут согласны).

3. Каким именно я могу ее сократить.

 

Поправьте меня, пожалуйста, если я где-то мыслю не так.

[Little_CJIOH]

 

http://blog.shumoos.com/archives/268

 

Начните с автоматизации тестирования изменяемого / нового функционала. Когда сможете не отставать от программистов, и полностью автоматизируете тестирование нового функционала, тогда и только тогда можно начать покрывать тестами остальной код.

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

 

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

У меня в ситуации постоянно меняющейся архитектуры и фиксированых пользовательских сценариев на фоне полного отсутствия ресурсов для регрессионного тестирования такой подход дал хороший результат.

[lurk]

1. Анализ рисков

2. Уменьшение регрессивного набора - путем его оптимизации, в том числе и за счет анализа рисков

3. Подключение разработчиков к тестированию 

4. Увеличение штата - тоже вариант решения - все зависит от того - чего Вы хотите добиться. 

[Dananas]

1. Анализ рисков

2. Уменьшение регрессивного набора - путем его оптимизации, в том числе и за счет анализа рисков

3. Подключение разработчиков к тестированию 

4. Увеличение штата - тоже вариант решения - все зависит от того - чего Вы хотите добиться. 

 

1. Да, анализ рисков это тоже вариант. Утащил наверх.
2. Хмм... Уменьшение объема самого тестового набора, да, это сократит время на регресс. Но координально или статистически это мало времени выкроит. Но если объем приложения и тестового набора столь велик, то будет один из ключевых выходов. Но, к сожалению, не мой вариант. То же утащу наверх.

3, 4. Это в принципе же одно и то же? И там, и там, увеличение штата проверяющих.

[Dananas]

 

 

http://blog.shumoos.com/archives/268

 

Начните с автоматизации тестирования изменяемого / нового функционала. Когда сможете не отставать от программистов, и полностью автоматизируете тестирование нового функционала, тогда и только тогда можно начать покрывать тестами остальной код.

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

 

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

У меня в ситуации постоянно меняющейся архитектуры и фиксированых пользовательских сценариев на фоне полного отсутствия ресурсов для регрессионного тестирования такой подход дал хороший результат.

 

 

Да, когда созреем до автотестов именно этим путем и пойдем. Спасибо за напоминание

[leftCh]

1. Регрессионные тесты находят ошибки? Как часто?  Насколько критичные?

2. Пользователи находят ошибки? Как часто? Насколько критичные?

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

4. Что из себя представляет ваш "нетривиальный для автоматизации" продукт? UI, модули, апи, нужные основные данные об архитектуре и вкратце о назначении продукта

 

Сколько видела активностей по автоматизации, ни у кого не получилось с первого раза :)

[Molechka]

Сколько видела активностей по автоматизации, ни у кого не получилось с первого раза :)

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

Вот и проходят первые грабли :)