Три ступени развития службы контроля качества программного обеспечения

Занимаюсь тестированием давно. Сейчас руковожу практикой тестирования. Чтобы настроиться на рабочий лад, я расскажу анекдот про консультанта. Это мой любимый анекдот. Консультант решил отдохнуть, поехал на отдых. Едет на своей машине где-то в горах, ему пресекает дорогу отара овец с чабаном. Вот он решил: «О, как раз то, что надо! На ужин будет у меня шашлык!» Подходит к чабану и говорит: «Хочешь, я с точностью до одного барана скажу, сколько у тебя баранов в стаде!» «Ну, давай!» «А ты мне за это барашка!» «Ладно». Достает он свой ноутбук, соединяется с Internet, выходит на сайт, который занимается аэрофотосъемкой, делает фотографию, отправляет в исследовательский центр, расшифровывает, получает точные данные, говорит: «У тебя 325 баранов». Тот говорит: «Точно. Ну, бери барана. А хочешь, я скажу, чем ты занимаешься в жизни?» «Чем?» «Ты консультант». «А как ты узнал?» «Очень просто. Ты пришел тогда, когда тебя не звали. Ты дал мне ту информацию, которой я владел. И ты взялся за дело, в котором ничего не понимаешь. И вообще, отдавай мою собаку».

О чем сегодня пойдет речь? Существует целый набор стандартов, как сделать разработку более предсказуемой, более качественной. О них мы сегодня разговаривать не будем. Я постарался построить свой доклад на двух постулатах — это свой опыт и здравый смысл. О том, что у меня есть опыт, наверное, никто не будет спорить, но насчет здравого смысла мы можем поговорить потом в кулуарах. Подходите — побеседуем. Может быть, у кого-то свой здравый смысл, так что обсудим. Кстати, а кто может продолжить фразу? Как заканчивается у классика? Три источника и три составных части чего? Марксизма. Так, есть. А кто может перечислить их? Эх, не учили классиков. Это диалектический материализм, учение о прибавочной стоимости и учение о классовой борьбе. Но это немножко из другого доклада.

Три ипостаси. При создании службы качества нужно решить всего лишь три вопроса: создать службу, оптимизировать ее и управлять ею. Сейчас поговорим о первой ипостаси — это создание службы. Всего я выделяю шесть вопросов, на которые нужно найти ответы при создании службы качества. Причем, на мой взгляд, если вы отвечаете «да» на все эти шесть вопросов, то она у вас есть. Если хотя бы на один из этих вопросов вы отвечаете «нет», это значит, что ее не только нет, это значит, что вы тратите деньги попусту. Возможно, у вас есть специалисты, которые работают и делают качественно свою работу. Но каждое из этих «нет» говорит о том, что или вы не контролируете ситуацию, или у вас нет таких специалистов, или вы не управляете ситуацией. Давайте пока остановимся на этих шести основных вопросах, чтобы понять, на чем строится служба качества.

У Джоэла Сполски есть отличная статья «Пять неуважительных причин не иметь тестировщиков». Отлично написано, нет смысла повторяться. Все сводится, в принципе, к одному постулату — это экономически невыгодно. Но он не указал одну простую причину — разработчики не видят своих ошибок. Это свойство человека. Вот очень простой тест. Кто без ошибок в школе писал диктанты и сочинения, поднимите руку. Отлично! То есть мы видим, что из всех 5-6 человек могут сказать, что они почти качественно, без ошибок могут делать свою работу. Остальные все равно делают ошибки. Я в том числе. Помимо этого, почему разработчики не могут находить свои ошибки? У каждого своя задача, своя цель. Разработчики видят свою цель в том, чтобы подтвердить, что их функциональность работает. И они в этом убеждаются. Тестировщики ставят своей целью подтвердить, что функциональность не работает, и убеждаются в том, что они ищут. Так как цели разные, каждый получает свой результат. Если у вас разработчики тестируют код, то они чаще всего убеждаются в том, что он работает. В то же время тестировщики могут убедиться в том, что он не работает.

