Перейти к содержимому

Тестирование безопасности
онлайн, начало 10 июля
Тестирование мобильных приложений
онлайн, начало 10 июня
Программирование на Python для тестировщиков
онлайн, начало 5 июня
Школа для начинающих тестировщиков
онлайн, начало 11 июня
Фотография

Mid-life career change in QA


  • Авторизуйтесь для ответа в теме
Сообщений в теме: 97

#21 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 22 января 2016 - 19:23

Елена, вы молодец! Удачи вам! И план и курсы - все правильно, я считаю! 

Ольга, спасибо за поддержку! Мне она помогает чувствовать, что я на правильном пути.


  • 0

#22 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 22 января 2016 - 20:13

Мои 7 know-how в QA

 

Предыстория: я руковожу от бизнеса проектом по разработке ПО на новой платформе для ретейл продукта в банке. От момента сбора требований и до окончания тестирования прошло 2 года. Тестирование закончили вчера. Впереди раскатка на сеть. Оглядываясь назад, я сформулировала свои 7 know-how для улучшения качества ПО и процесса работы с ним. Это мой личный опыт и мои открытия. Мне интересно ваше мнение. А как у вас?

 

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

 

2. Юзабилити тестирование - это must have. Никто кроме пользователя не скажет, как и что лучше и удобнее сделать в программе. И даже если в вашей компании до этого юзабилити не проводили, сделайте его сами. 

 

3. IT и UAT тестирование хорошо делать одновременно. Что это даст?  Больше времени на пользовательское тестирование и исправление бизнес-логики и дефектов, а они очень важны, ведь приложение мы сделали не для IT, а для бизнеса. Более сплоченная команда, а значит более эффективная: вопросы решаются быстрее, когда и бизнес и IT тестируют в одной упряжке, бизнес лучше понимает систему, IT лучше понимает бизнес-логику. Почти во всех дефектах необходимо понимать обе стороны. Экономится время, так как тест кейсы делятся между IT и бизнесом. Дефекты разрешаются быстрее: бизнес нашел ошибку, IT выгрузил логи, и вот уже разработчик понял, что не так. 

 

4. Эксперт UAT (это я:)) должен иметь прямой доступ к разработчику в любое время. Если у вас его нет - требуйте. Что это даст? По многим ошибкам работы приложения только бизнес понимает, как оно должно работать (в ТЗ описано не все!). Часто после обнаружения ошибки надо быстро выяснить, что это: дефект, стандартное поведение системы или настройки на тестовой среде? Прямой доступ к разработчику, например по email, позволяет это выяснить за пару минут и пойти дальше: сменить настройки, зафайлить дефект или CR. 

 

5. Приоритеты тест-кейсов. В начале тестирования времени всегда "вагон", и все тест-кейсы можно успеть пробежать. Так кажется. К концу проекта время закручивается в такую спираль, что охватывает паника: сегодня новая поставка и есть два дня на тест. Что тестировать в первую очередь, если функционал приложения описан на 500 страницах руководства пользователя? Я разделила на 4 группы: 

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

      2) регресс тестирование новой поставки - минимальный набор кейсов, позволяющий протестировать базовый функционал. На 3 часа.

      3) краткий бизнес процесс - кейсы тестирующие основные функции + если осталось время, чуть дополнительных. На 2 дня.

      4) полный бизнес-процесс (до этого доходит редко). 1-2 недели. 

 

6. После окончания тестирования все только начинается. Как оказалось разработать ПО и протестировать - это лишь 50% успеха. Его еще нужно раскатать на сеть, чтобы пользователи могли работать с вашим новым ПО. При необходимости мигрировать данные из старого ПО в новое, обучить пользователей и саппорт. А иначе новым ПО просто никто не сможет пользоваться, а вы погрязнете в потоке звонков и писем от пользователей. Здесь кроются главные враги QA - как правило про жизнь после приемки тестирования и релиза уже никто не думает, релиз вышел, чего еще нужно. На деле очень важно начать думать о раскатке и миграции задолго до начала тестирования! Может даже понадобится ТЗ на миграцию и доп.доработки для ее автоматизации и тестирования. Если не подумать заранее, то финишная прямая проекта превратится в дорогу в ад. Увеличив время и деньги проекта. 

 

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

 

