четверг, 3 января 2008 г.

Обеспечение качества. Контроль качества. Тестирование

Добрый день, Рад, что наконец смогу поделиться со всеми, тем что давно уже изучаю, исследую и обдумываю. А именно это вопрос определений Обеспечение качества (Quality Assurance), Контроль качества (Quality Control), Тестирование ПО (Software Testing). Казалось бы все просто и ясно, но на самом деле эти понятия связаны между собой, переплетены и запутаны. И как оказывается, нет единого мнения о том, что они представляют из себя.


В течении недели я проводил небольшой опрос среди своих коллег, занимающих разные позиции в разных компаниях, связанных и не связанных с тестированием и обеспечением качества и разработкой ПО. Было опрошено 15 человек: 3 тест менеджера, 1 руководитель группы тестирования, 2 ведущих тестировщика, 6 тестировщиков, 2 разработчика, 1 человек не имеющий отношения к разработке и тестированию вообще. Цифра конечно не большая, но уже из нее видно, что более менее адекватное и правильное определение этих понятий имеют не более половины опрошенных, что само по себе ужасно. Получается что половина опрошенных не понимают что такое качество, и как его достигать, а так как в основном отвечали на вопросы люди отвечающие за качество, то получается, что половина из них не до конца понимает, чем занимается.

Можно долго исследовать почему это происходит, от себя могу сказать, что основные причины:
1. недостаток структур, обучающих тестировщиков
2. большинство коммерческих структур обучают лишь практической стороне вопроса, не затрагивая теорию
3. персонал обучающий тестировщиков сам зачастую оказывается слабо квалифицированным

Не буду вдаваться в подробности темы обучения тестировщиков, так как она часто поднимается и уже, я думаю, что достаточно раскрыта. Речь идет о понятих Обеспечение качества (Quality Assurance), Контроль качества (Quality Control), Тестирование ПО (Software Testing).

До проведения опроса мое понимание данных определений было следущим:
Тестирование (Testing) - совокупность действий проводимых над объектом тестирования, а именно применение различных видов тестирования, для получения результата о его соответствии поставленным требованиям.
Контроль качества (Quality Control) - совокупность мероприятий проводимых в процессе разработки, для постоянного получения исчерпывающей информации о соответствии объекта тестирования поставленным требованиям. Сюда входят Test Management, Test Analysis, Test Design, Testing and etc.
Обеспечение качества (Quality Assurance) - совокупность мероприятий, охватывающих все подразделения компании, предпринимаемых на разных стадиях разработки, для улучшения качества выпускаемого продукта. Сюда входят, оптимизация имеющихся процессов: бизнес-анализа, проектирования, разработки, тестирования и т.п.

Но, проанализировав все полученные ответы, а также посоветовавшись с авторитентными людьми, я пришел к выводу, что понятие тестирования, представленное выше, слишком узко и сводится к банальному исполнению тестов (Test Execution). Немного переосмыслив могу резюмировать следующее:

QA (Quality Assurance, Обеспечение качества) - совокупность мероприятий, охватывающих все технологические этапы разработки, выпуска и эксплуатации ПО информационных систем, предпринимаемых на разных стадиях жизненного цикла ПО, для обеспечения качества выпускаемого продукта.
QC (Quality Control, Контроль качества) - совокупность действий проводимых над объектом тестирования в процессе разработки для получения информации об актуальном состоянии объекта тестирования в разрезах: "готовность Продукта к выпуску", "Соответствие зафиксированным требованиям", "Соответствие заявленному уровню качества продукта".
Software Testing является одной из техник контроля качества и включает в себя активности по планированию работ (Test Management), проектированию тестов (Test Design), выполнению тестирования (Test Execution) и анализу полученных результатов (Test Analysis).

Причем, разница между понятиями видна сразу и не требует дополнительных разъяснений.

Как все мы знаем: "Истина где-то рядом." Поэтому буду рад получить от вас комментарии и дополнения, которые приблизят нас еще на один шаг к правде о том, чем мы всетаки занимаемся. И кто знает, может нас ждет еще одна статья, в которой придется дополнить сделанные выводы.

Большое спасибо, всем, кто участвовал в опросе, а так же отдельное спасибо, Славе Панкратову, за качественные комментарии к предыдущей статье о разнице между QA, QC, Testing, которые сподвигли меня к проведению опроса и написанию этого материала.

