Социология Code Review или что делать, елси ваши тестировщики начали писать тесты
•Als PPTX, PDF herunterladen•
2 gefällt mir•1,320 views
My talk from XPDays Ukraine 2012. About test code review when the acceptance tests is written by manual QA.
Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Ähnlich wie Социология Code Review или что делать, елси ваши тестировщики начали писать тесты
Ähnlich wie Социология Code Review или что делать, елси ваши тестировщики начали писать тесты (16)
Mehr von Oleksiy Rezchykov
Mehr von Oleksiy Rezchykov (9)
Социология Code Review или что делать, елси ваши тестировщики начали писать тесты
- 1. Социология Code Review или что делать, если ваши тестировщики взялись писать код Ноябрь 2012 Алексей Резчиков
- 2. Обо мне Java разработчик и тимлид уже более 6-ти лет В разное время работал project, resource, development и competency manager Последователь XP/Agile/Lean Консультант по Testing Automation, Continuous Integration и Continuous Delivery Евангелист Spring Framework в 2 рамках SpringByExample.com.ua @twincengray #xpdays
- 3. Реалии индустрии @twincengray #xpdays 3
- 4. Реалии индустрии @twincengray #xpdays 4
- 5. Реалии индустрии @twincengray #xpdays 5
- 6. Как это работает? @twincengray #xpdays 6
- 7. Автоматизация @twincengray #xpdays 7
- 8. А давайте напишем фреймворк автоматизации @twincengray #xpdays 8
- 9. @twincengray #xpdays 9
- 10. To BDD or not to BDD @twincengray #xpdays 10
- 11. Поехали!!! @twincengray #xpdays 11
- 12. Кто будет писать тесты? @twincengray #xpdays 12
- 13. Расскажите своим тестировщикам про… @twincengray #xpdays 13
- 14. Composition or Inheritance Наследование не используется совсем Наследование используется там где стоит использовать композицию @twincengray #xpdays 14
- 15. Строковые преобразования Особенности реализации строк в языке программирования Строковые литералы/константы Манипуляции по строками @twincengray #xpdays 15
- 16. Деньги Точность в операциях с деньгами Правильные типы данных Собственные утилиты @twincengray #xpdays 16
- 17. Даты Правильное использование встроенных средств Сторонние библиотеки Собственные хелпер классы @twincengray #xpdays 17
- 18. i18n & l10n Использование локали Хранение/получение сообщений Форматирование (даты, деньги) @twincengray #xpdays 18
- 19. Автоматизировали регрессию @twincengray #xpdays 19
- 20. Что будет если просто… @twincengray #xpdays 20
- 21. НО это хороший первый шаг @twincengray #xpdays 21
- 22. Параметризация тестов A=1; B=2; A=2; B=2; A=3; B=3; C=1; C=2; C=3; @twincengray #xpdays 22
- 23. PageObject/PageElement Page Page class Test @twincengray #xpdays 23
- 24. Steps @twincengray #xpdays 24
- 25. Что получилось? Тот же тест что и несколько слайдов ранее… @twincengray #xpdays 25
- 26. Что делать со всем этим кодом? @twincengray #xpdays 26
- 27. Checklist от КО Посмотреть мою прошлую презентацию Не оставляйте без присмотра Добавлять фичи Добавлять тесты фич Постоянно рефакторить @twincengray #xpdays 27
- 28. Тесты и люди @twincengray #xpdays 28
- 29. Основываясь на личном опыте… @twincengray #xpdays 29
- 30. Куда девать тесты? @twincengray #xpdays 30
- 31. Черная или белая коробка? @twincengray #xpdays 31
- 32. Этот загадочный зверь регрессия @twincengray #xpdays 32
- 33. Дайте тестам повзрослеть @twincengray #xpdays 33
- 34. Итог Роли на проектах все больше смешиваются Автоматизации становится необходимой Не отделяйте код тестов от проектного кода Постоянно совершенствуйте свои тесты Тестировщики и разработчики обменивайтесь знаниями и опытом То чем мы занимаемся - командная игра @twincengray #xpdays 34
- 35. Вопросы? @twincengray @ua_spring oleksiy.rezchykov@gmail.com SpringByExample.com.ua mcgray.com.ua @twincengray #xpdays 35
Hinweis der Redaktion
- Спасибо что досидели.Трудно идти первым и трудно идти последнимСегодня я хотел бы опять поговорить об инспекции кода или о Code Review. Снова, потому, что в прошлом году я рассказывал про психологический аспект этой практики.О Code Review было сказано уже очень много.Разбирать классические подходы к организации, применяемые инструменты я не буду. Этой информации достаточно в открытых источникахСегодня хотел бы рассказать о том, как изменения в индустрии влияют на проекты, а следовательно на наши устоявшиеся практики
- JavaManagementXP/Agile/LeanКонсультант– вот откуда я черпаю большинство информации из окопов, как говорит КнибергВ свободное от зарабатывания на хлеб время SBEКто моя аудитория: тестировщики, разработчики, менеджеры.Новые вызовы для проектных командАвтоматизация. НачалоТесты. Как с ними житьГраблиИтог
- Для большинства проектов, и я говорю не только про public web что интересно сюда подключаются уже и финансово-банковский сектор (телеком давно тут) TTM становится главным критерием успешности
- Распространяются идеи Lean Startup, когда важно побыстрее доставить услугу на рынок, чтобы получить быстрый ответ этого самого рынка и как следствие быть первым, кто сделает именно ТО что НУЖНО на рынке.
- Также распространяется концепция DevOpsПро это сегодня говорить не будем
- Единственный возможный способ заставить это работать это реализовать CD.CD это современный buzwordэдакая мантра для менеджмента.Как работает этот XpInjection=====================Все хотят CDУ многих уже есть CI и хорошее покрытие Unit/Integration tests
- Высокая степень автоматизации, как необходимое условие CDАвтоматизация развертывания, автоматизация сборки и конечно же автоматизация тестирования
- Болезнь поражает очень многих. Сам делал это несколько раз, но имею оправдания. Так как это было давно и тогда нельзя было обеспечить всю требуемую функциональность существующими средствами.Кто будет писать фреймворк?Разработчики– хотят выложиться по полной и часто в поисках идеального продукта забывают для чего он нуженТестировщики– часто напаковывают продукт функциональностью, которая скорее всего не понадобится нарушая принципы YAGNI & KISSВместе (одни знают КАК это сделать другие ЧТО должно получиться в результате)Если вы все таки пишете свой фреймворк или расширяете существующие не забывайте его тестировать
- Болезнь поражает очень многих. Сам делал это несколько раз, но имею оправдания. Так как это было давно и тогда нельзя было обеспечить всю требуемую функциональность существующими средствами.Кто будет писать фреймворк?Разработчики– хотят выложиться по полной и часто в поисках идеального продукта забывают для чего он нуженТестировщики– часто напаковывают продукт функциональностью, которая скорее всего не понадобится нарушая принципы YAGNI & KISSВместе (одни знают КАК это сделать другие ЧТО должно получиться в результате)Если вы все таки пишете свой фреймворк или расширяете существующие не забывайте его тестировать
- Каждая команда должна решить это для себяЕсли бизнес не работает с вами плотно, возможно достаточно просто Acceptance TestsВ случае если вы все же решили применять BDD учтите, что теперь в ваш репозиторий скорее всего будут иметь доступ люди бизнеса, которые скорее всего будут писать требования, а лучше критерии приемки. Сейчас набирает популярности подход Specification by Example, при котором ваши тесты и будут являться документацией по проекту.
- Тут я заканчиваю с вещами напрямую не касающимися инспекции кода тестов
- В моей презентации тоже не обошлось без Вейдера– куда же без негоИ сразу же очень непростой вопросНа этом слайде и далее по презентации тесты – автоматизированные приемочные либо регрессионные тесты. Для простоты - просто тесты.Три путиРазработчики пишут тесты вместе с фичами (сказка для нас, надеюсь, что пока)Тесты пишут автоматизаторы (редкий случай)Обычные тестировщики начинают писать тесты + - Всех подходов
- Или основные ошибки начинающих при написании тестов, а также о чем им стоит рассказать в первую очередь
- В использовании наследование несравненно больше ошибок, чем в попытке следовать полиморфизму и инкапсуляции.Но про них тоже стоит поговорить.
- ВладимирЦукур вчера говорил, что они выбрали для написания тестов Groovy (у них тесты начали писать тестировщики, не владевшие автоматизацией)Это во много было вызвано именно такими проблемами.Некоторые особенности работы с данными в языке программирования
- Коля и Андрей вчера говорили о том, что разработчик должен заглядывать в код к тестировщику. Я скажу больше – лучше самому научить тестировщика ряду приемов, чтоб потом не находить в коде сюрпризов.
- Самый распространённый и самый верный, шаг.Но и тут на подстерегают сложности.
- Что будет если просто автоматизировать ручные проверки:Как правило очень некрасивый кодКоторый конечно сложно рефакторить, масштабировать, да что там говорить его сложно читать.
- Что стоит сделать после такого первого шага
- Использовать лучшие практики –Page Object, Page Element, Steps.
- Использовать лучшие практики –Page Object, Page Element, Steps.
- У Коли А. попросить картинку с КО!?Поменять
- Занимайтесь образованием других, кто бы ни писал тесты опускать планку качества не стоит!!!Кто пишет, а кто проводит ревизию?Назначайте ответственногоиз числа разработчиковДелайте «авианалеты»Тактика без стратегии ничего не дает – планируйте развитие тестов
- Поначалу очень хочется положить тесты и фреймфорк, если мы его писали в отдельный репозиторий. Это скорее плохо чем хорошо. К тестам сразу стоит относится так же как и другому коду, но в то же время они должны быть достаточно изолированы в плане зависимостейМой совет разделяемые артефакты, один репозиторий. Для того, чтоб можно было использовать те же метрики для оценки и те же настройки статических анализаторов (см. мою презентацию за прошлый год). Это позволит вам держать руку на пульсе.
- Мне кажется что после доклада Коли и Андрея и вчерашнего доклада Владимира тема так и осталась не раскрыта до конца.Фичатестируется всегда на самом нижнем из возможных уровней, пусть и открывая коробку. Цель автоматизированной регрессии также работать быстро - так что тут тоже работает это правило.Test set UP, REST API, Scripts
- Не переносите бездумно тесты фич в регрессионыйsuite.У этих тестов совершенно разное назначение. Стоит добавить дополнительные проверки в тесты модулей на которые повиляла данная новая функциональность.
- СимптомыТесты становятся мусорной свалкой (трудно понять что внутри)Тесты работают часамиВ итоге их больше никто не запускает
- То о чем уже говорил, но хотел бы повторить в завершении.Некоторые вещи звучат цитатами КО, но от этого им чаще не следуют…