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

[Eluniel]

Великие умы, спасайте! От начальника спасу нет. Каждый год требует «цели по тестированию на следующий год». Мы занимаемся разработкой веб-приложения на базе redmine по документообороту. На этот год поставили цели переписать тесты в нескольких плагинах и увеличить тестовое покрытие, а такжн внедрить гемы mutant и crystalball. Не могли бы вы поделиться опытом, какие цели ставите вы?

[Spock]

читайте книги, ходите-ездите на конфы, делитесь полученными знаниями внутри компании

[Сергей]

В основном, цели связанные с РТМ.

[Freiman]

Сначала запросите у начальника цели подразделения и всей компании на следующий год.
Потом подумайте, что реально нужно сделать на проекте, и натяните сову на глобус оттрассируйте цели компании на цели по тестированию.
У нас примерно так.
Например, подразделению надо более стабильные релизы, и чтоб ни одного "отката" с прода и не более чем N хотфиксов в год.
Как мы можем этого достичь?
- менеджеры должны делать такое и сякое
- разработчики должны делать это, это и вот это
- тестировщики обещают увеличить тестовое покрытие и довести его до M% требований, внедрить test-first и что-нибудь еще.

[Spock]

 

 

и чтоб ни одного "отката" с прода и не более чем N хотфиксов в год

такие опасные требования я бы сказал, поощряют отсутствие рефакторинга, прогресса и "работает? ничего не трогай!"

[Freiman]

такие опасные требования я бы сказал, поощряют отсутствие рефакторинга, прогресса и "работает? ничего не трогай!"

не понял вашей логики

[Spock]

 

 

не понял вашей логики

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

 

если в компании есть метрики по минимизированию хотфиксов и роллбэков, то код лучше не переписывать так как он "и так работает", лучше просто сделать изменение по заданию и все, ведь в таком случае инициатива с рефакторингом будет наказуема

 

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

[Vasiliy]

 

 

 

не понял вашей логики

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

 

если в компании есть метрики по минимизированию хотфиксов и роллбэков, то код лучше не переписывать так как он "и так работает", лучше просто сделать изменение по заданию и все, ведь в таком случае инициатива с рефакторингом будет наказуема

 

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

 

Но для этого и надо тестировать!) Чтобы и рефакторинг был и откатов с рода не было.

[Vasiliy]

А вообще тема прекрасна!:) Бюрократия в самом расцвете))

1. Про цели конторы вам уже сказали. Зайдите в разработку и поинтересуйтесь их развитием, что синхронизировать общие цели.

2. Обучение людей заложили? Посещение конференций, тематических докладов. Закупка  и изучение литературы внутри отдела?

3. Применение новых инструментов? Сокращение времени на тестирование?

[Spock]

 

 

Но для этого и надо тестировать!) Чтобы и рефакторинг был и откатов с рода не было.

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

[Vasiliy]

Ну каждому бизнесу свое:))
Кто-то может реально жить: "Работает? Ничего не меняй!"

[Spock]

 

 

Ну каждому бизнесу свое:))
Кто-то может реально жить: "Работает? Ничего не меняй!"

да, может жить, но недолго и несчастливо :)

 

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