Оригиналы ответов на опрос о разнице между Quality Assurance, Quality Control и Testing, можно найти здесь

5 комментариев:

Анонимный комментирует...

Алексей

я прочитал обе статьи. Считаю что данные определения вполне пригодны. Хороший шаг для определения собственой "системы координат", в отношение которой в дальнейшем можно строить теории или практики. Мне кажется, что нельзя дать единственно правильного и неоспоримого определения для этих терминов. Почему? Приведу аналогию с физическими системами измерений. Нельзя сказать, что измерять длину в метрах правильно, а в дюймах нет. И даже если вдруг получится сформулировать "идеальное" определение того что такое тестирование, QA итд., вовсе не факт, что оно будет принято и пониматься всеми одинаково.
Подавляющее большинство людей работающих в ИТ считают, что QA==Testing. Это все-равно, что говорить что системный архитектор и программист - одно и тоже. Еще это показатель общей безграмотности кадров, работающих в ИТ. Причем такие люди зачастую занимают руководящие посты в разных компаниях. Ужас. Так что проблемы с образованием не только в области обеспечения качества.

Мое мнение, что та или иная специализация, может характеризоваться обязанностями и действиями. Но, к сожалению, а может быть и к счастью, в области обеспечения качества некоторые активности могут относится к нескольким специализациям. Например, такая активность, как планирование тестирования, может быть как частью тестирования(IEEE Std 829 - Test Plan), так и частью QA(IEEE Std 730 - Software QA Plan). Но есть и такие, которые нельзя попутать, например, формализацию процесса работы с дефект-трекером - к активностям тестирования отнести сложно.

Я полностью согласен с картинкой из первой статьи. Где QA включает QC включает Testing. Это логически понятно из самих названий. Рассуждения таковы: чтобы обеспечивать качество продукта, нужно постоянно контролировать это качество (например от билда к билду, от версии к версии). В свою очередь для того чтобы проконтролировать качество, нужно сделать какие-то акции, провести эксперименты.

Теперь попробую дать определения так, как я это вижу в своей "системе координат".

Обеспечение качества - совокупность мероприятий, сервисов и действий направленных на постоянное улучшение качества выпускаемого продукта путем улучшения процессов и систематического контроля как за соблюдением этих процессов так и за качеством выпускаемого продукта.

Контроль качества - систематические действия, направленные на определение текущего качества выпускаемого продукта, определение относительного изменения этого качества по отношению к предыдущему состоянию продукта и выявление тенденций в отношении улучшения или ухудшения качества в следующем состоянии продукта.

Тестирование - набор целенаправленных действий дающих понятие о текущем качестве продукта, подтверждающих то, что разрабатываемый продукт имеет заранее спланированное поведение и характеристики и не имеет незапланированных характеристик и поведения (т.е. дефектов).

Основные различия:
QA, это превентивные действия, попытка недопустить появление дефектов. Понижение рисков появления неисправностей.
Тестирование - действия направленые на поиск неисправностей которые уже допущены, либо подтверждение того, что их нет.
Контроль качества - действия направленные на оценку текущего состояния продукта. По сути близко к тетсированию. На практике редко (на моей памяти ни разу) выделяется отдельно от тестирования. Т.е. по результатм тестирования у нас есть данные - прошел тест или нет, найдены дефекты или нет. По результатам контроля качества, мы можем вынести вердикт о функциональности продукта - годна она к релизу или нет.

Как-то вот так.

Еще я склонен согласится с тем, что все три роли могут быть объеденены в одну. Хотя бы потому что я сейчас сижу на всех трех стульях - я тестирую (провожу эксперименты), я контролирую качество (оцениваю, что билд номер N - есть релиз, т.к. он удовлетворяет критериям) и обеспечиваю качество (формализую процессы, участвую в обсуждениях архитектуры проекта). Конечно, хотелось бы больше сосредоточиться на последних двух областях, но...

nikoden комментирует...