Вторая причина или второй вопрос, есть ли у вас стратегия тестирования. Протестировать программу на 100% невозможно, это уже аксиома. Сочетание тестовых данных почти бесконечного множества вариаций с теми путями, которые заложены в программу, делают эту задачу невозможной. Это означает, что вы заведомо не можете выполнить свою работу в установленные сроки в заданном бюджете. Какой вывод? Нужно планировать свою работу, нужно выставлять приоритеты, нужно проводить определенные приемы, использовать определенные приемы, чтобы как можно ближе подойти к задаче, найти все возможные дефекты. По минимуму, таких приемов несколько. Например, выделять класс эквивалентности тестовых данных и управлять рисками. Самый простейший вариант управления рисками — это выделить три категории тестов.

Первое — это small-test или небольшая группа тестов для того, чтобы убедиться, что приложение, которое к вам пришло на тестирование, действительно тестопригодно. Если оно падает при первом же «клике», то какой смысл его тестировать? Это трата времени. Вот именно эту задачу решает первая группа тестов — small-test.
Вторая группа тестов — это проверка критических путей. Это категория тех тестов, которые должны быть выполнены обязательно, иначе можно считать задачу тестирования невыполненной.

И третья группа тестов — это дополнительные тесты, которые желательно выполнить, если у вас осталось время. Такое случается. К примеру, когда вы выполняете тест, он занимает определенное время. Вы нашли в нем дефекты, вы их должны проверить, убедиться, что они в тестовом окружении проявляются. Условия их проявления занести в открытую систему. Возможно, обсудить это с кем-то, получить response, убедиться в том, что это действительно баг, а не фича. И на все это уходит время. Вы должны планировать время на эту работу. Но если вы не нашли дефекта, значит, тест прошел быстрее. Соответственно, у вас есть некоторая экономия времени. Нужно предусматривать ту категорию тестов, которую хотелось бы выполнить, если время осталось до конца операции тестирования. В конечном итоге, все это замыкается на матрицу покрытия требований тестами. Без этого фактически невозможно ни планировать, ни понять прогресс тестирования.

Архитектор производит архитектуру. Разработчик производит код. Что производит тестировщик? Это как в детской игре, когда называется пара предметов белого цвета, а потом спрашивают, что дает корова? Дети всегда отвечают молоко, ну, или чаще всего. Точно так же и здесь — тестировщик производит баги. На самом деле. Настоящие, истинные тестировщики сразу не согласились, остальные, наверное, к ним не относятся. Тестировщик — это зеркало проекта, он всего лишь отображает то, что произвел разработчик. Плохой тестировщик — плохое зеркало, хороший тестировщик — хорошее зеркало. В конечном итоге тот баг-репорт, который является результатом работы тестировщика, это, в общем-то, определенное задание разработчику. Ему что-то нужно сделать. Будет это сделано или не будет, это уже вопрос управления. Но баг, попавший в багтрекинговую систему, априори является заданием на внесение изменений. Отсутствие учета этих нюансов приводит к тому, что достаточно большое количество дефектов может сильно подвинуть следующие этапы разработки, увеличить объем работ, который не был учтен в планах. В принципе, неважно, как вы ведете свою базу дефектов. Вы ведете ее в какой-то очень накрученной системе, полностью автоматизированной, или просто в Exсel-файле. Важно, чтобы эта работа была однозначно всеми понята. Должен существовать процесс внесения бага, поступление заявки на внесение изменений разработчику, на проверку. И каждая стадия жизненного процесса дефекта должна быть четко и однозначно всеми понята. Этот процесс, описывающий жизненные этапы дефекта, и является основополагающим в вопросах качества.

Есть ли у вас процедура передачи версии в тестирование? Это, возможно, звучит для некоторых странно, но достаточно часто встречается ситуация, когда все свалено в одну кучу. Здесь разрабатываем, здесь же тестируем, здесь же исправляем, здесь же снова пытаемся тестировать. Этот гордиев узел очень трудно разрубить. Трудно оценить, где были внесены изменения, что тестировать, что не тестировать. И если рассмотреть стандартный набор кода, то его можно разделить на три части. Первая часть — это то, что не изменилось с прошлой версии. Вторая часть — это то, что изменилось. И третья — это то, что было добавлено нового. Нужно ли тестировать все три части в одинаковом объеме? Интеграционное тестирование — это немножко другое. Скажем так, третья часть требует максимального внимания. Вторая часть требует внимания в меньшей степени, потому что здесь только нужно проверить, не поломали ли изменения в системе все предыдущее. И первую часть достаточно протестировать на то, что интерфейсы первой и второй частей работают так же, как и должны работать. Нужно ли первую часть тестировать подробно? Нет, конечно, не нужно! Если вы не даете такой информации тестировщику, или нет механизмов для ее получения, то как он узнает, что изменилось в системе, а что осталось из предыдущей? И как он может построить приоритеты, что делать, в каком объеме. В конечном итоге это, собственно, экономика. Вот вам итерационный процесс. Это то, что прибавилось. Это то, что изменилось. Это то, что не изменилось. Точно такой же подход: это тестируем подробно, в этом тестируем изменения, это тестируем, чтобы не поломались переходы интерфейса. Помимо всего прочего, это передача ответственности. Ответственности не в том плане, как у классика, кто будет сидеть? А ответственность в том, чтобы четко понимать, чья процедура и в какой момент дала сбой и пропустила дефект на конечную стадию.