Ну и самое главное - это отношения в команде. Активный и грамотный IT PM - это благо. С ним спокойно и комфортно от ощущения, что проект под контролем. Ищите такого и меняйте того, кто не такой. Без помощи друг другу проект не вытянуть. 


  • 0

#23 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 783 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 23 января 2016 - 08:14

 Все интересно описано, но вот это - не очень:)

Эксперт UAT (это я:)) должен иметь прямой доступ к разработчику в любое время.

Со стороны команды разработки я абсолютно против доступа заказчика к разработчику. Есть РП, есть аналитик - пишите требования им.

Прямой доступ к разработчику разрушает цепочку постановки задач и потом в Системе повляются всякие незарегистрированные фичи, которые никто не описывал.


  • 1

#24 Freiman

Freiman

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 543 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 23 января 2016 - 10:02

С таким уровнем знаний и опыта вы явно не начинающий тестировщик. Реально у вас есть 2 года опыта в разработке/анализе требований, проектировании и выполнении тестов и пр.
Продолжайте развиваться и при этом не принижайте свой опыт и знания :)
  • 0

#25 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 23 января 2016 - 14:59

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

 Андрей, привет! Вы все время говорите очень правильные вещи! Я ведь и правда поняла после курсов, что мне нет смысла резко уходить в тестирование. Я поняла, что мой путь - это Product Manager in fintech. Сейчас это так востребовано и у меня все для этого есть: 20 лет работы в банках, свободный английский, опыт серьезных проектов по разработке финансового ПО, высшее экономическое образование, мне осталось набраться знаний в IT, что я и делаю. Спасибо! Моя самооценка после вашего сообщения значительно поднялась:)


  • 0

#26 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 23 января 2016 - 15:02

 Все интересно описано, но вот это - не очень:)

Эксперт UAT (это я:)) должен иметь прямой доступ к разработчику в любое время.

Со стороны команды разработки я абсолютно против доступа заказчика к разработчику. Есть РП, есть аналитик - пишите требования им.

Прямой доступ к разработчику разрушает цепочку постановки задач и потом в Системе повляются всякие незарегистрированные фичи, которые никто не описывал.

У нас все описано в CR (change request) , без этого разработчик ничего делать не будет. А смысла писать кому-то, кто просто перешлет мое сообщение разработчику я не вижу. Это время и сломанный телефон. Когда я пишу разработчику, то ставлю в копию всю команду. Все в курсе происходящего. 


  • 0

#27 Sezam

Sezam

    Активный участник

  • Members
  • PipPip
  • 149 сообщений
  • ФИО:Сергей Атрощенков


Отправлено 23 января 2016 - 16:31

 

 Все интересно описано, но вот это - не очень:)

Эксперт UAT (это я:)) должен иметь прямой доступ к разработчику в любое время.

Со стороны команды разработки я абсолютно против доступа заказчика к разработчику. Есть РП, есть аналитик - пишите требования им.

Прямой доступ к разработчику разрушает цепочку постановки задач и потом в Системе повляются всякие незарегистрированные фичи, которые никто не описывал.

У нас все описано в CR (change request) , без этого разработчик ничего делать не будет. А смысла писать кому-то, кто просто перешлет мое сообщение разработчику я не вижу. Это время и сломанный телефон. Когда я пишу разработчику, то ставлю в копию всю команду. Все в курсе происходящего. 

 

А теперь представьте что экспертов по UAT у разработчика может быть 5. С 3х разных проектов.
И как ему легче и адекватнее будет ответить: получив одно письмо? три по проектам? Или 12 писем по 2м проектам, когда он работает над третьим? :)
И зачем писать разработчику, если "У нас все описано в CR (change request) , без этого разработчик ничего делать не будет. " ? Уже же все описано.


  • 0