В целом я согласен и с материалом статьи, и с предыдущим комментарием.
Но у меня есть некоторые замечания, которые я и хочу изложить:
1. В определении QC, на мой взгляд,"готовность Продукта к выпуску" как раз и определяется на основании "Соответствия зафиксированным требованиям" и "Соответствия заявленному уровню качества продукта".
2. Не согласен с тем что Test Management есть планирование тестирования и является частью Testing. Планирование тестирования - это планирование тестирования, и ни что иное и в мировой практике зовется как Software Test Planning (STP). А Test Management - скорее часть QA поскольку включает и контроль качества самих тестов, и оценку достаточности покрытия тестами тестируемой области (соответствие тестплану), и контроль версий тестов, а также контроль документирования результатов тестирования (фиксирование статуса выполнения отдельно взятого теста).
3. Не согласен с формулировкой о том, что планирование тестирования "может быть" частью тестирования и частью QA. Скорее хошее планирование тестирования позволяет решить и задачи тестирования, и задачи QC и QA. Поясню. Тестплан, это не просто статический документ написанный один раз перед тем как начать тестирование и после этого благополучно забытый. К ранее написанным тестпланам возвращаешься и в процессе тестирования и после рализа. Пока тестирование не закончено, тестплан может изменяться.
Грамотно составленный тестплан позволяет:
- провести анализ дизайна продукта (в глобальном смысле, а не GUI) с точки зрения того что уже воплощено, что еще предстоит воплотить и какие проблемы возникли уже на данном этапе, при этом оценить вероятность появления изменений к требованиям и, по возможности, сами эти изменения, обсудить эти изменения с разработчиками и продуктменеджером (это нужно продолжать делать и тогда, когда тестирование уже идет полным ходом, давая новую пищу для анализа);
- оценить проектные риски с точки зрения качества в момент когда разработка уже начата, а значит когда уже появилась динамика рисков;
- определить интеграционные моменты смежных продуктов или компонентов которые требуется учесть при тестировании, а значит и методы и степень взаимодействия смежных подразделений внутри проекта и за его пределами;
- определить методы и подходы к тестированию;
- предъявить требования к минимальному покрытию тестами;
- предъявить требования к лабораторному оборудованию, необходимому для тестирования;
- определить критерии готовности продукта к выпуску, включая требования к уровню качества.
- определить сроки тестирования.
4. Далее, цитата: "QA, это превентивные действия, попытка недопустить появление дефектов." - Красиво и наивно. Попробуйте недопустить нашествие саранчи... Будьте готовы к тому, что дефекты так или иначе будут.
Скорее задача QA состоит в следующем:
- сократить разницу во времени между началом разработки и началом тестирования
- сократить время обнаружения дефектов
- сократить время исправления дефектов
- минимизировать количество ложных обнаружений дефектов и сократить время идентификации таких ложных дефектов
а в нескольких словах: сократить стоимость исправления дефектов (чем раньше дефект найден - тем дешевле он нам обошелся) и как следствие - суммарную стоимость проекта!
5. В больших и средних проектах разница между QC и Testing проявляется в том, что трекинг готовности продукта осуществляют не те кто его непосредственно тестирует, а их менеджеры, опираясь на отчеты о готовности отдельных фич, приемочного тестирования и прочие критерии готовности продукта, такие, например, как допустимый процент неисправленных дефектов, отсутствие дефектов блокирующих релиз.
6. Цитата: "Еще я склонен согласится с тем, что все три роли могут быть объеденены в одну." - Очень неблагодарное допущение. Точно так же как не стоит доверять контроль качества продукта программисту, не стоит доверять и контроль качества тестирования продукта инженеру, выполняющему тестирование. А в сколь-нибудь большом проекте это просто невозможно.

А еще, я не нашел явного упоминания об одной, жизненно важной для продукта роли QA, которую не осуществить средствами одного QC.
Это экспертная оценка продукта силами департамента QA или независимыми экспертами (хотя-бы бэта тестерами, но так или иначе квалифицированный департпмент QA принимает в этом участие с самого начала разработки).
Что имеется ввиду? - Неформальная оценка способности продукта решить те бизнес задачи, которые на него возлагает отдел маркетинга или заказчик.
Она на, мой взгляд, должна включать, как минимум:
- оценку качества технических требований к продукту и их соответствие бизнес требованиям (осуществляется до начала разработки);
- оценку способности продукта обеспечить те бизнес процессы потенциального покупателя или заказчика которые достаточны для того, чтоб продукт был востребованным и конкурентноспособным;
- оценку удобства использования продукта для целевой группы пользователей (равно как и оценку правильности выбора целевой группы).

А.Б. комментирует...

