Пятничный поток сознания…

Год назад я наткнулся на одно видео про творческие команды. Видео от креативного продюсера 1С Game Studio. Этот материал мне так зашел, что я его пересмотрел раз 5. В видео затрагиваются темы около ИТ, частично - управление командами. Посмотрите, скорее всего оно вам понравится. Накидаю немного мыслей из этого видео, добавлю своих примеров, а вы уже решите, смотреть или нет:

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

Строчка в резюме: я - перфекционист.
Перфекционизм это болезнь. Он не ведёт к результату.
Бывают случаи, когда те или иные вещи делают до идеала. Это может быть стартап, процессы в команде, да что угодно. Имхо — пустая работа. Улучшать можно до бесконечности и никогда не запустить ту или иную сущность. Перфекционизм ведет, в первую очередь, к процессу. Гораздо эффективнее определить MVP, запустить итерацию, снять метрики. После получения метрик можно внести коррективы. Только так можно понять ок гипотеза или не ок. Везде нужен баланс.

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

Биография ууспешных людей — мотиватор / обучатор.
Часто можно найти биографии успешных людей, но обычно, это success story. К сожалению, не вижу в их обучающей ценности. Люди совершают ошибки, это нормально. Если человек выжил и стал успешным, значит его ошибки были не значительны. Гораздо ценнее было бы найти материал, где человек упал и не поднялся. К сожалению таких материалов про ИТ почти нет, если знаете — пришлите в личку. Это самые ценные знания.

То, что ты делаешь — ничтожно.
В ИТ мире мы все очень ранимые и боимся испортить отношения друг с другом. Мы можем видеть, что коллега делает говно, потом этот коллега у нас запрашивает обратную связь, а нам стыдно сказать все честно. Я считаю, что надо учиться говорить людям правду, если они ее у нас просят. ИТ — очень жесткий бизнес, можно сжигать тонны ресурсов, а потом выпустить плохой продукт, который не взлетит. Пожалуйста, научитесь говорить коллегам правду, когда они от нас ее сами хотят.

Руководитель знает, куда мы идем.
Я был по разные стороны баррикад, скажу честно, план есть далеко не всегда. Однако, важно, чтобы исполнялась следующее условие:
1. Команда доверяет капитану плыть в какую-то точку на 100% зная, что у него нет карты.
2. Капитан доверяет команде в том, что команда приложит все усилия чтобы судно не утонуло, понимая, что у всех есть спасательный жилет кроме него.
Если команда думает, что у капитана есть карта, или капитан не доверяет команде - у вас проблема. Очень часто плана может действительно не быть, многие решения могут приниматься на ходу, быстро, без проверенных вводных. Это нормально. У нас активно развивающаяся отрасль, тут платят хорошо только потому, что каждый день мы решаем не стандартные задачи. Делай раз, делай два, делай три — не оплачивается.

Вообще, это видео лучше смотреть вживую. Посмотрите, а потом проставьте лайк или дизлайк. Очень интересно, зайдем вам или нет.
#team

Генерация тестовых данных
Сначала хотел начать историю с 2010 года, однако понял, что первые годы работы я решал совсем просты задачи в области обеспечения качества, поэтому лучше начать с 2014. В 2014 я получил свой первый серьезный офер в большую компанию, это была Mail.ru, проект — социальная сеть «Мой Мир». Многие из вас могут ничего не знать про эту социальную сеть, да это и не важно. Важно то, что нам приходилось тестировать много всего, что связано с юзер-контентом. Надо было иметь большое кол-во тестовых данных, таких как аудио, видео, фото, текст. Все эти данные надо было создавать, и мы где-то, как-то руками, в гугле находили картинки нужного разрешения, вырывали куски текста из книги «Маленький принц», а затем считали символы. Сейчас это все звучит смешно, ведь сегодня есть много генераторов онлайн. Однако, их основная проблема — они очень узконаправленные. Какие-то могут делать только текст, какие-то только фото и.т.д. Какое-то время назад я посмотреть очередной выпуск передачи «Ошибка выжившего» и увидел в разборе крутой генератор - Slothman. Настоятельно рекомендую всем, кто связан с тестированием обратить на него внимание. 6 лет назад мы бы отдали за такое пол царства =)
#web #mobile