С уважением,
Сергей Атрощенков |
@barbaricqa | Email|
Barbaric QA

#28 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 23 января 2016 - 16:56

 

 

 Все интересно описано, но вот это - не очень:)

Эксперт UAT (это я:)) должен иметь прямой доступ к разработчику в любое время.

Со стороны команды разработки я абсолютно против доступа заказчика к разработчику. Есть РП, есть аналитик - пишите требования им.

Прямой доступ к разработчику разрушает цепочку постановки задач и потом в Системе повляются всякие незарегистрированные фичи, которые никто не описывал.

У нас все описано в CR (change request) , без этого разработчик ничего делать не будет. А смысла писать кому-то, кто просто перешлет мое сообщение разработчику я не вижу. Это время и сломанный телефон. Когда я пишу разработчику, то ставлю в копию всю команду. Все в курсе происходящего. 

 

А теперь представьте что экспертов по UAT у разработчика может быть 5. С 3х разных проектов.
И как ему легче и адекватнее будет ответить: получив одно письмо? три по проектам? Или 12 писем по 2м проектам, когда он работает над третьим? :)
И зачем писать разработчику, если "У нас все описано в CR (change request) , без этого разработчик ничего делать не будет. " ? Уже же все описано.

 

Я вам с удовольствием объясню:) Проектов действительно наш разработчик ведет много с нашим банком. И главный мозг от разработчика работает по нескольким стримам. Только в нашем проекте три стрима, я отвечаю за один. И вы правы, бывает, что все три эксперта UAT ему пишут в течение дня. Происходит это так: я тестирую очередной кейс, понимаю, что бизнес-логика не корректная. Далее я на основе ТЗ делаю предварительный вывод, что это: дефект или нам все сделали по ТЗ, а когда начали тестировать, поняли, что надо изменить и тогда это CR. Пишу разработчику, он проверяет у себя (дефект у него может не воспроизводится к примеру), определяет уже точно дефект это или CR, пишет прямо в переписке свое решение, я его согласовываю или мы совместно его меняем и когда обе стороны сказали ОК, я завожу CR в HP ALM и прикладываю переписку и финальное решение. Отправляю номер CR разработчику - все, работа пошла. Потом весь процесс как он по факту реализован описан еще в мануале для пользователей. Понимаете, чтобы в моем случае кто-то вместо меня описал нужную бизнес-логику в системе и указал на имеющуюся ошибку, это человек должен знать продукт, а продукты досконально знают только их владельцы, т.е. я. Верите или нет, но кроме меня это описать некому. Поэтому доступ к разработчику - это жизненно необходимая вещь. По крайней мере у нас в банке. В самом начале тестирования я у разработчика спросила, мол будет много вопросов от бизнеса, ответы на которые IT не знает и не сможет помочь, могу я писать напрямую, он ответил, что конечно пиши. А было подразделение по другому стриму, которое не писало напрямую, а кидало скрины на поддержку, мол ошибка, тестировать не могем:) Знаете чем кончилось? Прошел месяц, а их скрины так и остались в почте. Потом они тоже стали писать напрямую. 


  • 0

#29 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 783 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 23 января 2016 - 22:45

Не очень понятно - разработчик сидит и ждет ваших писем? Или вы отрываете его от текущих задач? Или он все это ставит в свою общую очередь?

Я так понимаю, что у вас это не очень много дефектов/изменений, если вы можете справиться с ними один на один с разработчиком. У нас иногда такие портянки приносили с продакшена, что с ними еще отдельно надо было разбираться, приоритезировать и решать, что будем делать, а что - нет. Один разработчик там точно не справится.

 

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


  • 0

#30 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 783 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 23 января 2016 - 22:47