Этот слайд я уже фактически рассказал. Единственное, я хотел бы добавить про передачу ответственности. В качестве примера расскажу: есть такое Европейское Космическое Агентство. Оно уже много лет запускает космические корабли, которые бороздят просторы нашей Вселенной. Корабли называются «Ариан». В 1996 году, когда они переходили с версии «Ариан-4» на «Ариан-5», их постигла большая неудача. Космический ракетоноситель взорвался при старте и уничтожил очень ценный исследовательский спутник. Убытков было на 500 миллионов долларов. Дотошные французы докопались до причины, почему это произошло, благодаря этой процедуре (существованию процедуры, в том числе и процедуры передачи ответственности). Они нашли ошибку, они исправили эти процедуры. Ошибка оказалась банальная — переполнение буфера. Возникла она вследствие того, что на версии «Айрин-4» использовалась 16-ричная система исчисления. Дальше они перешли к 64-ричной системе, и те компоненты, которые хорошо работали, которые не надо было изменять, они оставили. Все логично: зачем тратить деньги на то, что и так хорошо работает. Но так как в 16-ричной системе этого вообще не могло произойти, то сопряжение новой системы со старой в одной компоненте дало сбой. Да, не могло такого произойти, поэтому нигде не стояла проверка на переполнение буфера. А когда новая система стала работать, компонента, работающая по одному принципу, пыталась запихнуть слишком много в другую. Та почувствовала себя не очень хорошо и решила, что самый лучший выход из ситуации — это все к черту взорвать. Тем не менее, надо отдать должное, они все-таки нашли эту ошибку, уже потом, когда обломки изучали.

Последний вопрос — это оценка готовности программы. Весь фокус в том, что если у вас нет QA, если у вас нет тестирования, то вы никогда не узнаете, готова ваша программа или нет. У вас нет объективных данных о системе. Можно ли судить о готовности системы по количеству багов? Нельзя. Должны существовать критерии. Критерии это не постановка задач. Критерии — это то, как мы будем судить о том, готова система или нет. Да, один из критериев это процент количества багов. Но сразу вопрос: у нас система протестирована, мы знаем, сколько в ней багов, но если мы опираемся только на дефекты, мы можем понять, система готова к выпуску или нет? Нет. Не можем. Все очень просто. У вас есть, к примеру, 100 требований. Из них вы покрыли тестами, тест-кейсами только 80. Кто-нибудь может сказать, что у них система покрывается тест-кейсами на 100%? Поднимите руку, у кого такое происходит? У нас, наверное, никто не разрабатывает ядерные реакторы и прочее. Хотя сомневаюсь, что и у них на 100% это сделано. При этом мало покрыть тест-кейсами всю систему. Нужно еще и каждый тест-кейс протестировать, как минимум, в 4 вариантах. Это простейший случай. Это класс эквивалентности. Если мы в качестве примера возьмем числовую прямую, то нам надо, как минимум, протестировать левую неправильную точку, левую правильную, правую правильную и правую неправильную. Спасибо! Получается, что у нас есть система, она протестирована. Мы знаем, насколько много есть дефектов. Но если мы при этом не учитываем, сколько тест-кейсов у нас должно было быть, сколько их есть, мы не можем оценить, насколько система протестирована в действительности. То есть, есть шесть минимальных вопросов, которые надо решить. Если вы их решили, у вас есть тестирование. Если вы их не решили, у вас тестирования нет. Решили эти вопросы, ответили «да» на каждый вопрос — отлично, дальше можете строить любую систему качества — ISO, CMM, CMMI — какого угодно уровня.

