Социология Code Review или что делать, елси ваши тестировщики начали писать тесты

Editor's Notes

• #2: Спасибо что досидели.Трудно идти первым и трудно идти последнимСегодня я хотел бы опять поговорить об инспекции кода или о Code Review. Снова, потому, что в прошлом году я рассказывал про психологический аспект этой практики.О Code Review было сказано уже очень много.Разбирать классические подходы к организации, применяемые инструменты я не буду. Этой информации достаточно в открытых источникахСегодня хотел бы рассказать о том, как изменения в индустрии влияют на проекты, а следовательно на наши устоявшиеся практики
• #3: JavaManagementXP/Agile/LeanКонсультант– вот откуда я черпаю большинство информации из окопов, как говорит КнибергВ свободное от зарабатывания на хлеб время SBEКто моя аудитория: тестировщики, разработчики, менеджеры.Новые вызовы для проектных командАвтоматизация. НачалоТесты. Как с ними житьГраблиИтог
• #4: Для большинства проектов, и я говорю не только про public web что интересно сюда подключаются уже и финансово-банковский сектор (телеком давно тут) TTM становится главным критерием успешности
• #5: Распространяются идеи Lean Startup, когда важно побыстрее доставить услугу на рынок, чтобы получить быстрый ответ этого самого рынка и как следствие быть первым, кто сделает именно ТО что НУЖНО на рынке.
• #6: Также распространяется концепция DevOpsПро это сегодня говорить не будем
• #7: Единственный возможный способ заставить это работать это реализовать CD.CD это современный buzwordэдакая мантра для менеджмента.Как работает этот XpInjection=====================Все хотят CDУ многих уже есть CI и хорошее покрытие Unit/Integration tests
• #8: Высокая степень автоматизации, как необходимое условие CDАвтоматизация развертывания, автоматизация сборки и конечно же автоматизация тестирования
• #9: Болезнь поражает очень многих. Сам делал это несколько раз, но имею оправдания. Так как это было давно и тогда нельзя было обеспечить всю требуемую функциональность существующими средствами.Кто будет писать фреймворк?Разработчики– хотят выложиться по полной и часто в поисках идеального продукта забывают для чего он нуженТестировщики– часто напаковывают продукт функциональностью, которая скорее всего не понадобится нарушая принципы YAGNI & KISSВместе (одни знают КАК это сделать другие ЧТО должно получиться в результате)Если вы все таки пишете свой фреймворк или расширяете существующие не забывайте его тестировать
• #10: Болезнь поражает очень многих. Сам делал это несколько раз, но имею оправдания. Так как это было давно и тогда нельзя было обеспечить всю требуемую функциональность существующими средствами.Кто будет писать фреймворк?Разработчики– хотят выложиться по полной и часто в поисках идеального продукта забывают для чего он нуженТестировщики– часто напаковывают продукт функциональностью, которая скорее всего не понадобится нарушая принципы YAGNI & KISSВместе (одни знают КАК это сделать другие ЧТО должно получиться в результате)Если вы все таки пишете свой фреймворк или расширяете существующие не забывайте его тестировать
• #11: Каждая команда должна решить это для себяЕсли бизнес не работает с вами плотно, возможно достаточно просто Acceptance TestsВ случае если вы все же решили применять BDD учтите, что теперь в ваш репозиторий скорее всего будут иметь доступ люди бизнеса, которые скорее всего будут писать требования, а лучше критерии приемки. Сейчас набирает популярности подход Specification by Example, при котором ваши тесты и будут являться документацией по проекту.
• #12: Тут я заканчиваю с вещами напрямую не касающимися инспекции кода тестов
• #13: В моей презентации тоже не обошлось без Вейдера– куда же без негоИ сразу же очень непростой вопросНа этом слайде и далее по презентации тесты – автоматизированные приемочные либо регрессионные тесты. Для простоты - просто тесты.Три путиРазработчики пишут тесты вместе с фичами (сказка для нас, надеюсь, что пока)Тесты пишут автоматизаторы (редкий случай)Обычные тестировщики начинают писать тесты + - Всех подходов
• #14: Или основные ошибки начинающих при написании тестов, а также о чем им стоит рассказать в первую очередь
• #15: В использовании наследование несравненно больше ошибок, чем в попытке следовать полиморфизму и инкапсуляции.Но про них тоже стоит поговорить.
• #16: ВладимирЦукур вчера говорил, что они выбрали для написания тестов Groovy (у них тесты начали писать тестировщики, не владевшие автоматизацией)Это во много было вызвано именно такими проблемами.Некоторые особенности работы с данными в языке программирования
• #18: Коля и Андрей вчера говорили о том, что разработчик должен заглядывать в код к тестировщику. Я скажу больше – лучше самому научить тестировщика ряду приемов, чтоб потом не находить в коде сюрпризов.
• #20: Самый распространённый и самый верный, шаг.Но и тут на подстерегают сложности.
• #21: Что будет если просто автоматизировать ручные проверки:Как правило очень некрасивый кодКоторый конечно сложно рефакторить, масштабировать, да что там говорить его сложно читать.
• #22: Что стоит сделать после такого первого шага
• #24: Использовать лучшие практики –Page Object, Page Element, Steps.
• #25: Использовать лучшие практики –Page Object, Page Element, Steps.
• #28: У Коли А. попросить картинку с КО!?Поменять
• #29: Занимайтесь образованием других, кто бы ни писал тесты опускать планку качества не стоит!!!Кто пишет, а кто проводит ревизию?Назначайте ответственногоиз числа разработчиковДелайте «авианалеты»Тактика без стратегии ничего не дает – планируйте развитие тестов
• #31: Поначалу очень хочется положить тесты и фреймфорк, если мы его писали в отдельный репозиторий. Это скорее плохо чем хорошо. К тестам сразу стоит относится так же как и другому коду, но в то же время они должны быть достаточно изолированы в плане зависимостейМой совет разделяемые артефакты, один репозиторий. Для того, чтоб можно было использовать те же метрики для оценки и те же настройки статических анализаторов (см. мою презентацию за прошлый год). Это позволит вам держать руку на пульсе.
• #32: Мне кажется что после доклада Коли и Андрея и вчерашнего доклада Владимира тема так и осталась не раскрыта до конца.Фичатестируется всегда на самом нижнем из возможных уровней, пусть и открывая коробку. Цель автоматизированной регрессии также работать быстро - так что тут тоже работает это правило.Test set UP, REST API, Scripts
• #33: Не переносите бездумно тесты фич в регрессионыйsuite.У этих тестов совершенно разное назначение. Стоит добавить дополнительные проверки в тесты модулей на которые повиляла данная новая функциональность.
• #34: СимптомыТесты становятся мусорной свалкой (трудно понять что внутри)Тесты работают часамиВ итоге их больше никто не запускает
• #35: То о чем уже говорил, но хотел бы повторить в завершении.Некоторые вещи звучат цитатами КО, но от этого им чаще не следуют…