Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Дефицит ресурсов тестирования... или нет?

905 views

Published on

Доклад Анастасии Леншмидт на конференции SQA Days-18, 27-28 ноября 2015 г., Москва
www.sqadays.com

Published in: Education
  • Be the first to comment

  • Be the first to like this

Дефицит ресурсов тестирования... или нет?

  1. 1. Дефицит ресурса тестирования… или нет? Леншмидт Анастасия АвтоТрансИнфо, Санкт-Петербург skype: a.lenshmidt a.lenshmidt@gmail.com Масштаб бедствия: 19 слайдов
  2. 2. Будем знакомы ● Система ЭДО (web-приложение) ● 7 разработчиков ● 2 тестировщика ● 4 интеграционных проекта Слайд 2 из 19
  3. 3. Основы основ Что мы используем: • jira + confluence • git + stash • selenium • slack Слайд 3 из 19
  4. 4. Ой, все... Слайд 4 из 19
  5. 5. Где собака зарыта? На что обращаем внимание: • Cycle time или время жизни задачи: сколько раз проходит цикл разработка-тестирование- разработка • Work in progress: количество одновременно тестируемых задач (возможность распараллеливать задачи) • Testability: предоставил ли разработчик инструменты и сведения о том, как тестировать Слайд 5 из 19 Почему задачи долго в тестировании?
  6. 6. Помнишь, как все начиналось… ● StartUp ● Разработка “в закрытую” ● 3 разработчика ● 1 тестировщик Flow: ● Есть только ветка master ● Разработчики все “сливают” сами в master ● Редкие выкладки ● Hotfix’ов мало Слайд 6 из 19 ЭТАП 0
  7. 7. Слайд 7 из 19 Время жизни задач ЭТАП 0
  8. 8. Кто решает? Flow: ● По-прежнему существует только master ● Что вливаем? Когда? – решают тестировщики ● Нужна стабильная “ветка” ● Проект запустили ● Появились пользователи ● 5 разработчиков ● 2 тестировщика ● 2 интеграционных проекта Слайд 8 из 19 ЭТАП 1
  9. 9. Время жизни задач Слайд 9 из 19 ЭТАП 1
  10. 10. Больше людей-больше веток ● 7 разработчиков ● 2 тестировщика ● 4 интеграционных проекта Flow: ● Стабильный master ● Много задач → много “веток” ● Требуется больше коммуникаций (особенно на начальном этапе) ЭТАП 2 Слайд 10 из 19
  11. 11. Время жизни задач Слайд 11 из 19 ЭТАП 2
  12. 12. Слайд 12 из 19 Что из этого вышло: ● “Релизами” (выкладкой) управляют тестировщики ● Выкладки 3-4 раза в неделю ● При попадании на тестовый стенд разработчик быстро получает feedback (нет сомнений, чей код сломал ветку) ● В любой момент времени можем выложить hotfix или срочную задачу
  13. 13. Ближайшие цели: Прогон автотестов локально на ветках разработчиков: ● feedback максимально рано (на любом этапе разработки) ● разработчики не тратят время на проверку базового функционала Слайд 13 из 19
  14. 14. Еще немножко Слайд 14 из 19 “историй из жизни”
  15. 15. Автотесты Слайд 15 из 19
  16. 16. Локальные тестовые стенды Хорошо, если он не 1. И их не 1 000, а ровно столько, сколько нужно тестировщику Слайд 16 из 19 или
  17. 17. Удобно-это так: Слайд 17 из 19
  18. 18. Выводы: ● Всегда ориентируйтесь на ситуацию ● Будьте готовы к переменам ● Делайте удобные процессы ● Пишите документацию ● Расставляйте приоритеты ● Договаривайтесь Слайд 18 из 19
  19. 19. На заметку • Slack https://slack.com/is • Errbot http://errbot.io/ • ChatOps https://speakerdeck.com/jnewland/chatops-at-github • Про наши автотесты http://sqadays.com/ru/talk/16562 • Behave http://behave.readthedocs.org/en/latest/tutorial.html Слайд 19 из 19

×