У каждого своя точка зрения на все на свете... Мы говорим практически об одних и тех же вещах, но почему-то вы перефразируете то о чем мы говорили до этого. А теперь по пунктам:

1. "готовность Продукта к выпуску" может и связана с "Соответствия зафиксированным требованиям" и "Соответствия заявленному уровню качества продукта", но это никак не одно и тоже, а одни из его составляющих.

2. Тест менеджмент и планирование это по существу одно и тоже, если включить в понятие планирования то что вы написали, а именно:
- контроль качества тестов,
- оценку достаточности покрытия тестами тестируемой области,
- контроль версий тестов,
- контроль документирования результатов тестирования
и т.д.
Все эти активности должны быть спланированы!!! А вот QA уже должно убедиться в том, что это было сделано :) Так что я упорно продолжаю разделять тест менеджмент и QA.

3. Ну если для вас тестинг это просто кликинг, то вы можете не включать планирование в него... А по поводу тест плана у меня вопросов нет и быть не может - это другая тема, которую можно начать в моей статье по планированию тестирования.

4. Вы говорите только о деньгах и дефектах, но QA смотрит на все намного шире. В круг ее обязанностей входят не только процессы связанные с разработкой и тестированием, но и взаимодействием между командами, планированием выполняемых работ, разработкой шаблонов и т.д. Точнее все, чтобы обеспечить качественное выполнение поставленных задач на всех уровнях.

5. Да не важно кто все это делает. В маленьких конторах есть 1 тестер, который и QC и QA одновременно. Да и вообще мы не конкретизируем здесь, а смотрим на вопрос в общем.

6. без комментариев, опять конкретика...

-----------
И теперь по поводу экспертной оценки.
Все что вы говорите подпадает под определенны виды тестирования:
- Requirements Testing
- Business Cycle Testing
- User Interface Testing / Usability Testing
А это уже тестирование, и значит тестировщики этим должны заниматься.

А по поводу экспертной оценки, хотите ее получить, наймите людей со стороны :)

Вот.

Спасибо за ваши комментарии.
Алексей.

nikoden комментирует...

Алексей, то что у каждого своя точка зрения - это абсолютно нормально :)
Благодаря этому QA и дает столь ценный результат.
Проблема не в том что "Мы говорим практически об одних и тех же вещах...", а в том что мы понимаем их по-разному. Многие могут похвастаться знанием формального RUP и бесконечно долго говорить о нем, но на практике у всех получаются разные результаты. Мое мнение таково, что уже время не просто обобщать теоретические знания, а анализировать и систематизировать практический опыт нарабатывая так называемые "Best Practices", которые позволили бы отобразить RUP на реальные проблемы, с которыми сталкиваются современные проекты.

Что же касается пунктов, возможно я был недостаточно точен опустив ряд пояснений которые считаю для себя сами собой разумеющимися.
Поэтому вернусь к пунктам еще раз:

1. Здесь я абсолютно того же мнения, но хотел подчеркнуть связь между составляющими, и именно такую, как я указал.

2. Боюсь, вы путаете разработку тестов с управлением тестами. На практике действительно разработку тестов называют частью планирования, с чем я в целом
не спорю. Но управление тестами - никогда. Это систематические мероприятия, которые суть - есть часть самого процесса контролируемого QA. Они неизменны и регулярны в рамках проекта, поэтому нет необходимости описывать их регламент в тестплане.
Достаточно их однажды регламентировать в документах описывающих ваш формальный процесс.
Иначе так, чего доброго, можно будет назвать все действия формального процесса частью планирования только потому, что они там упоминаются.

3. Здесь я имел ввиду как раз противоположное :) а именно, насколько важно планирование и для тестирования, и для QC, и для QA, и какие задачи оно решает именно для них. И уделил специально для для этого особое место перечислению этих задач, чтоб показать, насколько тесно они связаны в тестплане. Если принадлежность какой-либо задачи какому-то из понятий не очевидна -
это, возможно, мое упущение.

