Текст книги "Agile-тестирование. Обучающий курс для всей команды"
Автор книги: Лайза Криспин
Жанр: Управление и подбор персонала, Бизнес-Книги
Возрастные ограничения: +12
сообщить о неприемлемом содержимом
Текущая страница: 1 (всего у книги 30 страниц) [доступный отрывок для чтения: 10 страниц]
Джанет Грегори, Лайза Криспин
Agile-тестирование. Обучающий курс для всей команды
Научный редактор Сергей Виноградов
Издано с разрешения Pearson Education, Inc. (Addison-Wesley Professional)
Благодарим за консультации Илью Таджибаева
Все права защищены.
Никакая часть данной книги не может быть воспроизведена в какой бы то ни было форме без письменного разрешения владельцев авторских прав.
Authorized translation from the English language edition, entitled MORE AGILE TESTING: LEARNING JOURNEYS FOR THE WHOLE TEAM, 1st Edition; ISBN: 0321967054; by GREGORY, JANET and by CRISPIN, LISA; published by Pearson Education, Inc., publishing as Addison-Wesley Professional.
© 2015 by Lisa Crispin and Janet Gregory. All rights reserved. No part of this book may be reproduced or transmitted in any form or by any means, electronic or mechanical, including photocopying, recording or by any information storage retrieval system, without permission from Pearson Education, Inc. RUSSIAN language edition published by MANN, IVANOV, and FERBER PUBLISHERS. © 2019.
© Перевод на русский язык, издание на русском языке, оформление. ООО «Манн, Иванов и Фербер», 2019
* * *
Моим внукам Лорен, Брейдену и Джо, которые радовали меня весь год.
Джанет
Моей семье. Тем, кто со мной, и тем, кого уже, к сожалению, нет с нами. Моим дорогим друзьям, которые являются частью той семьи, что я выбрала сама.
Лайза
Предисловие Элизабет Хендриксон
Еще десять лет назад Agile считался чем-то радикальным. Маргинальным. Странным. Стандартный подход к разработке программного обеспечения включал анализ, дизайн, написание кода и тестирование. Интеграция и тестирование проводились на заключительном этапе. Полный цикл разработки занимал месяцы, даже годы.
Если вы никогда не работали в компании с долгими циклами и прерывными фазами, это покажется немного странным, но десять лет назад стандарты были такими. Когда Agile только зарождался, он был направлен в основном на программистов. Джанет, Лайза и еще несколько специалистов по контролю/обеспечению качества (QA) и тестированию были в их числе. В то же время многие последователи Agile не чувствовали необходимости в QA. Конечно, они ошибались. QA изменился, подстраиваясь под новые сферы деятельности, но никуда не исчез.
Такие люди, как Джанет и Лайза, показали, как можно встроить QA в Agile, вместо того чтобы игнорировать его. В своей первой книге[1]1
Криспин Л. Грегори Дж. Гибкое тестирование. Практическое руководство для тестировщиков ПО и гибких команд. М.: Вильямс, 2016.
[Закрыть] Джанет и Лайза рассказали о корпоративных изменениях, необходимых для полной интеграции тестирования и разработки, научили преодолевать трудности. Рекомендую эту книгу.
Однако остались вопросы. Как эти методы применять в различных сферах? С чего начать? Что должен знать тестировщик, чтобы быть наиболее эффективным? Эта книга начинается с того, на чем заканчивается первая, и отвечает на вышеназванные и многие другие вопросы. И даже если бы в книге содержались только эти ответы, она уже была бы замечательным продолжением. Но она намного больше. Здесь вы столкнетесь с темой, которую Джанет и Лайза так искусно вплели в текст, что ее можно даже не заметить. Я же хочу обратить ваше внимание на то, что эта книга об адаптации.
Обдумывайте и адаптируйте. Этот простой способ поможет вашей компании прийти к Agile. Экспериментируйте, пробуйте разные подходы, фильтруйте полученные знания, повторяйте. Так вы почувствуете, что ваша организация подвижна и гибка, способна двигаться в ногу с запросами рынка и постепенно удовлетворять их. Эта книга учит адаптировать, несмотря на то что она в общем-то об Agile-тестировании.
Часть вторая «Обучение для улучшения тестирования» касается не только того, как вы учитесь сами, но и того, как построить учебную среду.
Часть седьмая «Разные сферы деятельности» не просто рассказывает о разных вариантах Agile, приспособленных под различные условия, а является своего рода путеводителем по разного рода адаптациям.
Мир невероятно быстро меняется. Еще десять лет назад Agile был чем-то странным, теперь это мейнстрим. Планшеты типа iPad теперь повсюду, а несколько лет назад никто не знал об их существовании. Методы, инструменты, технологии меняются наравне с рынком так быстро, что за ними трудно успевать. Уже недостаточно уметь что-то делать одним способом, необходимо открывать новые пути. Эта книга – фантастический источник для Agile-тестирования. Она научит адаптироваться и чувствовать себя комфортно в процессе изменений.
Надеюсь, она понравится вам так же, как мне.
Элизабет Хендриксон,основатель и президент Quality Tree Software Inc.
Предисловие Джоанны Ротман
Что делают тестировщики? Они представляют информацию о продукте на основании тестов, и это позволяет определить задачи для команды.
Именно это Джанет Грегори и Лайза Криспин сделали в своей книге. У вас проблемы с гибкостью? Существует множество способов, которые помогут понять ценность совместной работы, создания и обучения коллектива и вашу роль в процессе тестирования.
Не знаете, как выстроить тестирование конкретного продукта, коллектива или программы? Здесь вы найдете ответ.
Как вы взаимодействуете с коллегами за офисной перегородкой? А с теми, кто находится на другом конце мира? Джанет и Лайза сталкивались с этим и знают о проблеме не понаслышке. Они делают акцент на ролях, а не на должностях. И это особенно ценно.
В книге много изображений, так что вам не придется постоянно думать, что авторы имели в виду. Они не просто рассказывают – они показывают.
«Agile-тестирование. Обучающий курс для всей команды» – больше, чем книга о тестировании. Она о том, как с помощью тестирования выстроить работу команды, отдела, организации и обеспечить наиболее эффективный переход к Agile. Не в этом ли и заключается суть представления информации об организации на основе тестов, которые выявляют существующие проблемы?
Тестировщикам или руководителям команды тестировщиков нужна эта книга. Если вы внедряете тестирование в свою организацию, она также пригодится. Иначе как вы узнаете, что должен делать тестировщик?
Джоанна Ротман,консультант по вопросам управления
Пролог
Эта книга – продолжение темы, о которой мы говорили в предыдущей книге. Мы не будем повторяться, но выстроим контекст так, чтобы все было понятно, даже если вы не читали ее. Мы ссылаемся на «Гибкое тестирование», когда нам кажется, что читателю необходимо получить детальное представление об основных определениях.
ДЛЯ КОГО ЭТА КНИГА
Мы предполагаем, что вы, читатель, не новичок в мире Agile-тестирования, что у вас уже есть определенный опыт работы с Agile и опыт тестирования, и теперь вам нужна помощь в областях за их пределами. Если требуется введение в развитие Agile и в основы Agile-тестирования, перед прочтением этой книги рекомендуем ознакомиться с работой Расмуссона «Гибкое управление IT-проектами. Руководство для настоящих самураев»[2]2
Расмуссон Дж. Гибкое управление IT-проектами. Руководство для настоящих самураев. СПб.: Питер, 2012.
[Закрыть].
Эта книга для всех, кто интересуется процессами тестирования в Agile-командах. Судя по нашему опыту, это не только тестировщики и руководители команд, но и программисты, заказчики, бизнес-аналитики, DevOps-специалисты, руководители направлений, – одним словом, почти все.
ПРИЕМОЧНОЕ ТЕСТИРОВАНИЕ
В дополнение к тому, чем мы делимся с вами, о чем узнали за последние несколько лет, хотим, чтобы эта книга была полезна читателям. Нам хотелось знать, какие вопросы остались у прочитавших первую книгу. Поэтому мы попросили всех пользователей в нашей имейл-рассылке пройти своеобразное «приемочное тестирование». Мы отфильтровали ответы и приложили все усилия, чтобы раскрыть суть возникших вопросов во второй книге.
Вы заметите, что мы используем разработку через поведение (Behaviour Driven Development, BDD), о которой подробнее поговорим в главе 11.
Например, <исходные данные>,
Когда <триггер, действие>,
Я должен <ожидаемый результат>.
• Я Agile-тестировщик или руководитель. Когда нанимаю новых тестировщиков без опыта работы по системе Agile, я должен знать, как ввести их в работу, не бросая за борт без спасательного жилета.
• Я работаю в команде Agile. Когда прочту эту книгу, я должен узнать как подходить к исследовательскому тестированию с автоматизированными тестами и получать общую картину покрытия тестами без использования сложных инструментов.
• Я опытный руководитель команды тестировщиков Agile. Когда прочитаю эту книгу, должен понять, как использовать Agile-тестирование в разных командах, чтобы моя компания могла развиваться.
• Я опытный руководитель команды тестировщиков. Прочитав эту книгу, должен понять, как координировать автоматизированные процессы тестирования на разных этапах с различными командами, как их улучшить.
• Я опытный руководитель команды тестировщиков Agile. Когда прочту эту книгу, должен понять, как другие команды адаптировали методы Agile-тестирования для различных областей, и получить представление, как применить это в своей сфере.
• Я работаю в команде Agile и интересуюсь тестированием. Закончив читать эту книгу, я пойму, какими должны быть тесты, а какими нет, и как эффективно организовать тестирование.
• Я опытный Agile-тестировщик. Натыкаясь в книге на интересную тему, я хочу получить ссылки на онлайн-ресурсы и другие книги.
• Я опытный Agile-тренер или руководитель. Если в книге упоминается идея, полезная для моей команды, то должно быть достаточно информации, чтобы разработать стратегию и убедить коллектив попробовать ее в деле.
• Я работаю в команде Agile, и мои задачи касаются тестирования и информирования клиентов. Когда прочту эту книгу, я должен понять, как говорить с командой заказчика о процессах тестирования.
• Я опытный руководитель команды тестировщиков Agile. Прочитав эту книгу, хочу знать о наиболее распространенных методах внедрения Agile, понимать рабочую среду тестировщиков из других компаний, если они претендуют на место в моей команде.
(Важно: это приемочное тестирование – не часть книги, но мы думаем, что некоторые примеры и истории, рассказанные здесь, помогут добиться результатов.)
КАК ЧИТАТЬ ЭТУ КНИГУ
Мы распределили информацию так, как считаем удобным. Тем не менее вам не обязательно читать книгу с первой главы. Вы можете начать с любой наиболее интересной темы. Мы стараемся рассказать лишь раз о каждой, но так как многие методы и принципы пересекаются, вы обнаружите похожие идеи в разных главах.
ЧАСТЬ ПЕРВАЯ. ВВЕДЕНИЕ
Прочтите эту часть, чтобы понять, как появилось Agile-тестирование, как оно превратилось в краеугольный камень развития системы Agile и продолжение разработки продуктов. Отчасти успешное внедрение Agile зависит от способности компании определять наиболее важные задачи для успешного Agile-тестирования в долгосрочной перспективе.
ЧАСТЬ ВТОРАЯ. ОБУЧЕНИЕ ДЛЯ УЛУЧШЕНИЯ ТЕСТИРОВАНИЯ
Технологии и мастерство тестирования постоянно развиваются, и границы между различными областями постепенно размываются. Даже опытным специалистам нужно постоянно повышать свои навыки. В этой части рассказывается, что необходимо знать тестировщикам, бизнес-аналитикам или программистам, чтобы преодолевать трудности, возникающие в процессе тестирования. Мы объясним плюсы специалистов широкого профиля и перечислим неочевидные умения и отдельные техники, которые будут полезны тестировщикам и всему коллективу. В этой части раскрываются различные аспекты того, что и как изучать.
ЧАСТЬ ТРЕТЬЯ. ПЛАНИРОВАНИЕ РАДИ ЦЕЛОСТНОЙ КАРТИНЫ
Планировать ровно столько, сколько необходимо, – секрет равновесия. Пока мы работаем на небольших отрезках, необходимо следить за всем процессом, за всей системой. В этой части мы рассказываем о различных аспектах планирования: от выпуска продукта до постановки задач. Здесь вы также найдете информацию о разных моделях, таких как квадраты Agile-тестирования и предложенные стратегии адаптации.
ЧАСТЬ ЧЕТВЕРТАЯ. ТЕСТИРОВАНИЕ БИЗНЕС-ЦЕННОСТИ
Если вы, как и многие Agile-команды, разрабатываете надежный код только для того, чтобы понять, что это не то, чего хотел заказчик, вам пригодится информация из этой части. Мы рассказываем об инструментах и принципах, особенно из сферы бизнес-аналитики, которые помогут определить идеи и варианты на ранней стадии, а также убедиться, что каждый знает свои задачи. Мы также обращаемся к смежным дисциплинам и расширяем мышление.
ЧАСТЬ ПЯТАЯ. ИССЛЕДОВАТЕЛЬСКОЕ ТЕСТИРОВАНИЕ
Программисты прислали вам некий код для тестирования. С чего начать? Если вы или ваша команда испытываете трудности с исследовательским тестированием, то в этой части вы найдете много полезного. Мы выделили несколько техник исследовательского тестирования: использование искусственных образов (персон) и туров (маршрутов) для генерации новых идей и тестов, сессионное тестирование (SBTM) и тестирование вокруг различных направлений («цепочек») работы (TBTM).
Наряду со всеми этими подходами мы рассматриваем другие пути удостовериться, что написанный код удовлетворяет потребности бизнеса и пользователей. В этой части мы рассматриваем пути минимизации рисков и сбора полезной информации в ходе нескольких видов тестирования, которые представляют трудности для Agile-команд.
ЧАСТЬ ШЕСТАЯ. АВТОМАТИЗАЦИЯ ТЕСТИРОВАНИЯ
Все больше и больше команд преуспевают в автоматизации тестирования, но при этом многие сталкиваются с единичными сбоями, разобраться в которых дорогого стоит. Каждый такой сбой может потребовать больше времени (и денег), чем все тестирование в целом. Автоматизированные тесты таят множество ловушек. В этой части мы приведем примеры, как распознать технический долг. Рассмотрим различные способы использования пирамиды тестирования, что поможет в планировании. Изучим некоторые альтернативные виды пирамиды тестирования для подхода к автоматизации под другим углом. Вы научитесь проектировать надежные и простые в использовании автоматизированные тесты. В этой части также приводятся примеры внедрения автоматизированных тестов в крупных компаниях.
ЧАСТЬ СЕДЬМАЯ. РАЗНЫЕ СФЕРЫ ДЕЯТЕЛЬНОСТИ
Ваш подход к Agile-тестированию будет определяться сферой деятельности. Вы работаете с крупными предприятиями? Возможно, перед вами стоит новая задача протестировать мобильное приложение или встроенное программное обеспечение. Может быть, ваша команда столкнулась с трудностями при поиске оптимального тестирования данных, которые помогают коммерческим предприятиям принимать решения. Интересовались ли вы, как Agile может работать при тестировании установленного ПО? Мы рассмотрим связь между тестированием и шагами в интеграции разработки ПО. Главы этой части касаются различных областей, поэтому мы включили истории людей, уже работающих в данных условиях. Некоторые из глав, возможно, не имеют отношения к сфере, в которой вы сегодня работаете. Но кто знает, что будет завтра.
ЧАСТЬ ВОСЬМАЯ. AGILE-ТЕСТИРОВАНИЕ НА ПРАКТИКЕ
В заключительной части мы рассмотрим, как команды могут визуализировать качество и тестирование, подведем итог всему, что узнали о методах Agile-тестирования. Это позволит чувствовать себя увереннее на стадии принятия решений. Создание общей версии для вашей команды невероятно важно для успешного исхода, так что мы поделимся моделью, которая поможет донести суть процесса тестирования до всех сотрудников.
В книге есть также два приложения:
• Приложение А. Page Object на практике: примеры.
• Приложение Б. С чего начать.
ДРУГИЕ СОСТАВЛЯЮЩИЕ
Поскольку команды используют различные методы и подходы Agile, мы постарались сохранить общую терминологию, насколько это возможно. Чтобы говорить на одном языке, добавили глоссарий используемых терминов.
Надеемся, вы захотите подробнее узнать о некоторых методах, техниках и инструментах, которых мы коснемся. Пожалуйста, посмотрите список литературы в конце книги, сайты, статьи и блоги, на которые мы ссылаемся. Мы разбили их согласно частям книги, чтобы необходимую информацию было проще найти во время чтения. Источники, упомянутые в самой книге, для удобства размещены в алфавитном порядке.
ЭКСПЕРИМЕНТ
Линда Райзинг много лет назад уговорила нас провести несколько маленьких экспериментов, изучить их результаты и продолжить решать задачи по частям, постепенно добиваясь поставленных целей. Если что-то в этой книге покажется полезным для вас и вашей команды, попробуйте внедрить это хотя бы пару раз. Оглядываясь назад, посмотрите, сработали ли нововведения, и при необходимости измените что-то. Если ничего не сработало, не огорчайтесь: вы получили опыт и сможете попробовать что-то другое.
Надеемся, на страницах этой книги вы найдете множество полезных для себя вещей.
Часть 1. Введение
В первой части мы быстренько пробежимся по истории того, как изменилось Agile-тестирование с тех пор, как мы впервые стали работать с Agile-командами. Представим некоторые новые концепции и подробно поговорим о важности изучения корпоративной культуры.
• Глава 1. Как изменилось Agile-тестирование.
• Глава 2. Важность корпоративной культуры.
Глава 1. Как изменилось Agile-тестирование
Каждый из нас начинал карьеру в области Agile как одиночка на поприще экстремального программирования (Extreme Programming, XP) во времена, когда даже не упоминалось о том, что в каждой команде могут быть свои тестировщики. Было всего два игрока: программист и заказчик. Клиенты определяли необходимые приемочные тесты, программисты автоматизировали их: раз, два и готово. На конференциях по экстремальному тестированию мы были единственными, кто определял себя как тестировщиков, хотя и понимали, что они могут внести значительный вклад в работу коллектива. Мы экспериментировали, обсуждали тестирование с первопроходцами XP, обменивались мыслями.
Но Agile развивался, а вместе с ним менялось и Agile-тестирование. Команды стали создавать библиотеки и фреймворки по автоматизации тестов и выводу их на новый уровень. Многие специалисты, внедрявшие Agile, оценили вклад опытных тестировщиков, таких как Элизабет Хендриксон и Майкл Болтон. Брайан Марик и Джошуа Кериевски впервые приняли на вооружение идею использования тестирования на основе примеров и историй, чтобы управлять разработкой.
Уорд Каннингем создал Fit (фреймворк для комплексного тестирования) – инструмент, помогающий выявить такие примеры. Дэн Норт представил BDD, которая проложила путь новым популярным инструментам (North, 2006). Agile-команды осознали ценность исследовательского тестирования, и оно стало для них не просто функциональным. Как показал Брайан Марик в своей матрице, которую мы адаптировали для квадратов Agile, тестирование охватывает теперь множество областей (Marick, 2003).
Конечно, все еще оставались трудности, препятствующие успеху Agile-тестирования. Мы, тестировщики, завидовали всем тем инструментам, которые имелись у программистов в свободной интегрированной среде разработок (Integrated Development Environments, IDEs). Нам хотелось, чтобы для нас все было так же просто. Мы начали эффективно использовать «силу трех», или «трех друзей», как говорит Джордж Динвидди. Когда заказчик, программист и тестировщик работают вместе, всегда возникают вопросы, как должен функционировать тот или иной элемент (Dinwiddie, 2010). Тем не менее было непросто учесть все запросы клиентов: дизайн, юзабилити, данные и другие составляющие качественного продукта. О некоторых из них мы поговорим в этой книге.
Практикующие специалисты в разных областях заполняют пробелы в Agile-тестировании. Мы счастливы поделиться историями реальных людей, рассказать о том, как они успешно использовали Agile-тестирование в разных сферах.
Тестирование в командах Agile – это процесс, а не конечный пункт. Эту идею, витавшую в наших мыслях, нам подсказала Элизабет Хендриксон (Hendrickson, 2006). В книге мы подчеркиваем: в процессе разработки софта тестирование должно учитываться на всех этапах.
Постоянно изучая лучшие техники Agile-тестирования, мы обнаружили, что подготовка специалистов широкого профиля с углубленными знаниями и навыками помогает справиться со сложными задачами. Опытные эксперты создали методы и шаблоны, которые позволяют членам команды из разных сфер сотрудничать и узнавать друг от друга ровно столько, сколько им необходимо.
Практикующие специалисты, такие как члены Agile-альянса инструментов функционального тестирования (Agile Alliance Functional Test Tools, AA-FTT), проложили путь к созданию более эффективных инструментов тестирования. Сегодня подход к написанию кода тестов так же важен, как и подход к написанию кода основного приложения. Мы научились определять, какой фреймворк, тестовая библиотека или драйвер подходят для конкретных нужд команды.
Выявляя потребности клиентов, бизнес-аналитики внесли свой вклад в развитие Agile. Тестирование и бизнес-аналитика обладают некоторыми взаимосвязанными качествами, которые помогают определить коммерческую ценность продукта. Таким же образом эксперты по пользовательскому интерфейсу (User Experience, UX) показали простой действенный способ вовлечения клиентов на этапах разработки новых элементов. DevOps-специалисты соединили разработку, функциональную часть и тестирование для улучшения качества в новых условиях (разработка и запуск). Их метод также позволяет сократить цикл запуска, снизить риски и повлиять на заказчика.
По сравнению с тем, что мы наблюдали несколько лет назад, сейчас Agile-команды понимают важность исследовательского тестирования. Хотя очевидно, что пользы от него может быть в несколько раз больше. Мы рады, что коллективы, использующие его в работе, делятся своим опытом.
Появились новые, творческие подходы к планированию тестирований и сотрудничеству. Сегодня у компаний куда больше возможностей визуализировать качество. Матрицы и пирамида тестирования адаптированы и расширены для применения в различных областях.
Все больше команд сталкиваются с тестированием мобильных приложений и встроенного ПО на расширяющемся поле устройств и платформ. Огромные объемы информации, содержащие новые технологии хранения, управления, анализа, поиска и визуализации, формируют новую категорию – большие данные (Big Data). И тестирование должно соответствовать новым реалиям.
Изначально Agile подразумевалась как методика для небольших коллективов, работающих в одном помещении. Сейчас мы видим, что Agile используют как крупные организации (нередко начинавшие как маленькие Agile-компании), так и распределенные команды. В организациях с общекорпоративным ПО тестирование сопряжено со строгими ограничениями. В то же время организации находят новые пути использования приложений с минимальным функционалом (Minimum Viable Products, MVPs), обеспечивающим итерационные релизы с быстрыми циклами обратной связи и доступное обучение.
В 2008 году некоторые компании были заняты тестированием в продакшн (на живой среде); мы не слышали об этой технике, если не считать случаев выпуска продукта без тестирования с одной только надеждой на успех. Сегодня выпуск обновлений для небольшого количества пользователей путем изучения логов на предмет ошибок и другие методы получения быстрой обратной связи могут стать важной и необходимой стратегией в определенных условиях.
Все эти изменения и инновации подвигли нас и других специалистов поделиться знаниями и опытом. Agile постоянно развивается, и многие из вас уже внедряют эту методологию, изменяя бизнес-процессы в обучении. Актуальные задачи, связанные с тестированием, во многом отличаются от тех, что вы решали, когда только начинали вникать в Agile. Надеемся, опыт, представленный в этой книге, породит идеи для экспериментов, чтобы можно было визуализировать качество вашего продукта, а затем изучить и адаптировать свои процессы.
РЕЗЮМЕ
С развитием программного обеспечения Agile мы постоянно изучаем и актуализируем методы тестирования. В этой главе мы рассмотрели, как именно менялось Agile-тестирование.
• Мы поняли, что тестирование – это процесс, невероятно важный для успешности продукта, и поэтому в нем должен быть заинтересован каждый член команды: от совета директоров до разработчиков и службы поддержки.
• Команды, работающие по Agile, четко осознают, как специалисты из разных областей (бизнес-аналитики, UX-дизайнеры и DevOps) расширили наши возможности, чтобы добиваться нужного для заказчика уровня качества.
• Инструменты для Agile-тестирования продолжают стремительно развиваться, позволяя Agile-командам внедрять инфраструктуру, необходимую для поддержки обучения и быстрой обратной связи.
• Agile-команды познают ценность исследовательского тестирования и других методов, которые помогают донести необходимую информацию до клиентов и разработчиков.
• Agile-тестирование должно идти в ногу с быстро меняющимися технологиями и новым контентом. Далее мы поговорим об этом.
Правообладателям!
Данное произведение размещено по согласованию с ООО "ЛитРес" (20% исходного текста). Если размещение книги нарушает чьи-либо права, то сообщите об этом.Читателям!
Оплатили, но не знаете что делать дальше?