​​Легкий вход в автоматизацию...
Автоматизация — очевидный тренд сегодняшнего дня. Возможно кто-то меня закидает камнями, но, сегодня, каждый QA должен уметь программировать. Это мое мнение. К сожалению мой вуз нужных знаний мне не дал и 5 лет назад я пошел учить все сам, с нуля. Главный вопрос для меня в то время был в выборе языка, какой учить? Многие советовали Python из-за его простоты. В поисках материалов по Python я случайно наткнулся на JavaRush. Очень понравилась геймефикация и большая, бесплатная часть по синтаксису. Не Python? Да мне было и не важно. На тот момент я не видел особой разницы, а Java казалась даже круче. Пойдя все бесплатные уроки на JavaRush я попытался приложить это к своей работе, не получилось. Не достаточно базово понимать синтаксис языка, чтобы начать писать авто тесты. Начал искать информацию дальше. Кто-то посоветовал курс Алексея Баранцева — Программирование для тестировщиков на Java. Курс был оплачен моей компанией, и я ринулся в бой. Несколько месяцев пролетели незаметно, я получил огромный набор знаний, а главное, я начал писать заветные авто тесты. Безусловно, приходилось много учить сверх того, что давалось на курсе, ведь на работе надо было решать много не стандартных задачек, но как базис, этот набор (JavaRush + Курс Алексея Баранцева) мне сильно помогли.

Правильный ли выбор я сделал много лет назад? Может надо было учить другой язык? С моей точки зрения - Java лучший язык для моих задач. Мне очень повезло, что я случайно начал учить именно его. Почему я так думаю? Язык это инструмент, а писать тесты можно на разных языках. Но какой выбрать, чтобы раз и на долго, чтобы не переучивается? Давайте подумаем вместе. Глобально, я разделил бы все на три группы:
1. Автоматизация API
2. Автоматизация Web
3. Автоматизация мобилок
Если говорить про API и Web, то тут можно взять почти любой > не особо важно какой учить. Список посмотреть можно тут.

С мобилками сложнее. Про iOS не буду говорить, я под нее тесты не писал, да и рынок не большой, а вот что по Android? Там два больших игрока: Appium и Espresso. На Appium вы можете использовать множество языков, а вот Espresso - нет. Там Java и Kotlin. Важно то, что Espresso движется к тому, чтобы стать стандартом тестирования на Android.
Именно из-за этого я и советую начинать учить сразу Java, хоть он и сложнее. Начнете на Python, все равно будите учить Java, когда дойдете до Android.
Что в итоге? Я рассказал свою историю, а вам то что с нее? Давайте добавим полезности этому посту. Хотите попробовать легко написать свой первый тест на Java? Посмотрите видео и уже через 2 часа у вас будут первые тесты на вашем компьютере.

PS: кроме JavaRush, можете еще обратить внимание на канал voiTi v aiTi. Я сам смотрю с удовольствием, не смотря на то, что синтаксис Java мне уже не особо интересен.
PSS: если то, что я пишу вам кажется полезным, не стесняйтесь поделиться каналом с вашими коллегами =)

​​И снова про Charles!

Какое-то время назад я писал про Charles в этом посте. И правда, Charles очень полезная программа, если вы тестируете мобильные клиенты, это как швейцарский нож. К сожалению, в своём посте, я не раскрыл подробно все возможности этого ПО. Сегодня спешу это исправить. Просматривая Telegram каналы на темы тестирования и управления, я нашёл интересный материал в канале моей бывшей коллеги из Mail.ru Group - Насти, она стояла на страже качества в подразделении Почты. В нем вы можете почитать больше про решению реальных задачек с помощью Charles.

С уверенностью рекомендую вам этот материал. Все новичкам в Charles брать на вооружение.
#mobile

Про выгорание в ИТ

В течение 5 лет я преподавал «Тестирование мобильных приложений» в МГТУ, МФТИ и МИФИ. В процессе преподавания, мне было всегда интересно, а как делают другие, как они выступают? Публичные выступления, это вообще отдельный вид искусства. Наверно именно поэтому я стал вести этот канал. Мне было необходимо место, откуда я мог бы взять материал и дать его своему студенту или коллеге.