4. Может вам покажется странным, но это скорее я смотрю на задачу QA шире чем вы.
То, о чем говорите вы:
- взаимодействие между командами
- планирование выполняемых работ
- разработка шаблонов
- и многое-многое другое о чем еще можно упомянуть...
скорее точки воздействия на процесс для достижения конечной цели, но не сами цели.
Однако не зная конечной цели, вы не можете знать как нужно эффективно воздействовать на процесс.
Приглядитесь, все 3 пункта что вы назвали, так или иначе способны внести свой вклад в дело сокращения стоимости
исправления дефектов:
- взаимодействие между командами - быстрый и прозрачный обмен информацией, четкие формулировки, свободное и четко
регламентированное общение, минимум шума в информации позволят быстро идентифицировать дефекты и находить их причины
- планирование выполняемых работ - и так все ясно, планируйте наиболее трудоемкие и рискованные задачи на более ранние этапы, ставьте задачам на исправление критических дефектов максимальный приоритет, и т.д.
- разработка шаблонов - если речь идет о шаблонах документов - выносите место для наиболее важной информации вперед, предоставьте удобный способ описания деталей.
Так ваши воздействия приобретут направленный вектор подчиненный единой цели, что и обеспечит эффективность воздействия.
Есть такая поговорка: "О чем бы не говорилось - это всегда о деньгах". Возможно это и банально звучит, но бюджет коммерческого проекта не будет тратиться на то, что не помогает получить
прибыль или сэкономить деньги. поскольку коммерческие проекты тратят деньги на QA (и даже больше чем некоммерческие), то стоит предположить, что заслугу QA можно
оценить в денежном эквиваленте. Ответьте сначала на такие вопросы, прежде чем размышлять об этом дальше:
- Что в вашем понимании есть "качество" (самоцель или инструмент для достижения другой цели)? Если инструмент, то достижению какой цели он служит?
- Как вы измеряете качество в общем?
- Как вы оцениваете суммарную эффективность своих методов достижения качества?
Что, озадачил?...
Так вот, на Западе есть такое понятие: "Удельная Стоимость Дефекта". Чем раньше дефекты обнаруживаются и исправляются, тем затраты на их исправление меньше, а значит меньше и удельная стоимость этих затрат. Чем меньше удельная стоимость, тем эффективнее, считается, QA в проекте.
Как можно измерить затраты на исправление? - если дефект повлиял на сроки проекта, что повлекло дополнительные затраты на продление проекта, или, еще хуже, понизил имидж проекта будучи обнаруженным после релиза, что привело к потерям продаж,
то очевидно, что стоимость его исправления обошлась в эти дополнительные затраты и непредвиденные убытки; любой другой дефект обошелся в суммарные (и запланированные) человекочасы тех инженеров, которые были задействованы при его обнаружении и исправлении, чем они меньше - тем затраты меньше (и тем больше запланированных человекочасов у нас осталось для выполнения других задач проекта, в том числе, и не связанных с QC и QA вовсе). Как вы думаете, здесь связь с показателем успешности проекта в целом не прослеживается?...
Может это сразу и не очевидно, но связь между удельной стоимостью дефекта и эффективностью QA прямая.
Как? - примерно вот так:
Чего мы ждем от QA?
Качества выполнения всех этапов необходимых для получения конечного конкурентноспособного продукта в сроки, установленные проектным планом.
Что нам дает качество?
Гарантию того, что вероятность обнаружения недопустимых дефектов после релиза или сдвига сроков
релиза ввиду обнаружения недопустимых дефектов в предрелизный период будет минимальной.
Отсюда, чем меньше удельная стоимость дефекта, тем надежнее эта гарантия.
Зачем нам нужна такая гарантия?
Мы рассчитываем получить ожидаемую прибыль от продажи продукта и не получить неожиданных потерь этой прибыли.
По сути, это показатель успешности проекта.
Скажите, кто-нибудь станет заявлять что в успешном проекте неэффективный QA? - никогда.

5. В предыдущем комментарии зашла речь о том, что на практике Тестирование и QC совмещаются - я лишь отметил что на самом
деле все зависит от размеров департамента QA и в своей практике частенько наблюдал иное, о чем и написал.
А то, о чем говорите вы - это не совмещение в 1м тестере и QC и QA. Это полное отсутствие QA. Опять таки, исхожу из своего опыта и информации получаемой о QA в разных компаниях. Я частенько общаюсь с тестерами других компаний и знаю специфику
работы тестера-одиночки.

6. Тоже было высказывание в предыдущем комментарии. Я категорически не согласен что роль QC и QA можно совмещать.
Это не только вредно для QA, но еще и практически невозможно охватить одному человеку при грамотном QA. Это я тоже
заявляю исходя из своей практики.