У нас все описано в CR (change request) , без этого разработчик ничего делать не будет. А смысла писать кому-то, кто просто перешлет мое сообщение разработчику я не вижу. Это время и сломанный телефон. Когда я пишу разработчику, то ставлю в копию всю команду. Все в курсе происходящего. 

 

Аналитик не пересылает ваше письмо, а встраивает ваше пожелание в набор требований. И потом уже пускает в разработку.


  • 0

#31 Vasiliy

Vasiliy

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 2 783 сообщений
  • ФИО:Касимов Василий
  • Город:Москва

Отправлено 23 января 2016 - 22:48

Я сейчас подумал, а мы точно с вами под разработчиком понимаем одного и  того же человека?


  • 0

#32 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 21 апреля 2016 - 12:13

Сегодня со мной произошло чудо!

 

Когда мне в очередной раз дали «быстренько переписать рекламную брошюру» по одному из наших продуктов, я готова была взорваться. Сколько можно быть «универсальным солдатом»? Когда я уже буду заниматься чем-то одним? Ну почему мой американский коллега – Agile Project Manager и Scrum Master - ведет только один проект, а я скромный менеджер продуктов должна писать рекламу, следить за продажами, проводить маркетинговые акции, руководить проектами по доработке софта, организовывать тестирование и самой же тестировать, писать юзер гайды и обучать персонал?

 

В таких темных мыслях я пошла на офисную кухню, попить чайка и почитать что-нибудь расслабляющее. Для этого я открыла главную страницу software-testing.ru и увидела статью «Что должен знать тестировщик в России». В статье меня больше всего заинтересовала фраза о «людях-Т». Я погуглила и вышла на блог Social Tester Роба Ламберта, и на русский перевод статьи, размещенный на software-testing.ru.

 

И вот что оказалось (теперь меня просто гордость распирает):  Я – Человек-Т, а значит с большим потенциалом!

 

Цитирую:

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

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

Тестирование - это больше, чем простой поиск ошибок. Это изучение продукта, исследование его задач, определение нужд рынка (например, А/В тестирование), изучение того, что продукт на самом деле делает, выяснение, подходит ли он для того контекста, в котором его предполагается использовать, улучшение процессов, помощь в дизайне и улучшении продукта, помощь в его поддержке, рекламе и создании потребительской ценности.»

 

Это прямо все про меня! И мои мысли с негативных сразу перешли в позитивные. Но дальше возник вопрос с резюме. Я сделала два вида: полное, где расписан подробно опыт в тестировании и остальной мой опыт как минимум по управлению проектами и продакт менеджменте. Но когда я его отправила на прочтение американским коллегам в QA, они мне сказали, что надо убрать все не касающееся QA и сократить. В итоге получилось второе резюме намного короче и только про тестирование. Теперь я не знаю, что лучше для меня. Все-таки склоняюсь к мысли, что лучше показать весь свой релевантный опыт. Или оба использовать, исходя из ситуации и страны. Может в США действительно надо позиционировать только QA, а в России хорошо показать все.

 

А что думаете вы?


  • 0

#33 Freiman

Freiman

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 543 сообщений
  • ФИО:Андрей Адеркин
  • Город:Йошкар-Ола

Отправлено 21 апреля 2016 - 12:24

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

Было время, я, скромный тестировщик, следил за конкурентами, продумывал фичи, поддерживал сайт и блог, помогал техподдержке, писал статьи и доки, записывал обучающие видеоролики, стоял на стенде на выставках и много чего еще :)

Сейчас иногда даже жалею, что все это кончилось после перехода в другую компанию, где я только тестирую :)

 

Про резюме:

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

Если в проджект-менеджеры, руководители продукта и так далее - то вот тут можно дать волю и расписать вообще все свои достижения :)

Это не зависит от страны, а зависит от позиции.


  • 0

#34 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 130 сообщений
  • Город:Москва

Отправлено 21 апреля 2016 - 12:26

