Тестировщики-гомеопаты или хронические проблемы найма

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


    Когда начинал карьеру, на курсах показывали презентацию с обоснованием необходимости тестирования. Подпись к слайду гласила: «Чем раньше находишь баг в жизненном цикле продукта, тем дешевле его фикс». Рейты тестировщиков ниже, чем у программистов. Наймём тестировщиков → обеспечим качество и сэкономим на разработке. Профит!


    Тестировщики были охотниками за багами. Программисты пишут фичи, готовится релиз, релиз проходит стадию QA. В то время тестировщик «надевал шляпу» реального пользователя и начинал выполнять типичные сценарии. Считалось, что на эту позицию подойдёт человек без технического бэкграунда.



    Скорость разработки современных проектов возросла. Появилась концепция CI/CD. Никого не удивляют проекты с ежедневными релизами. Компании поняли, что ручные проверки не масштабируются. Тестировщики занялись автоматизацией приёмочного тестирования с помощью Selenium или ему подобных фреймворков. Изменение внутренностей скрыто, только бы фронтенд оставался с необходимыми локаторами.


    Так и повелось. У менеджеров автоматизация тестирования ассоциируется с одним навыком: работа с Selenium. В погоне за серебряной пулей они увидели в нём ответ на все вопросы. Рынок подстроился под спрос.


    Мы долго искали в компанию QA-автоматизаторов для тестирования веб-сервисов. Я просмотрел пару сотен резюме и провёл несколько десятков собеседований. Если обобщить впечатления, можно выделить три основных проблемы, которые часто мешают принять человека на работу.


    1. У тестировщиков нет представления об архитектуре проекта


    Здесь под архитектурой я подразумеваю высокоуровневое описание взаимодействий компонентов системы. Условно, по каким «трубам» перетекают данные, где они хранятся и как используются.



    Во время собеседования кандидат может возразить, мол, нам и не требуются знания архитектуры. Работаем с чёрным ящиком. Зачем заботиться о внутреннем устройстве?


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


    пирамида тестирования
    Вариант пирамиды от Мартина Фаулера


    В тестировании чёрного ящика есть такая же ловушка, как и в security through obscurity. Нельзя полагаться только на этот тип тестирования. Продукт может удовлетворять заявленным требованиям, при этом включать большое количество скрытых багов. Тогда по аналогии с безопасностью через неясность, единственным гарантом качества будет наше неведение о том, как система устроена внутри.


    Преимущество тестирования методом чёрного ящика в том, что тесты не зависят от имплементации. Здорово. Но это искусственное ограничение не должно мешать разбираться во внутренностях. Когда тестировщик знает, как работает продукт:


    • Сталкиваясь с багом, он способен локализовать проблему, а не строить гипотезы.
    • На обсуждении новой фичи, он готов дать фидбек, потому что понимает, как новая фича интегрируется с существующими компонентами.

    квадрат Малевича
    Малевич агитирует за тестирование чёрного ящика


    Наверное, всё та же любовь к чёрному ящику привела ко второй проблеме.


    2. Тестировщики не понимают, что происходит внутри браузера


    Нередко возникает ситуация, когда кандидат, у которого Selenium указан в качестве основного инструмента в резюме, не разбирается, как работает браузер и протокол HTTP. Тестирование для таких автоматизаторов — это прежде всего создание скриптов с действиями пользователя. Поверхностный подход, который создаёт лишние ограничения.


    Примеры HTTP-кодов и типы HTTP-запросов большинство соискателей называет. Следующий вопрос чаще всего ставит в тупик.


    Есть страница логина. Пользователь вводит корректные данные для авторизации и кликает на кнопку входа. Что происходит в браузере в этот момент? Почему последующие действия с сайтом не требуют повторной авторизации?


    Если тестировщик не ответил на эти вопросы, у меня закрадывается сомнение в его компетентности. Это говорит о том, что кандидат:


    • не может тестировать продукт без UI;
    • не умеет пользоваться Developer Tools в браузере;
    • не привык выяснять причину бага (фронтенд или бэкенд).

    Разработчику будет проще пофиксить баг, если он описан с техническими деталями.


    3. Халатное отношение к тестовому коду


    «Мой код не попадёт на продакшен, зачем заботиться о качестве?»
    Мне видится это попыткой разделить песочницы. Пускай разработчики заботятся о чистоте кода, а мы как умеем.



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


    С приходом Agile команды консолидировались. Пропали «мы» и «они». Команда отвечает за конечный результат. А раз инженерные практики стали общими, то и требования к коду тестов должны выдвигаться такие же, как к коду продукта.


    Для отсева кандидатов мы отправляли тестовое задание без дедлайна:


    Создайте на гитхабе Java проект с четырьмя наиболее важными функциональными тестами для списка задач http://todomvc.com/examples/react/

    Список типовых ошибок


    • Лишние усложнения
      Нагромождение абстракций, врапперов над классами и бойлерплейт код внутри тестов.
      Тестовые методы лучше делать максимально короткими. В этом помогут функции-хелперы и отделение сетапа от действий над объектами и проверками.


    • Нарушение конвенций по именованию классов, методов, переменных
      CamelCase в перемешку с подчеркиваниями. Так сейчас не носят. Линтеры и подсказки IDE спасают.


    • Хардкод путей к вспомогательным ресурсам


      String exePath = "Chrome_driver/chromedriver.exe";
      System.setProperty("webdriver.chrome.driver", exePath);

      Классическое «на моей машине работает».


    • Хранение бинарных файлов внутри репозитория
      Для решения этой проблемы есть git-lfs.


    • Отсутствие консистентности в методах
      В одном из решений кандидат описал методы для удаления и пометки «выполнено» так:


      public void DeleteTask(String task)
      ...
      public void CompleteTask(int taskno)

      В первом методе передают текст задачи, во втором — индекс в списке. Пользоваться таким API больно.


    • System.out.println() для логгирования
      Не даёт вспомогательной информации, в каком классе произошло событие.


    • Использование Thread.sleep
      Для решения этой проблемы есть библиотека awaitility. Она помогает добавить обратную связь к ожиданию выполнения необходимого условия.


    • Общие исключения вместо асертов
      Пример: тест добавляет несколько пунктов в список задач и отмечает все пункты как выполненные. Идея в том, что в случае проблем, метод findElement вернёт NoSuchElementException и тест свалится. Если позже посмотреть на результаты прогона тестов, NoSuchElementException введёт в заблуждение: непонятно, по-настоящему тест упал или код теста кривой. Нужно использовать асерт с понятным сообщением об ошибке в случае падения теста.


    • Злоупотребление асертами с булевыми значениями
      assertTrue или assertFalse используется для всего подряд:


      assertTrue("One To Do item should be added", toDosPage.getToDoListCount(false) == 1);

      Здесь лучше использовать assertEquals, чтобы иметь контекст при падении теста.


    • Не предусмотрена параметризация запуска тестов
      Пример: URL сайта для тестирования прибит гвоздями в коде.



    Отдельно стоит упомянуть работу с git. Чаще всего задание присылали одним коммитом. Писать понятные коммит-месседжи и разбивать большую задачу на несколько обособленных — необходимый навык, особенно в командной работе.


    Выводы


    Описанные выше проблемы — мой личный опыт и впечатления после собеседований. По наблюдениям годы опыта кандидата никак не коррелирует с количеством пробелов. Избегайте тестировщиков-гомеопатов, инвестируйте время в прокачку технических навыков сотрудников. Тестировщикам есть, чему поучиться у разработчиков и наоборот. Да прибудет сила с теми, кто строит инженерную культуру и плывёт против течения.


    Я буду рад ошибаться и счастлив, если в вашей компании с наймом всё по-другому.


    UPD 11/02/20: На вебинаре «Портрет тестировщика» делюсь мнением о том, как вижу профессию изнутри.



    • Почему бизнесу нужны тестировщики?
    • Роль тестировщика в команде
    • Ручное VS автоматизированное тестирование
    • Привлекательные стороны профессии и цена опыта
    • Необходимые хард/софт скилы
    • Ошибки в резюме начинающих специалистов
    • Девопс в тестировании
    • Карьерный рост

    Only registered users can participate in poll. Log in, please.

    Вы сталкивались с похожими проблемами при найме инженеров по качеству?

    • 72.2%Да. Тяжело найти технически подкованных людей78
    • 27.8%Нет. Это выдуманные проблемы30

    Similar posts

    AdBlock has stolen the banner, but banners are not teeth — they will be back

    More
    Ads

    Comments 30

      +2
      Следующий вопрос чаще всего ставит в тупик.
      Есть страница логина. Пользователь вводит корректные данные для авторизации и кликает на кнопку входа. Что происходит в браузере в этот момент? Почему последующие действия с сайтом не требуют повторной авторизации?

      Всегда задаю этот вопрос для определения уровня понимания работы браузера у тестировщиков которые указывают что работают с вебом, не важно ручные или авто. И да, отвечают ну очень крайне малое количество людей :(
      Вообще техническое рахвитие у тестировщиков по моему опыту крайне слабое, большинство становятся «незаменимымыми знакоками продукта». Но их знания бизнес логики их текущего проекта не обеспечивают им ту сумму котороую они обычно хотят.
        0
        По моим наблюдениям люди с 10+ годами опыта на собеседованиях отвечают хуже кандидатов 3+. Они «застывают» на каком-то этапе технической компетенции и как вы выразились, почивают на лаврах «незаменимых знатоков продукта».

        Проблема с такими кандидатами — желание учиться и переучиваться. Они уже привыкли забивать гвозди микроскопом.
        +8
        1) Статья не имеет смысла, без указания зп, которую вы предлагаете тестеру. Ибо за одни деньги тебе будет и динамика параметров, и степобджекты и пейджобжекты, и конвекторы и прочие сладости хорошего проекта (да еще разрабов будет пинать, что его рест-апи для хвостов не очень качественный). А за другие деньги будет хорошо, если человек знает базовый html/css/js.

        2) Обычно нанимается один хороший QA-лид, который делает весь каркас проекта и задает планку качества, а остальные тестеры его расширяют под строгим код ревью. Требовать, чтобы каждый мог также четко, как QA-лид — идиотизм.

        3) Примеры из статьи — бесполезные. Ибо один раз хватит человеку показать, как надо (а еще лучше дать пачку готовых методов), и он будет писать так, как нужно.

        4) На обсуждении новой фичи, он готов дать фидбек, потому что понимает, как новая фича интегрируется с существующими компонентами.

        — Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

        Такое ощущение, что писал статью человек, который в жизни не отвечал за QA в крупном проекте, и не работал с командой тестеров, если их больше 2-3.
          0
          Я что-то пропустил упоминание размеров проекта.
          Обычно нанимается один хороший QA-лид, который делает весь каркас проекта и задает планку качества, а остальные тестеры его расширяют под строгим код ревью.
          Если под «обычно» подразумевается «чаще всего», то обычно QA отдел начинается и заканчивается этим самым QA-лидом. Зачастую он же становится техническим писателем, и, как следствие, обладателем наиболее полного представления о бизнес-логике всего проекта. Что приводит нас к пункту 4.

          P.S. Да, это очень печально, да это не правильно. Но что поделать — обычно и правильно это все же не одно и то же.
            +1
            Требовать, чтобы каждый мог также четко, как QA-лид — идиотизм.

            Можете раскрыть, почему вы так думаете?
            На длительный проект, на мой взгляд, лучше нанять четверых крутых тестировщиков, чем десяток послабее.
              0
              Да тут ситуация как с разработкой — 4 сениора, 7 мидлов или десяток джунов?
              Лучше взять одного крутого, четверых послабее, и двух почти начинающих.
                0
                Джоэл Спольски в своей книге «О программировании» топит за то, что лучше не нанять подходящего специалиста, чем нанять не подходящего. К сожалению, это так.
                Конечный результат от четырёх толковых чуваков лучше, даже если кого-то толкового на этапе интервью отсеют.
                  0
                  Ага, пусть текущий программист лучше сляжет от переработок на 3 должности, а после больницы уйдёт подальше, пока ещё жив. /sarcasm
                  IMHO, конечный результат больше зависит от процессов: если выстроены процессы и любого программиста сначала натыкают в соглашения по коду, потом в собранную библиотеку методов и классов под проект и после — в гит с готовыми тестами и скажут «делай не хуже, если что-подходи, код-ревью по четвергам» — то нужно быть совсем уж неподходящим человеком, чтоб сделать плохо.
                  Ну а если галера снизу затоплена, посредине — уже горит, а сверху догружают техдолг — нужен суперджедай, чтоб разгрезти всё и сразу.
                0
                1. На инженерные вакансии в компании ± одинаковые рейты. В нашем случае предлагается зарплата middle/senior разработчика.
                Трюк в том, что на эти условия всё равно не найти ковбоев, стреляющих из двух рук.

                2. Большие компании могут себе позволить обучение, взращивание специалистов внутри. Мы ищем опытных и самостоятельных специалистов.
                Предположим, уровень программирования у человека хромает, это наживное. Но что делать с первыми двумя пунктами? Мне не кажется сверх-требованием просить рассказать архитектуру проекта и как браузер запросы гоняет. Это базовые вещи.

                один раз хватит человеку показать, как надо

                3. Значит мне всё время встречаются неправильные люди. Они где-то учатся плохим практикам и продолжают тащить свои знания сквозь годы опыта.

                А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

                4. У тестировщика в голове есть целостная картина о продукте. Если к этому добавить технический бэкграунд, он готов дать ценный фидбек о новой фиче. Потому что у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.
                  0
                  У тестировщика в голове есть целостная картина о продукте… у рядового разработчика знаний о продукте меньше, он пилит свою часть: компонент/сервис/etc.

                  вы только не забывайте, пожалуйста, что это специфика вашего проекта/компании.
                  А у многих команды QA+front+(1-3)back пилят свою часть, и знаний о продукте в этом случае у тестировщика и у разработчика примерно поровну… отсюда и столько удивления )
                  0
                  Чего бл**ть. А давайте еще тестер будет вам архитектура проекта писать, и вести утренний митап.

                  У некоторых аналитики и тестировщики — это одна сущность. Конечно, кампании сами себе злые буратины в таком случае.

                    0
                    Я скажу больше. Менеджер проекта — аналитик, тестировщик, глава отдела по связям с клиентами, глава отдела по связям с общественностью. И да, в таких компаниях найти документацию для составления тестов актуальной версии программы — нельзя от слова «Agile в течении 6 лет».
                    0
                    «Ронда» так тестировщиков нанимает ещё с 2016. В вакансии пишут " ничего не надо". А по факту, как давай меня гонять по всяким алгоритмам, прям будто собеседование в гугль на senior developer
                    0
                    Есть некоторая грань на которой лучше нанять разработчика, который будет тестировать свой код, чем нанимать плохо пишущего QA инженера.
                      +1
                      Согласен. Есть примеры, когда компания обходится без QA. Культура разработки, тесты, CI/CD — если всё присутствует, это круто.
                        +1
                        В основном такой подход больше применим для разработки бэкенда, где тесты написать достаточно просто, а с UI и приложениями всё может быть не так очевидно и просто
                      0

                      Требовать от простолюдина качеств благородного дона, да ещё и за простолюдинскую зярпляту, это знаете…
                      Бизнес требует? Ну тогда и решение проблем должно быть чисто управленческое, выше в комментариях адекватный пример приведен.
                      Ведь со всеми вашими хотелками, сотрудник уже не простолюдин, но дон благородный, требующий соответствующего обхождения.
                      Он ещё и прибавку потребует за вредность и унылость производства :-)

                        +5
                        Я не верю, что с таким подходом инженер придумает все возможные тестовые сценарии. Если знать внутреннее устройство продукта и читать код, можно избежать дублирования тестов на высоких уровнях пирамиды тестирования.

                        Забавно, что это ровно основной аргумент против того, чтобы программист сам тестировал свой код) Мол раз ты знаешь свой код, значит будешь писать тесты так, чтобы они этому коду соответствовали)

                          0
                          Есть такой момент. В идеале отлавливается на код-ревью.
                          0
                          Когда я устраивался тестировщиком, пять лет назад, были еще места для «ручных» тестировщиков. Сегодня к навыкам тестирования требуется и навык автоматизации. «Сбывается» то, о чем давно говорит James Bach. Нет никакого «ручного» и «автоматизированного» тестирования. Есть тестирование, и тестировщик, который, должен (постоянно) развивать себя, и пользоватья инструментами, там где это необходимо.

                          Должен сказать, ручные тестировщики смотрятся сегодня чуднó. Даже имея сильнейшее искреннее желание, они не в состоянии держать темп и развить необходимой эффективности, учитывая экспоненциальный рост сложности приложений, и повышение частоты изменений. Бизнес не имеет права идти на уступки в этом плане, иначе он отстанет от рынка. Я бы вообще упразднил такую должность.

                          Иметь и ручных тестировщиков и автоматизаторов вообще мрак. Приходится обьяснять, что у нас автоматизированно, сверять ручные тесты и обьяснять почему их нельзя автоматизировать. Столько ненужной канители. Как было бы удобно, если бы все имели одинаковый навык, не пришлось бы ничего никому обьяснять и ни с кем цацкаться. Обьем работы виден. Сдал код — значит работаешь. Нет кода — или затык или балду гоняешь.

                          Многие проблемы в приложении вскрываются когда начинаешь автоматизировать. При ручном тестировании, заложенные в человеке эвристики обходят эти проблемы. А автомат бездушен, беспристрастен, и тем хорош. Он всегда делает одно и то же. Он не закроет «мешающее» всплывающее окошко, а остановится и вынудит тебя выяснить в чем дело. И это заставит тебя узнать что-то новое о приложении. Знание приложения — первичное знание тестировщика.

                          Мои автоматизированные тесты «знают» о приложении больше, чем наши ручные тестировщики. А о старых версиях знают иногда больше чем разработчики. Я всегда могу сказать, что было протестированно и как. Это такая возможность. Нельзя ей пренебрегать.

                          А какие бы они тест-кейсы писали если бы умели автоматизировать. Машина все понимает однозначно, программист все понимает однозначно. Как удобно. Зачем эта архаичные многословные романы в экселе. А еще хуже немногословные огрызки с потугой на тест-кейсы. Некоторые сляпаны так, что другой человек по написанному не сможет его выполнить.

                          Вы не поймите неправильно. Я за правильное применение человеческой силы на производстве. Когда у тебя есть автоматизация, ты можешь заняться ручной проверкой особенно интересных и важных, но сложно автоматизируемых сценариев. Это интеллектуальный труд. Когда у тебя нет автоматизации, ты елозишь по регрессии, и сжигаешь этим человеческий ресурс. Простите, но по большому счету, ручное тестирование регрессии, это унизительное занятие для человека, как живого существа, в сравнении с его реальным умственным потенциалом.

                            0
                            Должен сказать, ручные тестировщики смотрятся сегодня чуднó.

                            Я бы вообще упразднил такую должность.

                            Exploratory testing в качестве основной задачи, но не для регрессии, согласен.

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

                            Самое печальное, у человека нет времени заниматься чем-то интересным и прокачивать навыки. Тут как в известной книге:
                            Нужно бежать со всех ног, чтобы только оставаться на месте, а чтобы куда-то попасть, надо бежать как минимум вдвое быстрее!
                            0
                            По наблюдениям годы опыта кандидата никак не коррелирует с количеством пробелов
                            На какую зп искали?
                              0
                              На зарплату middle/senior разработчика.
                              0
                              Большинство обозначенных проблем покрываются либо наймом разработчика на соответствующие задачи, либо наймом адекватного тестировщика, способного на освоение новых инструментов. В поиске такого тестировщика и состоит суть собеседования. Даже если кандидат практически не соприкасался с какими-либо задачами, всегда есть возможность прощупать как работают его мозги на наводящих хайлэвельных вопросах.

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

                              Другое дело, если нет времени на такого тестировщика, которому можно выделить время на вливание в инструментарий, но уверен, все решаемо с помощью зп.

                              Целиком поддерживаю Terras c его комментом.

                              А вам желаю определиться с тем, кого же вы в итоге ищите.
                                +1
                                Полностью согласен с автором статьи.
                                Технический бекграунд большинства QA инженеров (особенно долго работающих в аутсорсе) очень и очень ограничен.
                                Пару комментариев.
                                1. Несомненно все упирается в ЗП. Если хочется нанять кандидата — который за 5 минут проанализирует и нарисует UML диаграмму всего работающего приложения и распишет где-что может потенциально отвалиться (плюс может это и автотестами покрыть) — то такой специалист будет стоить явно не 200$.
                                2. Очень много кто из работающих тестировщиков понимает, что все это надо знать. Но он уже «прижился» в своей компании — и спокойно плывет по течению. Ему не нужно учиться новому, ему не нужно улучшать скиллы (мотивации нет). Просто расслабься и работай. Обратная сторона раскрывается — когда такой кандидат выходит на поиски новой работы и осознает, что его 5+/10+ лет опыта в узкопрофильной банковской системе мало кому интересны.
                                3. Пока компании берут тестировщиков на разные деньги и с разными уровнем — такие люди и будут. Для отбора «топовых» кандидатов — надо работать над технологическим брендом компании, внимательно собеседовать, давать тестовое задание и тд.
                                4. Курсы тестирования как раз и способствуют появлению множества таких «знаю только черный ящик и селинум => хочу много денег» тестировщиков на рынке. Да еще сразу — после трех месяцев обучения.
                                  0
                                  Нынче разработчика под такие требования найдёшь не сразу, а тут от QA их хотят :-D
                                    +1
                                    Мне в целом нравится подход когда QA в продуктовой команде и проводит ручное тестирование и пишет тесты на готовую стори/баг из своего спринта (при условии что есть готовый фреймворк, который написал кто-то из AQA/SDET).

                                    Это правда надо в definition of done задачи закладывать и включать в оценку задач спринта, да и часть тестов (особенно unit, которых больше всего в пирамиде) должны разработчики писать, а qa могут подсказать какие-то дополнительные проверки в них.

                                    Но чаще видел когда автоматизаторы отдельно, а ручное тестирование отдельно.
                                      0
                                      Вы описали фактически разработчика, это уже не QA manual или auto, это уже Developer in test. Вот если я допустим такой тестировщик как вы описали то зачем мне париться и идти в тестеры если у разработчика и вакансий больше, и прав и уважения и денег. И программист у всех на слуху, их релоцируют даже. Все маломальски технически грамотные QA переходят в разработку, хотят они того или нет. Остаются мануалы, автоматизаторы-гоняторы постманов и селенидов.
                                        0
                                        Первые два пункта не о разработчике, последний про автоматизацию с использованием готовых инструментов. SDET в моём понимании делает инструменты для тестирования.

                                        … вакансий больше, и прав и уважения и денег.

                                        У каждого свои приоритеты. Если нет уважения, есть два варианта: либо не та компания, либо не успели завоевать авторитет.

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

                                        Возможно, не все компании готовы платить. Это другая проблема.
                                          0
                                          Знаю несколько отличных тестеров с многолетним (лет около 15) опытом, которых даже +40% зп не переманили в разработку: девушкам не хочется постоянно писать код, а писать тесты — наоборот.
                                          Спрашивал — чем написание кода в QTP/Selenium/Rational robot лучше, чем та же разработка, отвечают, что сменой занятий: надоел код — тестишь ручками, надоело всё — смотришь сериал. Ну а денег и так хватает.

                                        Only users with full accounts can post comments. Log in, please.