1041

Горшочек, не вари!

Был случай на одном проекте.

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

Тестеры поразбирались недельку с системой и начали заводить баги. Штук по 10 в день.

Менеджер через пару дней очнулся, пришел в ужас от количества багов и осознания того что заказчики вскоре увидят реальное состояние дел. Сперва пробовал заворачивать баги обратно тестировщикам с посылом: "не баг, а фича", но программисты по большей части не разделяли такое мнение, т.к. баги есть баги и лучше их сейчас пофиксить чем потом, когда заказчики увидят и если не уволят. Менеджер же устраивал долгие разборы тестировщикам, пытался унять их продуктивность, но те не особо поддавались.

Закончилось тем что тестеров отправили обратно на родной проект, менеджеру их проекта объявили что "тут вам не здесь", мол, рано им еще с такими задачами работать.

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

IT-юмор

7.1K постов53.2K подписчиков

Правила сообщества

Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору

4
Автор поста оценил этот комментарий

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

1. CI/CD

2. Прогонка автотестов (юнит, интеграционные, e2e) на каждый коммит (в любой ветке)

3. Жесткие требования по стилю кода

4. Крэш репортинг с автоматическим заведением багов в тикет системе

4. Анальные кары за плохое покрытие кода тестами, за высокий рейт падений, за низкий рейт ci/cd пайплайнов.


В целом, у нас это работало на следующем стеке:

1. Gitlab (+ Gitlab CI/CD) - хостинг кода, плюс пайплайны с тестами

2. Sentry - крэш репортинг с автоматическим заведением тасков в редмайне

3. Codeception - PHPUnit (юнит тесты + интеграционные), Selenium (e2e тесты)

4. Мелкие проверки:

4.1 PHPCSFixer - кодстайл с жесткими правилами

4.2 Symfony Security Checker - проверка зависимостей на уязвимости

4.3 Unused scanner - проверка неиспользуемых зависимостей


Сам пайплайн состоял из следующих этапов:

I. Тестирование

1. Проверка кодстайла. Не там поставил запятую или микс/табов пробелов в одной строчке? Аварийное завершение пайплайна, иди переделывай.

2. Проверка уязвимостей. Хотя бы одна зависимость имеет минорную уязвимость? Аварийное завершение, иди переделывай

3. Неиспользуемые зависимости. Добавил что-то лишнее или зависимость для "потом доделаю"? Аварийное завершение, иди переделывай.

3. Юнит тесты, интеграционные тесты, e2e тесты. Хоть что-то упало? Аварийное завершение, иди переделывай.

II. Сборка

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

III. Деплой

Тоже не буду расписывать.


За покрытие кода тестами меньше 70% жестко имели тимлидов, а те - команду (меньше 90% - на пол-шишечки, среднее покрытие "по больнице" было 94-95%, у некоторых - 99.7-99.8%), за пайплайн рейт (отношение успешных пайплайнов к проваленным, в процентах) ниже 60% опять же жестко имели (этот рейт считался по всем веткам в репозиториях проекта, т.е. и dev и qa и master, поэтому такая цифра).


Звучит жутко? Некоторые при введении такой системы взвыли, но в целом за несколько месяцев приучились на ней работать. Стоит ли говорить про то, что качество и стабильность выросла в разы?

Важные моменты:

1. Время на тестирование изначально закладывалось в каждый проект (40% от времени на разработку, в особо сложных эпиках - 60%),

2. В проекте был минимум 1 QA (постоянный) и иногда (в зависимости от размера проекта) еще 1-2 QA подключались на время.

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


PS: названий не будет, nda

раскрыть ветку (1)
3
Автор поста оценил этот комментарий

Качественный процесс, только однажды работал в таком месте.

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

показать ответы

Темы

Политика

Теги

Популярные авторы

Сообщества

18+

Теги

Популярные авторы

Сообщества

Игры

Теги

Популярные авторы

Сообщества

Юмор

Теги

Популярные авторы

Сообщества

Отношения

Теги

Популярные авторы

Сообщества

Здоровье

Теги

Популярные авторы

Сообщества

Путешествия

Теги

Популярные авторы

Сообщества

Спорт

Теги

Популярные авторы

Сообщества

Хобби

Теги

Популярные авторы

Сообщества

Сервис

Теги

Популярные авторы

Сообщества

Природа

Теги

Популярные авторы

Сообщества

Бизнес

Теги

Популярные авторы

Сообщества

Транспорт

Теги

Популярные авторы

Сообщества

Общение

Теги

Популярные авторы

Сообщества

Юриспруденция

Теги

Популярные авторы

Сообщества

Наука

Теги

Популярные авторы

Сообщества

IT

Теги

Популярные авторы

Сообщества

Животные

Теги

Популярные авторы

Сообщества

Кино и сериалы

Теги

Популярные авторы

Сообщества

Экономика

Теги

Популярные авторы

Сообщества

Кулинария

Теги

Популярные авторы

Сообщества

История

Теги

Популярные авторы

Сообщества