Дальше уже второй этап. Если рассмотреть перечень операций, разница видна? Для вас — в правой части, для меня — в левой. Суть операций заключается в том, что некоторые из них сведены к минимальным усилиям.

Существует японская система «КайДзен». Наверное, многие слышали об этой системе. Она очень сложная, русскому человеку очень трудно ее понять. Типа «всегда наводи порядок на своем рабочем столе», «все должно быть подписано, где что лежит». Но, тем не менее, идея, которая заложена в этой системе, очень простая. Она заключается в следующем. Business Value или то, что деятельность дает полезного — это функциональное время, полезное время. Все остальное — это время простое, которое нужно сократить или свести к минимуму. Так вот, в работе тестировщика таких операций море. Море операций, которые не ведут к этому business value. Их нужно сократить максимально. И вот сейчас мы можем сказать, что это хит сезона. Автоматизация, наконец, докатилась и до development-а, до софтверных организаций. А то все говорили о том, что надо автоматизировать банки, надо автоматизировать страховые компании, CRM и прочие системы. Наконец-то, начали появляться системы, которые позволяют автоматизировать работу создания программ. Были попытки и раньше, но в данном случае это разбито на артефакты, разные этапы работы тестировщика. Вот если нажать кнопочку, волшебным образом подчеркнулись те места, которые автоматизируются в новой системе TFST. Team Foundation Server for Testers от Microsoft. Это не единственное решение на рынке, но оно сейчас достаточно популярное, наверное, в первую очередь потому, что Microsoft наиболее успешно продвигает свои решения, в отличие от многих других компаний. Это реально работает. Это реально позволяет свести к минимуму многие операции, которые занимают минуты, а складываются в часы, и в конечном итоге, что является непродуктивным в работе тестировщика.

И переходим к последнему этапу — это управление процессом. Почему в некоторых компаниях нет тестирования? Не будем поднимать руки, у кого его нет. Очень просто. Тестирование не приносит никакой прибыли, абсолютно никакой. А наоборот, оно съедает существенную часть бюджета, бюджета проекта. Логика очень проста — экономим на тестировании, значит, экономим бюджетные деньги. На самом деле в качесте ROI, в приведённой мной формуле должна быть не прибыль, а деньги, которые тестирование экономит. И тогда все становится на свои места. Четыре задачи тестирования: мы обнаруживаем ошибки, мы их обнаруживаем и не устраняем, но знаем о них. Кстати, был довольно интересный пример, можно сказать, забавный. Лет пять назад весь лос-анджелесский аэропорт стоял на ушах, была критическая ситуация. Система управления полетами отказала. Супернадежная система отказала. Ситуация была очень серьезная, очень высокий код опасности. Всех, кого можно, распихивали по разным аэродромам, кого уже было нельзя, тех сажали вручную. Потом стали разбираться, что случилось? Очень просто — нужно читать документацию. Оказывается, разработчики честно признались, написали: «Наш сервер нужно перегружать раз в 30 дней». И все, и никаких проблем. Вот если бы те, кто использовал его, читали документацию, они бы знали, есть такая проблема. И никаких экстренных ситуаций бы не случилось. История умалчивает. Одно могу сказать — это не русские. Мы как-то разрабатывали систему. Я руководил проектом, который тестировал. Это www.las-vegas.com. Это самый посещаемый сайт в Америке после sex.com. Считается, что каждый американец раз в жизни должен посетить Лас-Вегас. У них там жизненные принципы такие. Было два заказчика, мы делали все. Все, что связано с платежами и транзакциями по карточкам, нам не было поручено по одной простой причине, потому что все русские — хакеры. Это в документации не было записано, но, в общем, все откровенно так заявляли. Да, кстати, была очень забавная ситуация, отвлекусь. Мы сделали систему, мы представляли клиентам. Клиенты очень важные, миллиардеры. Дело в том, что в Лас-Вегасе у них больше 300 отелей. И две ассоциации: 98% всех отелей входит в одну ассоциацию и 98% входит в другую ассоциацию. И вот одной их этих ассоциаций мы представляли работу. В общем, мы им показывали все. Все хорошо, все классно. Но это был 2002 год, и у нас система была «сырая», были кнопочки у аккаунт-менеджера: здесь нажимаем, здесь ни в коем случае не нажимаем. Естественно, он нажал эту кнопочку, все упало. Но это был 2002 год. Выход из положения нашли очень остроумно. В этот момент, буквально за несколько недель, американский самолет-разведчик нарушил пространство Китая и был принудительно посажен, при этом китайцы потеряли свой самолет, разбился летчик, американцы несколько дней держали оборону в своем самолете, наверное, ели секретные документы. И потом им сказали: «Можно, открывайте!» Их, в общем, выпустили, но суть в другом. Китайские хакеры поклялись максимально осложнить жизнь американцам. И мы сказали: «Все, ребята, извините, наша система говорит, это китайские хакеры. Все. Мы отбили атаку, сейчас все настроим, через полчаса все будет работать».

