Хотелось бы проконсультироваться у общественности на тему тестов, проводимых самими программистами по ходу работу над заданиями.
Исходная ситуация: на данный момент, после выполнения задания программист должен провести тесты, которые бы доказывали, что он выполнил задание именно так, как надо. Выполненные тесты документируются и прикрепляются к задаче (есть своя система task management'а). В силу, скажем так, особенностей проектирования и реализации приложения, тесты, которые может провест программист, относятся к категории функциональных/интеграционных (проводить unit tests невозможно). Другими словами, чтобы протестировать правильность выполнения надо собрать и запустить приложение и проверить, как оно там живет. Тем не менее, при таком подходе количество ошибок, которые программисты вносят в другие части кода, не уменьшается .
Почитав умные книги и погуглив, я пришел к выводу, что:
— под developer testing понимаются, по большей части, unit tests
— нагружать программиста интеграционным и функциональными тестами смысла нет (в силу ряда причин, хорошо описанных, например, в "Code Complete" 2nd), т.к. качество это сильно не повысит (не программисткое это дело), а времени и нервов займет больше.
Собственно, вопросы:
— Я правильно понимаю суть developer testing? Или есть положительный опыт выполнения программистами дополнительных тестов?
— Я правильно понимаю, что разработкой интеграционных/функциональных тестов должны заниматься отдельные люди (риторический вопрос, но все же)?
Я (девелопер) часто начинаю с написания интеграционных тестов, потом быстренько их озеленяю, потом привожу в порядок код. В идеале, в процессе рефакторинга пишу юнит тесты, но часто лень. Но я фрилансер, я сам себе и архитектор, и QA.
Интеграционные тесты -- в смысле, они задействуют тестовую базу (или вообще ее не трогают), не отправляют писем и т.д. Функциональных тестов я не пишу.
Под developer tests понимаются тесты, предполагающие знание внутренней работы системы. Например, проверить, что такой-то метод с такими-то параметрами возвращает такое-то значение. Такие тесты не имеют business value, и нужны только самим программистам. Другое дело -- тесты, которые проверяют поведение системы и прямо завязаны на клиентские истории. Они тоже могут быть юнит тестами (см BDD), но тестируют не конкретный метод конкретного класса, а работу системы в конкретном контексте. Тогда можно менять реализацию при сохранении существующей функциональности, и девелоперские тесты упадут, а клиентские останутся.
Если же проводить юнит тесты невозможно, целесообразно изменить дизайн приложения (глубокая мудрость, к которой программистский мир идет уже который десяток лет).
ulu
Здравствуйте, npe, Вы писали:
npe>День добрый,
npe>Хотелось бы проконсультироваться у общественности на тему тестов, проводимых самими программистами по ходу работу над заданиями.
npe>Исходная ситуация: на данный момент, после выполнения задания программист должен провести тесты, которые бы доказывали, что он выполнил задание именно так, как надо. Выполненные тесты документируются и прикрепляются к задаче (есть своя система task management'а). В силу, скажем так, особенностей проектирования и реализации приложения, тесты, которые может провест программист, относятся к категории функциональных/интеграционных (проводить unit tests невозможно). Другими словами, чтобы протестировать правильность выполнения надо собрать и запустить приложение и проверить, как оно там живет. Тем не менее, при таком подходе количество ошибок, которые программисты вносят в другие части кода, не уменьшается .
npe>Почитав умные книги и погуглив, я пришел к выводу, что:
npe>- под developer testing понимаются, по большей части, unit tests npe>- нагружать программиста интеграционным и функциональными тестами смысла нет (в силу ряда причин, хорошо описанных, например, в "Code Complete" 2nd), т.к. качество это сильно не повысит (не программисткое это дело), а времени и нервов займет больше.
npe>Собственно, вопросы:
npe>- Я правильно понимаю суть developer testing? Или есть положительный опыт выполнения программистами дополнительных тестов? npe>- Я правильно понимаю, что разработкой интеграционных/функциональных тестов должны заниматься отдельные люди (риторический вопрос, но все же)?
npe>Заранее спасибо. npe>--- npe>npe
> Исходная ситуация: на данный момент, после выполнения задания программист должен провести тесты, которые бы доказывали, что он выполнил задание именно так, как надо. Выполненные тесты документируются и прикрепляются к задаче (есть своя система task management'а). В силу, скажем так, особенностей проектирования и реализации приложения, тесты, которые может провест программист, относятся к категории функциональных/интеграционных (проводить unit tests невозможно). Другими словами, чтобы протестировать правильность выполнения надо собрать и запус�
�ить приложение и проверить, как оно там живет. Тем не менее, при таком подходе количество ошибок, которые программисты вносят в другие части кода, не уменьшается . > > Почитав умные книги и погуглив, я пришел к выводу, что: > > — под developer testing понимаются, по большей части, unit tests > — нагружать программиста интеграционным и функциональными тестами смысла нет (в силу ряда причин, хорошо описанных, например, в "Code Complete" 2nd), т.к. качество это сильно не повысит (не программисткое это дело), а времени и нервов займет больше. > > Собственно, вопросы: > > — Я правильно понимаю суть developer testing? Или есть положительный опыт выполнения программистами дополнительных тестов? > — Я правильно понимаю, что разработкой интеграционных/функциональных тестов должны заниматься отдельные люди (риторический вопрос, но все же)?
Разработчики пишут все тесты, и модульные (unit tests) и интеграционные.
При определенной сноровке можно (и нужно) писать также и автоматические
функциональные тесты.
Те программисты которые занимаются реализацией новой функциональности
или исправлением дефектов также должны писать модульные тесты.
Заставлять писать тесты (не принимать выполненое задание если нет
тестов) я считаю неразумным. Я полагаю лучше измерять степень покрытия
тестами, и требовать от комманды удержания этой метрики на высоком
уровне. Как они будут этого добиваться пусть решают сами. Таким образом
они будут оказывать друг на друга давление с тем, чтобы код был покрыт
тестами на нужном уровне.
Кто будет писать интеграционные тесты пусть решает технический лидер
команды.
Автоматические функциональные тесты (такие тесты, которые поднимаю
систему целиком, и проверяют как она работает с точки зрения
пользователя) — это открытый вопрос. С одной стороны это вроде бы задача
отдела контроля качества, с другой стороны сделать систему пригодной для
автоматического функционального тестирования может только главный
архитектор.
Здравствуйте, npe, Вы писали:
npe>Почитав умные книги и погуглив, я пришел к выводу, что:
npe>- под developer testing понимаются, по большей части, unit tests npe>- нагружать программиста интеграционным и функциональными тестами смысла нет (в силу ряда причин, хорошо описанных, например, в "Code Complete" 2nd), т.к. качество это сильно не повысит (не программисткое это дело), а времени и нервов займет больше.
npe>Собственно, вопросы:
npe>- Я правильно понимаю суть developer testing? Или есть положительный опыт выполнения программистами дополнительных тестов?
Примерно так это обычно и понимается, но всё зависит от специфики конкретной разрабатываемой системы, от сложности тестирования.
npe>- Я правильно понимаю, что разработкой интеграционных/функциональных тестов должны заниматься отдельные люди (риторический вопрос, но все же)?
Давайте лучше посмотрим, на какие уровни абстракции можно разбить тестируемую систему, чтобы понять, кому на этом уровне можно доверить тестирование.
Можно выделить 3 основных уровня:
1) Уровень ядра — уровень, на котором каждый компонент представляет некоторую атомарную часть движка и не соответствует бизнес-функционалу, не инкапсулирует его. На этом уровне код покрывается юнит-тестами и этим занимаются именно разработчики, так как только они с нужном объеме понимают специфику того или иного тестируемого модуля на данном уровне
2) Уровень реализации кода, соответствующего бизнес-функционалу — на данном уровне все программные компоненты уже отражают бизнес-логику системы. В идеале это фактически полнофункциональная система, к которой только UI не прикрутили. На этом уровне тесты разрабатывают по-прежнему программисты, но часть задач может быть делегирована отдельной команде, которая занимается автоматизацией тестирования. Например, отдельным автоматизаторам можно делегировать тестирование модулей, к которым можно достучаться извне тестируемой системы. Например, веб-сервисы, ряд проверок баз данных, возможно, какие-то вспомогательные утилиты, которым что-то передается на вход и что-то выводится в какой-то поток.
3) Уровень UI — обычно на этот уровень разработчики не лезут, так как своих задач полно. Тут нужна отдельная команда. Но на этом уровне разработчики могут помочь команде, которая занимается автоматизацией. В частности можно оговорить, на какие объекты наложить определенные атрибуты, чтобы систему можно было легче тестировать автоматически.
Да, еще можно ввести нулевой уровень — уровень сборки. Кстати, это дело автоматизировать имеет смысл в первую очередь. Во-первых и отдача будет достаточно быстрой, да и автосборка — это основа для автоматизированного конвейера, на входе которого только ссылки на хранилище файлов проекта, а на выходе — собранный и протестированный продукт с выдачей всех необходимых метрик, как покрытие кода, мера соответствия поведения системы заявленным требованиям ( % успешно пройденных тестов, как самая грубая оценка ) и прочее.
OS>Я полагаю лучше измерять степень покрытия OS>тестами, и требовать от комманды удержания этой метрики на высоком OS>уровне. Как они будут этого добиваться пусть решают сами. Таким образом OS>они будут оказывать друг на друга давление с тем, чтобы код был покрыт OS>тестами на нужном уровне.
У вас есть положительный опыт при использовании этой метрики? Я имею в виду, что она реально помогла повысила качество выполнения заданий. Допустим, упала плотность ошибок или что-то в этом роде. Диспутов на тему полезности/бесполезности расчета степени покрытия я читал массу, хотелось бы послушать "истории из жизни" .
OS>Кто будет писать интеграционные тесты пусть решает технический лидер OS>команды.
Но такие тесты должна писать отдельная команда, пусть даже выделенная из состава разработчиков? Мне думается именно так. Ведь, по сути, что модульные, что интеграционные, что функциональные тесты — это почти самостоятельные под-проекты. Заниматься ими время от времени (например, ближе к концу релиза) смысла большого нет (это уже из моего опыта).
OS>Автоматические функциональные тесты (такие тесты, которые поднимаю OS>систему целиком, и проверяют как она работает с точки зрения OS>пользователя) — это открытый вопрос. С одной стороны это вроде бы задача OS>отдела контроля качества, с другой стороны сделать систему пригодной для OS>автоматического функционального тестирования может только главный OS>архитектор.
M>Давайте лучше посмотрим, на какие уровни абстракции можно разбить тестируемую систему, чтобы понять, кому на этом уровне можно доверить тестирование. M>Можно выделить 3 основных уровня:
Спасибо за выделение уровней. Поможет при задушевных беседах с заказчиком.
> У вас есть положительный опыт при использовании этой метрики? Я имею в виду, что она реально помогла повысила качество выполнения заданий. Допустим, упала плотность ошибок или что-то в этом роде. Диспутов на тему полезности/бесполезности расчета степени покрытия я читал массу, хотелось бы послушать "истории из жизни" .
Увы, такого опыта нет. Я либо был рядовым разработчиком в проекте, и мне
было не важна эта метрика, я за ней не следил. Либо вел проекты без
модульного тестирования вообще, либо тесты охватывали всё (реально думаю
было близко к 85-90%).
> Но такие тесты должна писать отдельная команда, пусть даже выделенная из состава разработчиков? Мне думается именно так. Ведь, по сути, что модульные, что интеграционные, что функциональные тесты — это почти самостоятельные под-проекты. Заниматься ими время от времени (например, ближе к концу релиза) смысла большого нет (это уже из моего опыта).
У меня другое мнение на этот счет. Интеграционные тесты должен писать
кто-то сильно интегрированный в комманду разработчиков. Такие тесты
нужно исправлять при каждом изменении архитектуры (вывели часть
функциональности в отдельный модуль — добавили тесты проверяющие
сопряжение этого модуля со всеми остальными, упростили какой-либо модуль
— убрали тесты, добавили зависимость одного модуля от другого — добавили
тесты...). Понятно, что разработчикам придется и самим кое-где править
такие тесты (переименование методов, изменение сигнатур), но им, когда
они работают над функциональностью, чужды задачи интеграционного
тестирования. Поэтому решать сколько и каких интеграционных тестов
необходимо, должен архитектор, техлид или ведущий разработчик.
И кстати, не для всякой системы есть необходимость в интеграционных
тестах. Только для модульных систем.
> OS>Автоматические функциональные тесты (такие тесты, которые поднимаю > OS>систему целиком, и проверяют как она работает с точки зрения > OS>пользователя) — это открытый вопрос. С одной стороны это вроде бы задача > OS>отдела контроля качества, с другой стороны сделать систему пригодной для > OS>автоматического функционального тестирования может только главный > OS>архитектор. > > Ага... А если его нет? (риторический вопрос...).
Главный архитектор есть всегда. Если есть какая-то система, то ее кто-то
построил, и он-то и есть главный архитектор, как бы его не называли.
Здравствуйте, npe, Вы писали:
npe>Но такие тесты должна писать отдельная команда, пусть даже выделенная из состава разработчиков? Мне думается именно так. Ведь, по сути, что модульные, что интеграционные, что функциональные тесты — это почти самостоятельные под-проекты. Заниматься ими время от времени (например, ближе к концу релиза) смысла большого нет (это уже из моего опыта).
Есть тесты и есть тесты. Функциональные тесты разработчиков — это не самостоятельные подпроекты, это часть процесса разработки. Заниматься ими после разработки — трата дорогого времени разработчика. Посмотрите в сторону Test-driven development. Разработчик пишет unit-тесты, пишет стаб класса и его методов. Прогоняет unit-тесты. Все тесты фейлят(если тест проходит на стабе, это плохой тест). Разработчик пишет и правит реализацию, до тех пор пока все тесты не пройдут.
Можно ли считать такие тесты тестированием? Нет. Приведу простой пример из книжки Бейзера "Тестирование черного ящика":
нужно написать метод вычисления функции y=x^2;
разработчик написал такой юнит-тест: assert(y(2)==4);
в реализацию вкралась ошибка, вместо y=x^2 получилось y=2*x;
Юнит-тест проходит, а метод реализован неправильно. Кто виноват? Виноват PM, который не выделил команду тестировщиков. Тестировщики тестируют совсем иначе. Правильный тестировщик разобьет входные данные на классы эквивалентности, например [-2;0;2], и обязательно обнаружит такую ошибку на одном из тестов, в данном случае 2 из 3-х зафейлят.
Классы эквивалентности — лишь одна из техник, ваши разработчики знакомы с теорией тестирования? Вряд ли. Потому что они не должны быть с ней знакомы.
Вывод: разработчики должны писать юнит-тесты, они избавят от глупых ошибок и траты времени группы тестирования на ошибки типа "метод падает при любом вызове"; группа тестирования должна быть и должна писать свои тесты, функциональные/интеграционные и все какие понадобятся; ожидать, что юнит-тесты разработчиков хоть как-то повлияют на качество ошибочно — хороший разработчик и без тестов делает мало ошибок, плохому тесты не помогут.
V>Правильный тестировщик разобьет входные данные на классы эквивалентности, например [-2;0;2], и обязательно обнаружит такую ошибку на одном из тестов, в данном случае 2 из 3-х зафейлят.
V>Вывод: разработчики должны писать юнит-тесты, они избавят от глупых ошибок и траты времени группы тестирования на ошибки типа "метод падает при любом вызове"; группа тестирования должна быть и должна писать свои тесты, функциональные/интеграционные и все какие понадобятся; ожидать, что юнит-тесты разработчиков хоть как-то повлияют на качество ошибочно — хороший разработчик и без тестов делает мало ошибок, плохому тесты не помогут.
Полностью согласен. Соответствует моему опыту и текущему положению дел в проекте. Не в том смысле, что дела именно так и обстоят, а в том, что они идут с точностью до наоборот и последствия расцветают пышным цветом...
Здравствуйте, vnfedotov, Вы писали:
V> ожидать, что юнит-тесты разработчиков хоть как-то повлияют на качество ошибочно — хороший разработчик и без тестов делает мало ошибок, плохому тесты не помогут.
Вообще-то, суть TDD как раз и заключается, что юнит тесты очень даже положительно влияют на качество. И не только потому, что хороший разработчик сделает еще меньше (по статистике, в 5-10 раз) ошибок. Тесты помогают (иногда вынуждают) улучшить дизайн приложения, это признают даже лучшие из разработчиков.
Здравствуйте, ulu, Вы писали:
ulu>Вообще-то, суть TDD как раз и заключается, что юнит тесты очень даже положительно влияют на качество. И не только потому, что хороший разработчик сделает еще меньше (по статистике, в 5-10 раз) ошибок. Тесты помогают (иногда вынуждают) улучшить дизайн приложения, это признают даже лучшие из разработчиков.
увы, вы ошибаетесь. Связь применения TDD и качества готового продукта исследовалась неоднократно и достоверно обнаружена так и не была.
Думаю стоит поискать связь между качеством продукта версии №3 в проектах
с TDD и non-TDD.
Реализовать метод X написав предварительно тест, и просто реализовать
метод X и проверить — это примерно одно и то же. А вот внести в метод X
изменения при наличии и отсутствии тестов (покрывающих всю систему) это
далеко не одно и то же.
Здравствуйте, vnfedotov, Вы писали:
V>Здравствуйте, ulu, Вы писали:
ulu>>Вообще-то, суть TDD как раз и заключается, что юнит тесты очень даже положительно влияют на качество. И не только потому, что хороший разработчик сделает еще меньше (по статистике, в 5-10 раз) ошибок. Тесты помогают (иногда вынуждают) улучшить дизайн приложения, это признают даже лучшие из разработчиков.
V>увы, вы ошибаетесь. Связь применения TDD и качества готового продукта исследовалась неоднократно и достоверно обнаружена так и не была.
Хмм.. неубедительно, 24 студента трудились над олимпиадными задачками, не имея, судя по всему, большого опыта применения TDD. К тому же, насколько я понял, авторы исследования (и сами студенты) не знают разницы между TDD и Test First.
По другую сторону баррикад, не говоря уже об очень уважаемых (это субъективно) людях, исследования Microsoft и IBM, проводимые с реальными командами разработчиков, работающих над реальными продуктами. Вот ссылка.
Здравствуйте, npe, Вы писали:
M>>Давайте лучше посмотрим, на какие уровни абстракции можно разбить тестируемую систему, чтобы понять, кому на этом уровне можно доверить тестирование. M>>Можно выделить 3 основных уровня:
npe>Спасибо за выделение уровней. Поможет при задушевных беседах с заказчиком.
Кстати, чуть-чуть в сторону от темы, но такой более высокоуровневый взгляд на вопрос автоматизации вот тут:
M>Кстати, чуть-чуть в сторону от темы, но такой более высокоуровневый взгляд на вопрос автоматизации вот тут:
M>здесь и M>здесь
Спасибо . Эта тема у нас тоже очень актуальна. "Борьба за качество" началась именно с внедрения автоматизированных тестов. Причем, абсолютно без учета прошлого негативного опыта в этом деле.
Поделился ссылками с сотрудником, отвечающим за разработку софта и попутно за автоматизацию тестов по этому софту. Демотивирующий эффект на лицо .
Здравствуйте, Marduk, Вы писали:
M>Давайте лучше посмотрим, на какие уровни абстракции можно разбить тестируемую систему, чтобы понять, кому на этом уровне можно доверить тестирование. M>Можно выделить 3 основных уровня:
Ок. Если представить себе вполне обыденную ситуацию: в приложении трудно выделить эти уровни. Точнее, скажем так, выделить-то можно (с сильными размываниями границ), но, вот, организовать модульное и интеграционное тестирование этих уровней — невозможно. Ну, спроектировано приложение так .
Теперь начинается поддержка приложения: копятся баги + change requests, организуются релизы и т.п. Разумеется, при исправлении багов и выполнении change requests добавляются новые ошибки. Как правило (делал анализ), причиной тому:
— невнимательность при выполнении задания.
— недостаточно тщательное функциональное тестирование выполненного задания программистом (программист может только выполнить функциональные тесты)
Была идея, что невнимательность можно компенсировать developer testing. Практика показала, что программисты недостаточно хорошо проектируют и документируют тесты. В принципе, я это ожидал и умные книги про это предупреждают...
Теперь, как говорится, внимание вопрос. В этой ситуации, когда заказчик не хочет переделки приложения и выделения отдельной команды тестеров, мне на ум приходят только 2 вещи:
— организация code review (выполненного задания и проведенных тестов);
— повышение квалификации разработчиков в области тестирования до минимально приемлемого уровня (чтобы, хоть, мнимально необходимое количество test cases могли прикинуть).
Есть ли еще какие-нибудь подходы? Может, чего упускаю?
Здравствуйте, npe, Вы писали:
npe>Здравствуйте, Marduk, Вы писали:
M>>Давайте лучше посмотрим, на какие уровни абстракции можно разбить тестируемую систему, чтобы понять, кому на этом уровне можно доверить тестирование. M>>Можно выделить 3 основных уровня:
npe>Ок. Если представить себе вполне обыденную ситуацию: в приложении трудно выделить эти уровни. Точнее, скажем так, выделить-то можно (с сильными размываниями границ), но, вот, организовать модульное и интеграционное тестирование этих уровней — невозможно. Ну, спроектировано приложение так .
npe>Теперь начинается поддержка приложения: копятся баги + change requests, организуются релизы и т.п. Разумеется, при исправлении багов и выполнении change requests добавляются новые ошибки. Как правило (делал анализ), причиной тому:
npe>- невнимательность при выполнении задания. npe>- недостаточно тщательное функциональное тестирование выполненного задания программистом (программист может только выполнить функциональные тесты)
npe>Была идея, что невнимательность можно компенсировать developer testing. Практика показала, что программисты недостаточно хорошо проектируют и документируют тесты. В принципе, я это ожидал и умные книги про это предупреждают...
npe>Теперь, как говорится, внимание вопрос. В этой ситуации, когда заказчик не хочет переделки приложения и выделения отдельной команды тестеров, мне на ум приходят только 2 вещи:
npe>- организация code review (выполненного задания и проведенных тестов);
Да, это нужно. Причем, если код-ревью перекрестное, то выполняется еще и задача обмена информации между разработчиками. Например, кто-то не знает, что некоторый функционал уже написан и использует самоделки, а ревьюер может порекомендовать то решение, которое уже есть.
npe>- повышение квалификации разработчиков в области тестирования до минимально приемлемого уровня (чтобы, хоть, мнимально необходимое количество test cases могли прикинуть).
npe>Есть ли еще какие-нибудь подходы? Может, чего упускаю? npe>Спасибо...
Я бы еще подумал над тем, чтобы тестирование интенсивно выдавало результаты. То есть, не так что решили разработчики когда-нибудь прогнать тесты, тогда их и запустили, а сделать так, чтобы эти тесты бегались постоянно (возможно на отдельной машине). Как только появятся изменения, из-за которых что-то перестает работать как надо, вы узнаете об этом достаточно быстро (не позднее времени полного прогона тестов).
Здравствуйте, npe, Вы писали:
M>>Кстати, чуть-чуть в сторону от темы, но такой более высокоуровневый взгляд на вопрос автоматизации вот тут:
M>>здесь и M>>здесь
npe>Спасибо . Эта тема у нас тоже очень актуальна. "Борьба за качество" началась именно с внедрения автоматизированных тестов. Причем, абсолютно без учета прошлого негативного опыта в этом деле.
npe>Поделился ссылками с сотрудником, отвечающим за разработку софта и попутно за автоматизацию тестов по этому софту. Демотивирующий эффект на лицо .
На самом деле очень много определяет постановка задачи. Если будет гонка за тестовым покрытием кода, то на какой-то стадии вся автоматизация просто рухнет.
А вот если рассматривать автоматизацию тестирования как средство оптимизации затрат на тестирование, в т.ч. за счет делегирования рутинных и объемных задач машине, то вот тут вполне можно преуспеть. То есть, имеет смысл определить, есть ли при тестировании такие задачи, а они наверняка есть. Та же сборка системы, та же инсталляция. Если используются базы данных, то заготовка некоторой модельной базы (а это служит хорошей основой для тестирования), импорт/експорт и т.п.
В тех ссылках ,что я привел просто выделены уровни, которые имеет смысл рассматривать и в какой последовательности их рассматривать.
Здравствуйте, ulu, Вы писали:
ulu>По другую сторону баррикад, не говоря уже об очень уважаемых (это субъективно) людях, исследования Microsoft и IBM, проводимые с реальными командами разработчиков, работающих над реальными продуктами. Вот ссылка.
Очень любопытно, первая статья утверждает, что плотность дефектов уменьшается вместе с покрытием кода тестами Или я чего-то не понял, или это революция.
Вторая, компилирующая результаты других исследований, обыденно подтверждает, что профит был только в половине случаев. Т.е. эффективность в плане качества сильно зависит от типа выполняемого проекта, уровня команды итд.
.
Или я чего-то не понял, или это революция.