Основные ошибки внедрения ATDD, BDD, CI, CD на проектах, Резчиков Алексей
Каждый новый проект, к которому Алексей подключается в качестве консультанта, уже имеет свою историю внедрения автоматизации тестирования, CI и CD. Истории очень разные, каждая интересна по-своему, каждая рассказывает об ошибках. О самых распространенных из них, а также о том, как их не допустить, Алексей расскажет в своем докладе.
This presentation helps understand how to evaluate a professional's growth and how to raise their salary in an appropriate and balanced way.
This presentation by Vitalii Voloshchuk (Project Manager, GlobalLogic) was delivered at Lviv Project Management Day on November 14, 2015.
This presentation is about the potential of 1x1 meetings between managers and their team members, and the way managers can make the most out of such meetings.
This presentation by Vitalii Voloshchuk (Project Manager, GlobalLogic) was delivered at Lviv Project Management Day on May 30, 2015.
Lear more at http://globallogic.com.ua/lviv-pm-day-spring-15-slides
Almost everyone who works with agile software engineering practices is aware of Code Review, and most of you already had a chance to participate in such kind of acitivities. Unfortunately very few people realize that Code Reviews is not only an approach of making the architecture and code better, but also important communication point between peers, where ones judge and others get judged.
Teams which don’t follow the basic rules of efficient communication and problem solving during Сode Reviews, have a high risk of being affected by issues, which can lately ruin their team attitude and even personal relations between the colleagues.
Having faced with such negative experiences, I’ve collected a plenty of bad practices running a Code Review and asked my colleagues about their emotions after being “code reviewed” in unproper way.
With all of that we’ll try to understand the most dangerous pitfalls of weak Code Reviews, their influences on team morale and will also leave some place for your experiences with this approach from your side. As a result you’ll have a clear idea about how no to run a Code Review and avoid personal issues in your daily work.
Peer code review is one of the most effective ways to find defects – but is it agile? Because agile teams loathe heavy process, code review practices can easily fail. However, lightweight peer code review aligns well with the central tenets of agile—keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares recent research on code review practices and describes an agile code review approach—how much time to spend, which code to review, how much code to review at a time, how to set goals, the value of annotation, and more. After comparing four styles of code review—pair programming, over-the-shoulder, email, and tool-assisted—Gregg gives specific advice for creating review checklists and dealing with the social effects of code review in an agile environment.
Основные ошибки внедрения ATDD, BDD, CI, CD на проектах, Резчиков Алексей
Каждый новый проект, к которому Алексей подключается в качестве консультанта, уже имеет свою историю внедрения автоматизации тестирования, CI и CD. Истории очень разные, каждая интересна по-своему, каждая рассказывает об ошибках. О самых распространенных из них, а также о том, как их не допустить, Алексей расскажет в своем докладе.
This presentation helps understand how to evaluate a professional's growth and how to raise their salary in an appropriate and balanced way.
This presentation by Vitalii Voloshchuk (Project Manager, GlobalLogic) was delivered at Lviv Project Management Day on November 14, 2015.
This presentation is about the potential of 1x1 meetings between managers and their team members, and the way managers can make the most out of such meetings.
This presentation by Vitalii Voloshchuk (Project Manager, GlobalLogic) was delivered at Lviv Project Management Day on May 30, 2015.
Lear more at http://globallogic.com.ua/lviv-pm-day-spring-15-slides
Almost everyone who works with agile software engineering practices is aware of Code Review, and most of you already had a chance to participate in such kind of acitivities. Unfortunately very few people realize that Code Reviews is not only an approach of making the architecture and code better, but also important communication point between peers, where ones judge and others get judged.
Teams which don’t follow the basic rules of efficient communication and problem solving during Сode Reviews, have a high risk of being affected by issues, which can lately ruin their team attitude and even personal relations between the colleagues.
Having faced with such negative experiences, I’ve collected a plenty of bad practices running a Code Review and asked my colleagues about their emotions after being “code reviewed” in unproper way.
With all of that we’ll try to understand the most dangerous pitfalls of weak Code Reviews, their influences on team morale and will also leave some place for your experiences with this approach from your side. As a result you’ll have a clear idea about how no to run a Code Review and avoid personal issues in your daily work.
Peer code review is one of the most effective ways to find defects – but is it agile? Because agile teams loathe heavy process, code review practices can easily fail. However, lightweight peer code review aligns well with the central tenets of agile—keeping feedback close to the point of creation, increasing team velocity by finding defects faster, and improving collective code ownership through frequent collaboration. Gregg Sporar shares recent research on code review practices and describes an agile code review approach—how much time to spend, which code to review, how much code to review at a time, how to set goals, the value of annotation, and more. After comparing four styles of code review—pair programming, over-the-shoulder, email, and tool-assisted—Gregg gives specific advice for creating review checklists and dealing with the social effects of code review in an agile environment.
Presentation from Agile Base Camp 2 conference (Kiev, May 2010) and AgileDays'11 (Moscow, March 2011) about one of the most useful engineering practices from XP world.
TDD style proved itself as very reliable and quick way of business tasks solving with code. But most of examples on trainings and in the internet show how to apply TDD to simple input/output code or interface based dependencies with mocking techniques. What about other areas of application development like database related code? Could it be developed with TDD style? What does TDD bring to developer? I will try to answer these questions in my talk and show on practical examples how helpful TDD is for database code, how it reduces risks and opens the door for refactoring techniques.
How to successfully grow a code review cultureNina Zakharenko
As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
Overview of Gerrit Code Review with a specific focus on its Jenkins CI integration.
See and learn how to improve your Agile application lifecycle management by making your builds more stable and your development more under control.
Gerrit Code Review allows developers to share ideas and get collective ownership of the project design and code-style.
Let’s imagine a perfect release of feature(s)? What development process is needed? How organize life-cycle stages in terms of decision-making points? How to reduce risks and bottle necks impact? What about the team properties? What can you change in own project or product right now?
I will try to answer for all these questions. All answers based on my long-year development (sometimes rapid :) experience of complex fintech projects/products.
Баба-Яга против! — Роман Дворнов, Ostrovok.ruYandex
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Ladutko - Gamification in Quality AssuranceAndrey Ladutko
Presentation from SQA Days-12 in Minsk (01 Dec 2012) about gamification and applying it - 3 examples: Windows 7 Language Quality Game, Code Review Game, Stackoverflow
Петрова Ксения - Data mining на практике - dmlabs.orgWG_ Events
В своем докладе Ксения рассказала об основных ошибках в Data Minning и как их избежать. Она объяснла, как выглядит цикл по решению задач в анализе данных и почему задачи нельзя решить "в лоб".
Presentation from Agile Base Camp 2 conference (Kiev, May 2010) and AgileDays'11 (Moscow, March 2011) about one of the most useful engineering practices from XP world.
TDD style proved itself as very reliable and quick way of business tasks solving with code. But most of examples on trainings and in the internet show how to apply TDD to simple input/output code or interface based dependencies with mocking techniques. What about other areas of application development like database related code? Could it be developed with TDD style? What does TDD bring to developer? I will try to answer these questions in my talk and show on practical examples how helpful TDD is for database code, how it reduces risks and opens the door for refactoring techniques.
How to successfully grow a code review cultureNina Zakharenko
As a team grows, code ownership is distributed. Code review becomes increasingly important to support the maintainability of complex codebases. An effective code base is on that can be worked on collaboratively by a team.
In this talk we'll discuss how to introduce a successful code review culture to your development team that will foster the idea of shared ownership. This in turn will result in a happy and healthy code base.
https://webexpo.net/prague2016/talk/how-to-successfully-grow-a-code-review-culture/
Overview of Gerrit Code Review with a specific focus on its Jenkins CI integration.
See and learn how to improve your Agile application lifecycle management by making your builds more stable and your development more under control.
Gerrit Code Review allows developers to share ideas and get collective ownership of the project design and code-style.
Let’s imagine a perfect release of feature(s)? What development process is needed? How organize life-cycle stages in terms of decision-making points? How to reduce risks and bottle necks impact? What about the team properties? What can you change in own project or product right now?
I will try to answer for all these questions. All answers based on my long-year development (sometimes rapid :) experience of complex fintech projects/products.
Баба-Яга против! — Роман Дворнов, Ostrovok.ruYandex
В последнее время во фронтенде появляется столько нового и внедряется настолько быстро, что не все успевают осознать последствия. Хорошо это или плохо? Рассмотрим некоторые новинки с точки зрения «за», а главное – «против».
Ladutko - Gamification in Quality AssuranceAndrey Ladutko
Presentation from SQA Days-12 in Minsk (01 Dec 2012) about gamification and applying it - 3 examples: Windows 7 Language Quality Game, Code Review Game, Stackoverflow
Петрова Ксения - Data mining на практике - dmlabs.orgWG_ Events
В своем докладе Ксения рассказала об основных ошибках в Data Minning и как их избежать. Она объяснла, как выглядит цикл по решению задач в анализе данных и почему задачи нельзя решить "в лоб".
Similar to Социология Code Review или что делать, елси ваши тестировщики начали писать тесты (16)
Story Testing Approach for Enterprise Applications using Selenium FrameworkOleksiy Rezchykov
Releasing a big software product frequently on the same high quality level could became an impossible task. Story Testing approach gives a possibility for many teams to work for a same product and release it without putting enormous efforts on testing. Approach is based on the BDD technique, Feature Flags and Selenium.
Story Testing Approach for Enterprise Applications using Selenium Framework
Социология 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
14. Composition or
Inheritance
Наследование не используется совсем
Наследование используется там где стоит
использовать композицию
@twincengray #xpdays
14
15. Строковые
преобразования
Особенности реализации строк в языке
программирования
Строковые литералы/константы
Манипуляции по строками
@twincengray #xpdays
15
26. Что делать со всем этим
кодом?
@twincengray #xpdays
26
27. Checklist от КО
Посмотреть мою прошлую презентацию
Не оставляйте без присмотра
Добавлять фичи
Добавлять тесты фич
Постоянно рефакторить
@twincengray #xpdays
27
34. Итог
Роли на проектах все больше смешиваются
Автоматизации становится необходимой
Не отделяйте код тестов от проектного кода
Постоянно совершенствуйте свои тесты
Тестировщики и разработчики
обменивайтесь знаниями и опытом
То чем мы занимаемся - командная игра
@twincengray #xpdays
34
Спасибо что досидели.Трудно идти первым и трудно идти последнимСегодня я хотел бы опять поговорить об инспекции кода или о 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.У этих тестов совершенно разное назначение. Стоит добавить дополнительные проверки в тесты модулей на которые повиляла данная новая функциональность.
СимптомыТесты становятся мусорной свалкой (трудно понять что внутри)Тесты работают часамиВ итоге их больше никто не запускает
То о чем уже говорил, но хотел бы повторить в завершении.Некоторые вещи звучат цитатами КО, но от этого им чаще не следуют…