В процессе перебора видео разных спикеров, я наткнулся на очень интересный материал. Вадим Макишвили, один из сотрудников Яндекса, рассказал о том, что может ждать людей через 10 лет работы в ИТ. Я был очень впечатлён его выступлением и уверен, что материал, который он рассказывал, будет полезен всем. Он назвал его - 36. Почему так? Это связано с кризисом среднего возраста, но с фокусом на ИТ, и конечно о выгорании. 36 — это его число, часто вижу людей, которых накрывает в нашей профессии и в 25 и в 30. Вадим рассказывает о том, как его самая любимая работа в топовой российской компании, в один момент превратись в ненавистную. О страхах того, что он уже не конкурентный в сравнении с молодыми, о боязни того, что он не делает ничего великого. Многие из вас ещё не столкнулось с этим, но лучше быть к этому готовым. Да, я понимаю, что когда нам 20, то все мы такие карьеристы и молодцы, но как ни печально, подобное может случиться с каждым. Вообще не важно кем вы работаете, дворником или топ менеджером крутой компании.

Пусть это не о тестировании, а о мотивации, это не важно. В ИТ без мотивации знания в тестировании не помогут.
Хороших выходных :)
#free

Selenium - сложный инструмент.

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

Когда я писал тесты, долгое время я не смотрел глубже на то, как это работает. Тесты бегают, они стабильны и ок. Сложности начинаются тогда, когда ты ловишь ограничение / пытаешься решить не стандартный кейс. Я уже писал о том, что начинил я свой путь в автоматизации самоучкой, продолжил по средствам тренингов. Скажу честно, мне повезло с выбором тренинга, это был курс Алексея Баранцева. Интересно то, что он не просто человек который учит, он core developer в проекте Selenium WebDriver, в котором участвует с 2011 года.

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

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

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

Хороших выходных.
#auto

https://youtu.be/4dh--iD_zK8

Немного про выгорание в ИТ.

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

Говоря с сотрудниками разных компаний я понял, что ситуация достаточно массовая. Ещё 10 лет назад я приходил на работу и мы все верили, что наша работа меняет мир людей в России. Сейчас, когда спрашиваешь о том, что человек делает, ответы очень часто достаточно унылые. Очень надеюсь, что это мое субъективное мнение и это только мне не повезло чаще пересекается с такими людьми.

Лично я считаю, что если работа не драйвит / я не верю в то, что делается - надо сразу уходить. Надо уступить место тому, кто будет гореть этим. Только такой человек будет эффективен. Работа должна быть оплачиваемым хобби, только так можно действительно менять мир.

Кому интересно подробнее узнать по выгорание с фокусом на ИТ / как работать с такими сотрудниками - отличное видео от ребят из Badoo
#team

А кто должен писать автотесты?

Обычно я в этом канале что-то рассказываю, но сейчас хочу узнать, а как у вас в компании / на проекте?

Тренд на автоматизацию очевиден. С ними можно деливерить софт быстрее. Для простоты я разделю все автотесты на 2 группы:
1. Юнит тесты
2. Все остальные (api / web / iOS/Android) тесты, отличные от юнит тестов.

По юнит тестам вроде спору особо нет, их обычно пишет разработчик. А как у вас обстоят дела со вторым блоком? Отсюда два вопроса:

1. Кто по вашему мнению должен писать автотесты, отличные от юнит тестов?
2. Кто по факту у вас пишет большую часть подобных тестов?

Заодно вместе посмотрим, как сейчас дела в ИТ секторе по автоматизации :)

Ps: я понимаю, что сложности api тестов и Android сильно отличается, да и на проекте тесты могут писать все. Тут речь на чьей стороне основная ответственность? Кто больше всего кода льёт в репозиторий с тестами?
#auto

Немного про Espresso.

Какое-то время назад зашёл разговор об автоматизации. В итоге эта беседа свелась на автоматизацию Android. После этого у меня очень долго крутились разные мысли в голове на эту тему и вспомнился один доклад с конференции. В 2019 году на Гейзенбаге был очень крутой доклад от Алексея из ВК. В своём докладе он рассказал о всех основных моментах, которые стоит учесть при старте автоматизации на Espresso. Если вы пишете подобные тесты / планируете писать / увлекаетесь автоматизацией - очень рекомендую к просмотру.
#auto

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