---------
И по поводу экспертной оценки тоже...
Представьте, что бизнес требованием было создать ложку.
А конечным продуктом стал некий совершенно новый инструмент размером с обычный столовый прибор способный перемещать неоднородные жидкие среды любого объема в пространстве на любые расстояния с любой скоростью, но это не "ложка".
Ваши тестеры прекрасно научились есть суп при помощи этого инструмента во время тестирования. Вся функциональность работает.
Требования соблюдены.
А за время разработки вашей ложки появились ложки нового поколения, которые универсальны и подходят и для чая и для супа, и включаются в интегрированный столовый прибор содержащий также вилку, нож, авторучку, часы... и т.д.
Можно ли при этом оценить успешен проект или нет и приступить к изготовлению промышленных образцов?!

Как вы это сделаете без экспертной оценки представителей целевой группы пользователей?
А теперь, представьте, что продукт гораздо более сложен и специфичен и ваши тестеры вообще не эксперты в предметной области, и что целевых групп пользователей несколько, они перекрываются, и специфика их задач очень различна в рамках предметной области, а ваши тестеры де-факто не попадают ни в одну из них, кроме того ваш продукт предназначен не для всех групп пользователей в рамках предметной области...
Вы все еще считаете что экспертная оценка всего лишь моя прихоть?...
Я вам больше скажу, у ваших тестеров не будет достаточно знаний даже для того чтобы выполнить те формальные RUPовские
типы тестирования, что вы назвали (которые кстати, едва покрывают треть поднятых мною проблем):
- Requirements Testing - покрывают качество описания самих ребований, но не полноту согласно бизнес требованиям, это вообще делается
не формальным тестированием, а аналитикой, а часто Requirements Testing на практике вообще не применяется, потому что сами требования изначально не выдерживают никакой критики или просто отсутствуют, а оценить потенциальную конкурентноспособность продукта все равно надо.
- Business Cycle Testing - часто выполняются именно третьей стороной (экспертами, заказчиком, бэта тестерами) на ее оборудовании, включают набор use-case'ов, которые обеспечиваются функциональностью продукта, выполняются в течении длительного времени со съемом
множества метрик включая контроль стабильности, а так же Capacity (или по RUPовски Volume) базы данных если речь идет о клиент-серверной системе, могут быть частично автоматизированы. Но при этом сама полнота набора use-case'ов согласно RUP никак не оценивается, что опять таки - минус.
- User Interface Testing / Usability Testing - эти 2 понятия вообще недопустимо смешивать. Это разные вещи. Usability не имеет ничего общего с тестированием функциональности пользовательского интерфейса, оно лишь проводится на пользовательском интерфейсе равно как и на многих других возможных компонентах продукта, но тип тестирования и тесткейсы совсем другие, и не всегда человек не разбирающийся в предметной области
способен провести его самостоятельно, а тем более написать к нему тесты. Здесь речь также об удобстве использования невизуальных компонентов,
если таковые имеются и администрирования, например, распределенного клиент-серверного продукта и т.д. А удобство пользовательского интерфейса -
лишь часть этого типа тестирования. А теперь представьте что вам нужно протестировать Usability стратегического бомбардировщика...
Все тестируйте: удобство ведения боя, навигации, пилотирования, обслуживания, наземной транспортировки, и т.д. Сильно это будет связано с User Interface Testing??? А без эксперта в выполнении тестов только Usability вы сами справитесь? А сколько экспертов вам понадобятся?

Так вот, исходя из вышеизложенного, как вы считаете, попадают ли в область ответственности QA взаимодействия со структурами внешними по отношению к проекту, такими как например, бэта тестеры, представители заказчика (если таковые имеются), ваш собственный техсаппорт?
Отвечу сам - ДА!
Это как то имеет отношение к Quality Control?
Тоже отвечу сам - напрямую - вообще никак, ведь продукт и проект продолжают в этом случае изменяться и получать новые задания даже тогда, когда все требования по Quality Control формально уже соблюдены.

Это я и имел ввиду говоря об экспертной оценке.

Спасибо за внимание.

наливной комментирует...

идея про ложку гениальна

Условия копирования публикаций:

Все публикации в данном блоге являются частной собственностью авторов. Любое копирование информации допускается только при условии указания имени автора и активной ссылки на источник.