Я тоже читал эту статью, но реальность показывает, нет, доказывает, что на работу берут по конкретным навыкам, а не по универсальности. Как учили нас в универе - знаю ничего обо всем, знаю все о ни о чем. Универсального человека заменить гораздо легче чем узконаправленного. А в резюме указывать лучше то, что вы хорошо знаете, иначе потеряете свое время и работодателя.


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#35 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 471 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 21 апреля 2016 - 12:28

Если вы показываете все навыки, то для многих вакансий окажетесь просто overqualified.

Про убрать смежное при подаче вакансии в компанию США: Мне рекрутер при подготовке к собеседованию в американскую компанию сделал замечание, что я отвечая на вопрос ухожу в смежные области, а этого делать категорически нельзя, ответ должен быть коротким и строго на поставленный вопрос. Возможно просьба убрать все не касающееся QA - про то-же.

Хотя, я думаю что в стартапах американских так-же ценят универсальных специалистов.


  • 0

#36 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 471 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 21 апреля 2016 - 12:38

Я тоже читал эту статью, но реальность показывает, нет, доказывает, что на работу берут по конкретным навыкам, а не по универсальности. Как учили нас в универе - знаю ничего обо всем, знаю все о ни о чем. Универсального человека заменить гораздо легче чем узконаправленного. А в резюме указывать лучше то, что вы хорошо знаете, иначе потеряете свое время и работодателя.

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


  • 0

#37 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 130 сообщений
  • Город:Москва

Отправлено 21 апреля 2016 - 12:48

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


  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#38 Little_CJIOH

Little_CJIOH

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 471 сообщений
  • ФИО:Власкин Павел
  • Город:Санкт-Петербург


Отправлено 21 апреля 2016 - 13:33

Обычный, заинтересованный в результате, а не в количестве сделанных телодвижений рекрутер. Я таких целых 2 знаю :)

 

Оплата у меня по планке старшего специалиста. Ровно сейчас я устроен очень серьезно, хоть и не очень интересно.

При устройстве стек технологий не совпал от слова совсем: RF/Java/Tomcat/Oracle против моих Cucumber/Ruby/Nginx/Mongo/Redis.

Зато я могу порассуждать на тему какие есть риски при использовании рекурсии.


  • 0

#39 Сергей

Сергей

    Гуру

  • Members
  • PipPipPipPipPipPip
  • 1 130 сообщений
  • Город:Москва

Отправлено 21 апреля 2016 - 14:34

Толковая контора.


Сообщение отредактировал Сергей: 21 апреля 2016 - 14:40

  • 0

"Если ты хороший плотник и делаешь красивую тумбочку, ты не будешь прибивать сзади фанеру, даже несмотря на то, что задняя часть повернута к стене, и никто ее не видит. Ты будешь хорошо спать ночью, только если тебе удалось воплотить в своем произведении эстетическую красоту и качество." © Стив Джобс


#40 Dorial

Dorial

    Новый участник

  • Members
  • Pip
  • 53 сообщений
  • ФИО:Елена
  • Город:Charlotte, USA


Отправлено 04 августа 2016 - 16:02

Всем привет!

 

На этой неделе случилось еще одно чудо, и какое! Меня взяли в QA отдел нашего банка! Я теперь QA Lead, мне предстоит многому научиться, но я очень рада происходящему. Хочу отдельно поблагодарить коллег с данного форума, кто помогал своими советами и поддерживал. Также очень благодарна ребятам в тренинга Школа Успешных Тестировщиков. Конечно Михаилу Портнову (я его "100% продукт":), и всем-всем!!!

Можно сказать что mid-life career change состоялся, впереди набор технической экспертизы и большие проекты. Аж голова кружится:)

 

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


  • 1


Здесь может быть ваша вакансия
Реклама на портале
Тестирование юзабилити (usability)
онлайн
Chrome DevTools: Инструменты тестировщика
онлайн
SQL для тестировщиков
онлайн



Количество пользователей, читающих эту тему: 0

0 пользователей, 0 гостей, 0 анонимных

Яндекс.Метрика
Реклама на портале