В этом примере все данные, в основном, взяты из книги очень интересного парня со странной фамилией для русского языка Блэкрэкс. Русские его любят называть Рэксблэк. Или наоборот. По его данным, среднее количество ошибок, команда разработчиков, срок активной разработки — в сумме мы получаем две тысячи дефектов. Если посмотреть рост стоимости, это, опять же, довольно усредненные и обобщенные данные. У каждого они могут быть свои. Каждый следующий этап на порядок увеличивает затраты. Тестирование — это 100 долларов. Здесь стоит 500, это по данным как раз этого гуру в тестировании. Он считает, что стоимость дефекта достигает 500 долларов, особенно, в промышленной разработке. Это не зарплата тестировщика, а жаль. Тогда бы я пошел в Support. Это включает в себя затраты. Это лицензии — я понимаю, ко многим это не относится, многие экономят. Но не будем спрашивать, кто — сейчас это уже не модно, даже опасно, кстати. Это поддержка тестовой лаборатории, это много чего. Все тестировщики знают, да и не только тестировщики. По данным я уже сам забыл, как его правильно называть, в среднем 80%, ну это в хорошем проекте 80%, дефектов находится на стадии тестирования. То есть дальше в Support и в Production поступает менее 20% дефектов. Можно сделать несложные вычисления. Они доступны даже многим тестировщикам. Получаем довольно приличный бюджет. Стоит этим управлять? Наверное, стоит.

Вопрос: Что означает сумма на слайде?

Сергей: Речь идет о стоимости дефекта. Это то, что стоит потратить, чтобы выявить 80% дефектов. Если вы спросите, сколько нужно потратить, чтобы сделать эти 80% дефектов, то да.

Вопрос: Но ошибка, внесенная на стадии проектирования, обойдется значительно дороже той, которая была внесена, например, на стадии разработки.

Сергей: Кто спорит? Кто-нибудь против? Нет. Секундочку. Это усредненные данные о стоимости дефекта. Он включает и дефекты, найденные, например, white box testing, которые значительно дешевле, чем black box testing. И дефекты, найденные в конце тестирования, которые являются critical-дефектами на стадии, например, бета-тестирования. Они могут обойтись в колоссальные деньги. Они могут стоить компании значительно больше, чем найденные на предыдущих. Сюда же включены все дефекты, все категории дефектов, созданные на стадии сбора требований, на стадии разработки архитектуры, на стадии разработки кода. Поэтому делить на то, что было на стадии создания архитектуры и кода, это не относится к этой таблице.

Вопрос: Есть ли смысл привлекать специалистов по тестированию в те предприятия, деятельность которых не связана с разработкой и продажей программного обеспечения? Но, тем не менее, программное обеспечение на этих предприятиях разрабатывается.

Сергей: Странный вы от меня ожидаете ответ. Если вы думаете, что я скажу «нет», тогда зачем я все это рассказывал. А если я скажу «да», то это как бы само собой подразумевается. Везде, где есть разработка, нужно тестировать. Сколько тестировать — это уже методология, это бюджет, это политика, это уже вопрос другой. Тестировать нужно.

Вопрос: Тестирование начинается уже после того, как сделана какая-то разработка?

Сергей: Я бы хотел сказать, что да. Вопрос следующий. У нас есть определенные стадии процесса разработки: когда еще нет кода и потом, когда уже есть код. Как искать ошибки или ловить эти ошибки, когда у нас кода нет? Что тестировать? Те артефакты, которые рождаются в процессе работы специалистов до создания кода. Легко это сделать? Нет. Есть ли методики? Да.