Из-за того, что пост про увольнения еще в процессе, хочу поделиться с вами другим интересным материалом. Часть читателей этого канал точно пишут тесты, часть хочет начать. Для тех, кто не пробовал автоматизацию на Android основная сложность связана с непониманием точки старта, с чего начать. Предлагаю откинут дискуссии о выборе инструмента и перейти сразу к делу. Потратив 15 минут своего времени вы сможете запустить свой первый тест на Espresso. Максимум информации и минимум букв.
#auto

Хоть на канале и нет рекламы, но свою вакансию грех не прорекламировать. Если кратко: у нас много интересных задач и мы ищем классного QA.

https://yandex.ru/jobs/vacancies/testing/test_eng_yaauto/

Про увольнения...

Этот пост я хотел написать пол года назад, но все не доходили руки. В итоге писал по одному абзацу в месяц. Увольнения это не самая приятная тема, это всегда не просто. Как это выглядит со стороны сотрудника знают всё, многие из вас увольнялись, кого-то, возможно, увольняли. А как это выглядит со стороны руководителя? В первую очередь я бы разделил это событие не два типа:
1. Когда человек сам уходит
2. Когда его надо уволить

Начнём с самого простого - сотрудник уходит сам.
Уход того или иного сотрудника в моей практике достаточно предсказуемый. На моей памяти только один раз я был удивлён тому, что мне принесли заявление. Самое грустное, что этот случай я долго анализировал и так и не понял, на что я должен был обратить внимание, чтобы это предсказать.
Из-за того, что чаще всего это событие предсказуемо, руководитель может к этому морально подготовится и иметь какой-то план «Б». Какие плюсы и минусы от увольнения по инициативе сотрудника?

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

Плюсы:
1. Новый взгляд на старые проблемы, очень часто новый человек приходит и решает то, что команда не могла долго сделать.
2. Возможность взять человека с другой областью в знаниях (был ручной qa, взяли ароматизатора)
3. Новый климат в команде, новые знакомства всегда всем интересны.

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

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

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

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

Что тут хочется посоветовать:
- Очень важно уходить / увольнять по-человечески. ИТ мир слишком тесен и ты не знаешь, в каком формате вы снова встретитесь. Знаю историю, когда сотрудник ушёл очень плохо от одного руководителя. Через 2 года они встретились в другой компании. Тот, кто плохо ушёл, снова вернутся в статус его подчиненного. Продолжение истории не знаю, но я думаю, как минимум, они оба вспомнили неприятные факты прошлого расставания.
- Максимально открыто говорите о причинах увольнения команде, вся недосказанность начинает генерировать безумные версии.
- Ответственно относится к найму. Некоторые руководители очень любят брать первого более или менее нормального кандидата и увольнять с испытательного срока, если что-то не так. Лично знаю одного такого. Для него это испытание боем. Ок это или нет? Лично по мне - не ок. Сильная текучка в команде + нагрузка на HR + безграничные фантазии тех, кто смотрит на это со стороны. Только богу известно, как смотрится эта ситуация, каждый фантазирует в меру своих возможностей.

Будьте осознанны, много раз взвешивайте всё за и против, а если уж решение понято, старайтесь делать все максимально мягко.
#team

Друзья, сегодня поймал себя на мысли, что все же и правда, все познаётся в сравнении. Этот год, в сравнении с прошлым, был сложным многие из нас узнали, что такое удаленка в первый раз в жизни, многим она не понравилась. Но несмотря на это, ИТ стал тихой гаванью, в сравнении с тем, что происходило в других областях / направлениях / профессиях. Желаю, чтобы 2021 год принёс вам только радость, чтобы все было хорошо у вас дома и на работе.

Поздравляю вас с наступающим Новым годом!

