Комментарии 20
Вы серьезно? КДПВ больше мегабайта!!!
А скромность М-Видео, лого которого оказалось аж на спойлере Феррари, вас не смутила?
Исправили. Спасибо, что заметили!
2019 год, люди до сих пор ругаются на тяжелые картинки
КДПВ больше мегабайта!Тяга к большому видна во всём :)
У меня был случай: Года полтора назад переходил как-то на сайт Мвидео откуда-то по рекламному баннеру, и мне повешались длинные куки. А за день до этого я уже клал что-то в корзину, и куки уже какие-то были. Естественно браузер начал их передавать при каждом запросе. Сайт такое не принял, начал ругаться 503 ошибкой, что кука слишком длинная, и всё тут. И никак и никто не смог помочь. Чистка куки спасла ситуацию.
Решил проверить трюк — даже после чистки куков, но при переходе с баннера — кука снова становилась слишком длинной, и сайт падал(точнее не впускал меня). Такой провальчик запомнился надолго)
В первую очередь была реализована смена методологии — переход со Scrum, то есть спринтовой модели, на Kanban.
Почему то считается, что в скраме деплоиться в прод надо только в конце спринта…
Почему?
Деплойся, когда удобно для достижения нужного результата.
Дальше начинаются детали, что конкретно было сделано для ускорения ttm.
Т.е. ttm сократили вполне конкретными мероприятиями, а не сменой одной доски на другую.
Методология разработки в данном конкретном случае косвенно влияет на сокращение TTM. Kanban дает чуть больше гибкости в плане смены приоритетов, что очень актуально для ритейла. Ну а если подходить формально, то в Scrum все-таки деплоить фичу стоит после прохождения всех процедур по тестированию и состав спринта менять можно с большой натяжкой.
Основное сокращение принес именно комплекс выполненных мер.
Основное сокращение принес именно комплекс выполненных мер.
в Scrum все-таки деплоить фичу стоит после прохождения всех процедур по тестированию и состав спринта менять можно с большой натяжкой.
Деплоить после успешного прохождение процедур по тестированию нужно всегда, а не только в скраме. И для тестирования не обязательно ждать конца спринта. В целом проблема «когда деплоить» больше техническая, нежели процессная.
Спасибо за статью, очень интересно.
1. Почему регрессионные автоматизированные тесты используются после объединения веток, а не до?
2. У вас есть выделенные автоматизаторы? Это же не эффективно, почему тестеры не учатся кодить? Или почему этим не занимаются программисты?
3.
Огонь! На каком количестве задач считали?
4.
Уволили? Перепрофилировали? Если не секрет, куда?
1. Почему регрессионные автоматизированные тесты используются после объединения веток, а не до?
2. У вас есть выделенные автоматизаторы? Это же не эффективно, почему тестеры не учатся кодить? Или почему этим не занимаются программисты?
3.
с 30–35 до 25 дней сократилась продолжительность time to market
Огонь! На каком количестве задач считали?
4.
на 50 % уменьшилась команда ручного тестирования;
Уволили? Перепрофилировали? Если не секрет, куда?
1. Почему регрессионные автоматизированные тесты используются после объединения веток, а не до?
Автоматизированные тесты используются в обоих случаях: сначала локально использует каждая из команд в своей ветке, а затем автотесты прогоняются на мастер-ветке убеждаемся, что ничего не отломалось после внесения изменений.
2. У вас есть выделенные автоматизаторы? Это же не эффективно, почему тестеры не учатся кодить? Или почему этим не занимаются программисты?
Львиная доля автоматизаторов (80%) – это как раз функциональные тестировщики, которые тиражируют автотесты на языке Gherkin. А вот основу или «ключевые слова» для автоматизации пишут полноценные квалифицированные 20% инженеров по АТ. В таком виде конструкция выглядит стабильной и легкоподдержуемой.
с 30–35 до 25 дней сократилась продолжительность time to market
Огонь! На каком количестве задач считали?
Считали усреднённо, на основе нескольких по составу релизов.
на 50 % уменьшилась команда ручного тестирования;
Уволили? Перепрофилировали? Если не секрет, куда?
Команда перевелась на другие проекты, покорять новые горизонты)
Рассказ интересный. Спасибо.
Расскажите, пожалуйста, как поддерживаете адекватность конфигурации стендов.
У нас есть несколько тестовых стендов, практически под каждую команду. Кроме того, есть препродакшен-конфигурации стендов для финального тестирования релизов и патчей. На тестовых стендах обновление базы происходит примерно раз в месяц: накатывается дамп свежей базы с продуктива, минимально необходимого объема. На препродакшен-стендах обновление базы делается более регулярно и в полном объеме, по понятным причинам. Выкладкой самого продукта занимаются Devops-инженеры, взаимодействуя с командой Quality Assurance. Все вышеописанные процедуры автоматизированы.
Возможно, вы можете ещё попробовать Blockly затащить. Для упрощения написания тестов.
М-Видео когда-то спонсировал Scuderia Ferrari или это фейк?
Это метафора :)
Скорее враньё. Метафорой это можно было бы назвать, если бы на фото был обезличенный болид без ливреи.
Интересно что подумает об этом сами formula1.ferrari.com
Вы бы мобильную версию сайта починили, чтобы на смартфонах нормально можно было пользовать, а то каждая страничка по пол года грузится, тормозит и скачет.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как сократить time-to-market: история про автоматизацию тестирования в «М.Видео»