Вопрос: Как можно проверять программу, пока нет кода?

Сергей: Я вам подскажу самый простой способ, как проверять программу, когда нет еще ни одной строчки кода. Это здравый смысл и логика. Я думаю, что если вы попробуете делать review требований, то на этой стадии, даже не будучи специалистом, вы можете найти много логических несоответствий. Если это будет делать специалист, то найдет их больше. Где взять таких специалистов? На рынке. Походите по рынку — найдите дешевле. Как в анекдоте.

Вопрос: А ваша компания эти вопросы закрывает?

Сергей: Да. Она эти вопросы закрывает. Но так как она молодая, немногочисленная, на всех не хватает, но подходите, побеседуем.

Вопрос: Какой у вас бюджет у тестирования?

Сергей: Бюджет — это вопрос очень интересный. А вы когда-нибудь слышали, чтобы вам раскрывали тайны бюджета?

Вопрос: Какой должен быть бюджет у отдела тестирования?

Сергей: Вообще, чем больше, тем лучше.

Вопрос: А если выражать относительно бюджета разработки?

Сергей: В процентах? Смотрите, очень простая логика. У вас высококвалифицированные тестировщики. Желательное соотношение «один к трем». Три разработчика — один тестировщик. Если они не очень квалифицированные, то «один к двум». Это желательное соотношение. Соблюдается ли оно? Конечно, нет. Но, например, в той же Microsoft два тестировщика на одного разработчика. И тестировщики у них довольно хорошие, которые пишут сразу код и автоматизируют тестирование. Но, опять же, я просто читал об этом. Это не значит, что это правило. Я думаю, что и в той же Microsoft есть забитые проекты, у которых маленький бюджет и у которых с тестировщиками тоже очень туго.

Вопрос: Должны ли тестировщики писать unit-тесты?

Сергей: Я уверен, что писать тестировщикам unit-тесты экономически невыгодно, хотя если вы посещали такой самый крупный в ru-нете сайт, посвященный тестированию как software-testing.ru, там это очень долго и много муссировалось. Есть такие компании, которые заставляют своих тестировщиков писать код для unit-тестов. Они просто выбрасывают деньги на ветер. Должны ли разработчики писать свой код, тестирующий их код? Да. Должны. И даже обязаны. Но они почему-то в это не верят.

Вопрос: На самом деле вовсе необязательно. Например, один разработчик будет тест писать, а второй разбатывать код.

Сергей: Это другой подход. В данном случае могут и тестировщики писать тесты. Почему бы и нет. Если у нас есть задокументированные API, если поведение интерфейса не меняется. Пусть реализация будет хоть какая. Не играет роли. Посадите тестировщиков, есть такие тестировщики, которые читают код с листа. Почему бы и нет? Но это проблема. Например, у нас в компании есть проект, который выполняется для компании Ping Identity. Это фирма, небольшой такой start up, который разрабатывает свой персональный протокол аутентификации web-пользователей. Но им повезло, их сейчас выбрали в качестве стандартного решения для всех государственных учреждений США. Ну, или не повезло. Повезло с тем, что теперь они стоят перед такой проблемой, а где взять. Увеличиваются объемы работ, у них такие тестировщики есть. И вакансии открыты по 3-4 месяца, по полгода некоторые. Действительно это проблема. Другой пример. Скажем, в США существует закон о скрытии персональных данных специальными механизмами, чтобы хакеры до них не добрались. И обязывают все компании, действующие на территории США или в интересах компаний США, применять механизмы скрытия этой информации, так называемые секъюрити. И вот компания Dell решила, что пора и им заводить такую систему, такую программу сокрытия своих данных. Давайте искать специалистов. Они открыли вакансию в Москве «Специалист-тестировщик. Специалист по информационной безопасности» и не смогли найти ни одного специалиста. Хакеров море, а как против них бороться, еще пока неизвестно. Нигде не учат. Есть энтузиасты, но, к сожалению, они редки. А компания Dell перенесла эту вакансию в Ирландию и там не смогла найти таких специалистов. В Америке нашли. Но они могут себе позволить бросать так вакансии. Есть незакрытые пятна на рынке. Все, спасибо за внимание. Если есть вопросы, милости прошу.

Только зарегистрированные и авторизованные пользователи могут оставлять комментарии. Авторизуйтесь, пожалуйста.