Немного про тест-кейсы
Начало года выдалось очень жарким и совсем не было времени на посты, пора это исправить. Хочется поговорить о тест-кейсах. До работы в Яндексе я не часто сталкивался с тест-кейсами, обычно мы сразу писали авто тесты, поэтому тест-кейсов в чистом виде я видел редко. Несмотря на это, инструменты для хранения и прохождения тест-кейсов типа TestRail я изучал, ведь это было нужно для моих студентов. В Яндексе тест-кейсы активно используются, хранят их в своем аналоге TestRail. Начав плотно работать с подобными инструментами я поймал себя на мысли, что писать и редактировать кейсы в этих системах очень неудобно, надо заходить через интерфейс, нажимать редактировать, править, потом сохранять. Так же была проблема с ревью тестов. Зачем это нужно? Соблюдение единого стиля написания и проверка того, что ничего не забыли проверить. Идеальным вариантом видится путь, когда системы типа TestRail являются лишь оболочкой для прохождения, а текст тестов хранится в репозитории. Если идти по такому пути, то можно легко писать тест-кейсы в среде разработки, а так же использовать все плюсы git для создания pull request. Увидев классное решение мы решили его попробовать. Все, кто успел с ним поработать видят в этом только плюсы. Можно долго писать ок это или нет, но лучше один раз увидеть, чем сто раз услышать. Советую к просмотру видео Артема Ярошенко — Тест-кейсы как код. Возможно вы захотите сделать что-то подобное у себя.

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

https://luxoft-techfest.jugru.org/

Совершенно случайно сегодня наткнулся сегодня в интернете.

Кто занимается автоматизацией точно сталкивался с JUnit. Кто-то использует 4ый, кто-то перешёл на 5ый. Сегодня нашёл очень годное видео на эту тему.
#auto

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

Поехали:
1. Огромный поток резюме разного уровня качества, бывают интересные, бывают так себе, чаще второе. Почему-то кандидаты не всегда замораживаются сделать его содержательными и после прочтения кандидат остается лютым котом в мешке. В итоге нет четкого понимания, стоит ли его звать на собеседование или нет. В итоге, кажется, тратишь очень много времени на совсем нерелевантные встречи. Можно пойти по пути - не звать, но в условиях голода на рынке не всегда лучший путь. Иногда сильные кандидаты как раз и не делают хорошие резюме потому, что не ищут работу. На моей памяти было несколько оферов из очень несодержательных резюме.

2. Многие говорят, что ИТ в РФ, это рынок кандидата. И да и нет. Если кандидат совсем обычный, джун или ранний мидл, то это скорее всего не правда. Для этих уровней это рынок работодателя, слишком много их стало, онлайн курсы «Профессия тестировщик за один день» сильно популяризирует профессию. Если же вы ищите опытных - да, определенно, рынок кандидата.

3. Часто вижу, что джуны и мидлы себя не адекватно оценивают по ЗП. Почему-то многие думают, что их ценность определяется их желанием, либо мнением, что через год они уже «ведущие специалисты». Я бы сказал, что ценность кандидата определяется из микса двух показателей: профит, который кандидат принесет компании и цены, которые дают по рынку. Да, вилка может двигаться, но это должно быть обосновано. В итоге приходит тебе кандидат с запросом в 220 - 250, ждешь уровень «бога». Начинаешь с ним говорит и всплывает, что на позицию мобильного тестировщика он не знает, что такое ADB, компоненты Android и.т.д. По факту выходит, что кандидат с его опытом стоит на рынке в 2 раза дешевле. Проблема.

4. Кандидаты почему-то ленивы, не готовятся к собесам, возможно просто не ищут работу. Например, задаешь классические вопросы по мобильному тестированию: что ты знаешь о жизненном цикле activity - не отвечают. Ну вот как можно не ответить на топ 10 вопросов по профессии в режиме удаленки, они же дают столько возможностей? Если не знаешь ответы на стандартные вопросы то гуглишь список этих топ 10 вопросов по теме и вешаешь шпоры за монитор. Да, глубоко не ответишь, но что-то базовое скажешь, да и в голове что-то отложится, пока писать шпоры будешь.

Вообще на тему зарплат и знаний на входе очень хорошо рассказали на Heisenbug Show / Сколько зарабатывают тестировщики? // 30.03.2021. Кому интересна эта тема - обязательно посмотрите.
И как бонус - забавное фото одного из мест для собеседований QA.
#free