Отчеты, отчеты и еще раз отчеты.

Когда я начинал работать в тестировании, многих инструментов, которые есть сейчас, не было. Работа была не такая удобная.

Один из таких инструментов - Allure, система отчетов автотестов, который стал самым популярным в своей области. Основная задача Allure - сделать процесс автотестирования прозрачным для всех, от тестировщика до менеджера продукта. Какие основные проблемы решает Allure?

1. Мануальные тестировщики не знают, насколько автотесты соответствуют написанным тест-кейсам.
2. Мануальные тестировщики не знают, что именно покрывается автотестами, а что нет.

Почему эти две проблемы имеют место быть? К сожалению, в индустрии, до сих пор есть разделение на ручных тестировщиков и автоматизаторов. Ручные тестировщики, зачастую, не умет программировать, а следовательно, им сложно понять, что происходит в автотестах. Если вы - ручной тестировщик, у вас где-то отдельно живут автотесты, а прогоны этих тестов вы не видите, советую посмотреть два видео про Allure под постом.
Если не очень любите смотреть видео - вот статья.

Скорее всего, вам понравятся возможности этого инструмента, и вы задумаетесь о его использовании у себя.
Хороших выходных!
#auto

История о том, как в Одноклассниках начали работать с QA стажерами

Очень часто слышу о том, что стажеры в тестировании - зло. Почему люди так думают? Классические тезисы по этому вопросу:
1. Стажеры ничего не знают.
2. Они съедают время ментора.
3. Они не стабильны в посещении работы.
4. Они могут уйти, ибо растут быстрее, чем компания может им предлагать новую заработную плату.
5. Им может надоесть профессия, перегорят.
6. И.т.д.

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

Подробнее, о том, как это делалось в ОК можно посмотреть в моем выступлении на Гейзенбаге.

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

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

Дивный мир мобильного тестирования...

Так исторически сложилось, что большую часть своего времени в тестировании я провел работая с мобильными приложениями. Когда я начинал, это было очень молодое направление, материалов практически не было. Android и iOS только набирали свою силу, мобильный интернет становился доступнее с каждым днем. До сих пор храню дома HTC Desire HD, один из первый Android устройств. Сейчас 4-ая версия Android считается морально устарелой, а кто-то ее даже в глаза не видел. На моем музейном экспонате (HTC Desire HD) стоит Android 2.2 :)
Возвращаясь к тестированию мобильных приложений о оборачиваясь назад, сразу приходят на ум строчки:

Мы все учились понемногу
Чему-нибудь и как-нибудь (с)

На дворе стоял 2014-ый год, все говорили об олимпиаде в Сочи, событиях на Украине, я же вышел на новое место работы и искал, где больше узнать про мобильное тестирование. К моему удивлению я нашел отличный доклад на русском языке с конференции LoveQA. Делали его ребята из Badoo и назывался он: «Наш опыт тестирования мобильных приложений». Несмотря на то, что докладу уже более 6-ти лет, он еще имеет актуальность и может быть полезен, как введение в специальность. Основная тема — жизнь после релиза. Если вы практически не имеете опыта в мобильном тестировании, хотите расширить свой кругозор или понять, как примерно это все делается, это видео для вас.

PS: доклад надо смотреть с пониманием того, что он был снят в 2014-ом году.
#mobile

Мнение некоторых разработчиков о QA

Делюсь цитатами:
🚫 Есть только один путь развития ручного тестировщика - автоматизация.
🚫 Если тестировщик пишет автотесты - он мидл. А вот мануальный - вечный джун.
🚫 Тестировщику не требуется никаких знаний, его обязанности может выполнять программист или аналитик.
🚫 Тестировщики с опытом работы 10 лет - миф. Профессии лет 5, не больше.

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

First case:
Я убежден, сегодня QA должен уметь программировать. Однако, есть много случаев, когда это не обязательно. Не каждый мобильный продукт на стадии зарождения вы будите автоматизировать. Рациональности в этом, зачастую, нет. Автотесты не находят всех ошибок. У человека есть то, что робот не умеет и не будет уметь - эмпатия. Получить впечатление от продукта может только человек. В ближайшем будущем ручного труда будет меньше, но он не уйдет полностью. Последние три года я относительно свободно пишу тесты на API, Web и совсем немного, с горем пополам, на Android. Автоматизатором себя не считаю. Ущербно тоже, и вам не советую. На пике карьеры ручного QA, вы спокойно заработаете свои 150. Вообще про разные ветки QA хорошо написано в книге «Как тестируют в Google», приложу ее под постом ниже.

Second case
Очень странно мерить грейд QA по знанию языка. В России QA вообще делятся на ручных и автоматизированных и ветки их развития очень разные. Очень часто, ветка развития ручного QA в менеджеры, а ветка развития автоматизатора, в разработчики. Знания языка и грейд, зачастую, не коррелируют. Не буду спорить, что автоматизаторы, в большинстве своем, зарабатывают больше ручных тестировщиков. Но к грейдам это никакого отношения не имеет.

Third case
Разработчик и аналитик конечно могут выполнять работу QA, с таким же успехом QA может выполнять работу аналитика и разработчика. Вопрос эффективности. Я вот кнопки рисовал и скруглял на web портале, даже сайт верстал. Я стал front-end разработчиком? Нет. Еще, я кран на кухне менял, я сантехник? Машину чинил, я механик? Разработка это про технологии, про головоломки, про алгоритмы. Тестирование про людей, про коммуникацию, про процессы, про юзер стори. Тестировщику нужны знания, очень много разных. Да, им надо меньше уметь программировать, но им надо больше про soft skill. И так, как я выступаю на стороне тестирования, то скажу в защиту: развить soft skill гораздо труднее, чем hard skill.

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

Глобально, я думаю, что работа QA не достаточно оценена. Когда все ок - это данность, когда все плохо - виноват QA. So sad...

Кстати, вспоминается притча:

Однажды Пабло Пикассо ужинал в ресторане. Его узнала одна из посетительниц и подошла к художнику с просьбой нарисовать что-нибудь для неё прямо сейчас. Пикассо взял карандаш, салфетку и сделал набросок городского пейзажа.
Когда женщина протянула руку в надежде получить рисунок, художник сказал:
- Он стоит десять тысяч долларов.
- Как?! Ведь Вы потратили на него не больше 10 минут! – возразила женщина.
- Я потратил на него 50 лет и 10 минут – ответил художник.

Это история о ценности опыта и кажущейся обывателю легкости, с которой настоящий профессионал выполняет свою работу.

#free

Оптимизация фотографий

Существует две основные проблемы мобильного интернета для использования на телефонах:
1. Качество (скорость, стабильность и.т.д.)
2. Ограниченный трафик

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

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

Может показаться, что мобильный интернет идеальный везде, но нет.
В маленьких городах России, в других странах мира все не так классно. Да зачем далеко ходить, выезжаем за МКАД и на себе ощущаем плохое качество соединения.

Что же с этим делать, чтобы наши продукты работали лучше? На качество связи мы особо повлиять не можем, но можем оптимизировать приложения, которые разрабатываем. Прежде всего надо понять, что является основным источником трафика. Зачастую, это картинки. На последнем Гейзенбаге услышал очень интересный доклад от компании Badoo. В докладе рассказывается об опыте оптимизации загрузки изображений, показываются примеры и объясняется каждый из них. Доклад очень интересный и если вы хотя бы раз меняли качество изображения у картинок на компьютере в Paint, без капельки сомнения рекомендую к просмотру. Если понравился доклад - обязательно отправь другу / подруге ;)
#mobile
@myCodeIsPerfect

Сколько вы зарабатываете? (С) Дудь
Вопрос денег интересует всех. Сколько я должен получать на старте? А через год? А через пять? Все зависит от знаний и вашего желания заниматься самообразованием. Примерные данные опубликовали в этой статье.

В целом, для рядовых специалистов, картина похожа на правду. Не буду вдаваться в философию, однако, если у вас сильное отклонение по ЗП в ту или иную сторону, то это, скорее всего, значит одно из:
1. Вы большой молодец и знаете много > много получаете, возможно, у вас все ок.
2. Вы большой молодец и продали себя дорого > много получаете, возможно, стоит задуматься о подкреплении ЗП знаниями.
3. Вы недооценены на этом месте работы > возможно, стоит обсудить свою ЗП с начальником / рассмотреть новое место работы.
4. Вы не развиваетесь > возможно, за стаж работы ЗП не поднимают, только за заслуги или новые обязанности.
5. Тут может быть ваш вариант ответа

Как вы думаете, цифры в опросе соответствуют реальности? Опрос анонимный, никто, в том числе я, не узнает автора ответов.
#free

Давайте уволим всех тестировщиков (с) 

Ввиду того, что надо было купить 100 коробок гречки и ещё больше туалетной бумаги, не было времени написать пару строк. Буду исправляться. Поговорим на сложные темы.

В последние годы часто слышу фразы: «Давайте уволим всех ручных тестировщиков и сделаем автоматизацию». Откуда такие идеи? Сегодня автоматизируют или хотят автоматизировать почти все: сборку машин и техники, работу пылесоса, кормушку для животных, и конечно тестирование. Если это можно сделать, то многие думают: «Почему нет?». Кроме этого, это стало так часто обсуждаемо, ввиду трансформации мира в целом. Как сказал CEO Microsoft:

«Every company is a software company. You have to start thinking and operating like a digital company. It’s no longer just about procuring one solution and deploying one. It’s not about one simple software solution. It’s really you yourself thinking of your own future as a digital company». 

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

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

Что можно сделать в данной ситуации специалистам по ручному тестированию? Надо тоже трансформироваться. Вспоминаю себя 10 лет назад и понимаю, что с теми знаниями, с которыми меня брали на первую работу, сейчас бы уже не вышло. Ожидания от QA сильно выросли за последние 10 лет и будут расти. Уже сейчас на собеседованиях джунов спрашивают как работает клиент - серверное приложение, что такое протокол HTTPS. Когда топор был тяжел, достаточно было уметь написать тест-кейс и жать на кнопки в произвольном порядке. Сегодня этого недостаточно, надо думать и знать много смежных областей. Завтра с нас попросят больше, например знания языков программирования на начальном уровне, ведь все хотят автотесты и быстрее релизить :) 

Кто-то может подумать: «Я 10 лет проработал ручником и проработаю еще 10 так же». Возможно, но конкуренция будет уже другая. В некоторых средних школах уже сейчас преподают языки программирования, например Java, как вам такое? Через 10 лет сегодняшние школьники выйдут на рынок труда и вы будете конкурировать ними. С этими 20 - летными, горящими, без семей и с огромным кол-вом времени на работу людьми. 

Возможно я немного сгустил краски, да и вообще, это не призыв к действию, это скорее просто «на подумать» во время карантина. Ну, а в дополнение, скину вам материал с Гейзенбага на подобную тему, выступление Баруха всегда очень интересные.

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

​​Немного о Pairwise Testing

Много лет назад я работал в большом зеленом банке. Типичная задача — проверь форму с миллиардом полей. Как быть, ведь банк — это ответственность? Возможно, надо вернуться к истокам и перебрать все возможные варианты? Не наш метод, ведь есть Pairwise Testing.

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

Pairwise testing — это техника формирования наборов тестовых данных. Заключается она в следующем: формируются такие наборы данных, в которых каждое тестируемое значение каждого из проверяемых параметров хотя бы единожды сочетается с каждым тестируемым значением всех остальных проверяемых параметров. (с)

В основу этой техники легло понимание того, что большинство дефектов можно найти при взаимодействии всего двух пар. Например, IBM провела исследование и выяснила, что до 97% дефектов можно найти при помощи Pairwise. Ссылку на первоисточник можно посмотреть ниже.

Звучит непросто. В дополнение к этому все говорят о каких-то сложных вещах вроде ортогональных матриц или скидывают ссылки на неработающие приложения.

Как и обещал, полезные материалы:
1. PICT — консольное приложение, очень хорошо использовать для работы с большими наборами данных. Инструкция присутствует, полностью рабочий вариант.
2. Sqamate — online вариант генерации. Никаких знаний не надо, вставляй данные и получай результат. Если вы ручной QA, вам этого скорее всего хватит.

Надеюсь, что этот небольшой материал поможет вам начать осваивать Pairwise Testing, ведь в online редакторе это действительно просто 🙂
#web

Конференция - это ок :)
Я подписан на много пабликов по тестированию, в одном из них нашёл мини конференцию в онлайне. Так, как это пост не рекламный, да и таких у меня пока не было, с чистой совестью предлагаю посмотреть программу. Конференция бесплатная, а спикеры интересные.
#free

Сегодня вышла отличная статья от коллег из ОК о том, как поднималась автоматизация на Android в компании. Очень советую почитать, в этом направлении была проделана огромная работа, что-то может быть полезно и вам :)
#auto

https://m.habr.com/ru/company/odnoklassniki/blog/497726/

Пороки руководителя

Многим понравился пост про мотивацию, а теперь давайте поговорим о руководителях. Есть хорошая пословица: «Приходят в компанию, а уходят от руководителя». Как сделать так, чтобы команда давала хорошие результаты? 
Материалов по управлению много, ведь сегодня каждый второй - коуч, и не важно, какой у этого коуча опыт. Рабочих идей - мало. Я для себя выделил хорошую схему - работа от пороков. Если можешь победить в себе эти пороки, будешь давать результаты.

1. Стремиться любым способом усидеть в кресле руководителя
Я видел случаи, когда люди в поте лица работали на результат компании, а когда оказывались в позиции руководителя, менялись. Работали уже на удержание в своем кресле, расслаблялись, принимали не достаточно эффективные решения для команды, однако эти решения помогали им остаться у руля. Человек терял интерес ко всему, кроме себя самого. Успешность руководителя может измеряться только успешностью его команды / успешностью компании. Можете представить себе случай, когда на протяжении долгого периода времени руководитель весь такой успешный, а команда очень плохая? Мне - сложно. С моей точки зрения герои должны быть твоя команда, молодцы они, а ты просто их руководитель.

2. Стараться нравиться подчиненным
Хорошо, когда руководитель интересуется жизнью подчиненных, контактирует с ними, но иногда это может перейти границу. Дружба не должна переходить какую-то черту, за которой ты не можешь дать честный фидбек, указать на ошибки, или не дай бог, не можешь уволить не эффективного работника. Дружба дружбой, а служба службой. Не надо мешать личное и рабочее. Всегда будет соблазн построить вокруг себя группу поддержки, которая одобрит любое, самое глупое решение. Будет ли это полезно бизнесу? Я думаю - нет.
Лучше стараться разделать личное и рабочее. 

3. Затягивать принятие решения из страха совершить ошибку
Иногда руководители на столько боятся совершить ошибку, что просто не делают ничего. Безусловно, мы все стараемся хорошо продумать решения, все проверить, но это работает в идеальном мире, где есть время подумать. Бывают случаи, когда времени вообще нету. В этом случае лучше принять хоть какое-то решение, чем никакого вообще. Я думаю, что нам надо признаться самим себе, что ошибки будут. Самые честные тут врачи, они прямо говорят: «А может и не приживется!» И действительно, может и не приживется. Нету на свете человека, который всегда принимал бы быстрые и правильные решения, мы будем ошибаться. Самые сильные слова любого руководителя: «Я был неправ».

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

5. Стремиться стать неуязвимым и не доверять подчиненным
Бывают руководители, которые просто спускают задачу сверху, не объясняя вообще ничего своим подчиненным, еще хуже, когда такие руководители не хотят обсуждать свои планы и решения с коллективом. 
С моей точки зрения, хороший руководитель должен быть готов к тому, чтобы его идеи могут критиковать, обсуждать, предлагать вместо них другие. Он не боится щелчков по самолюбию и урона для профессиональной репутации. Хороши управленец показывает, что доверяет подчиненным, и они обязательно отвечают ему искренностью и доверием. 

Все эти мысли собрал из отличной книги Патрика Ленсиони - «Пять пороков руководителя». На карантине почитать самое то, займет пару часов. 
#team

В условиях самоизоляции стало появляться много интересных подкастов, один из таких я послушал в начале мая - «Ошибка Выжившего». Гости подкаста были Артем Ерошенко (Senior QA Engineer at Yandex) и Всеволод Брекелов (участник програмного комитета Heisenbug). Подкаст оказался очень интересным и его фокус был на автоматизации. Если вам интересна данная тема и вы хотите расширить свой кругозор - настоятельно рекомендую
#auto
https://youtu.be/Yo9tWwtdwz8

Рекордеры в автоматизированном тестировании «наше все»?

Иногда слышу фразы о том, что рекордеры могут заменить знания программирования для нужд автоматизации тестирования. Много лет назад я сам «игрался» с такими инструментами как Selenium IDE. К сожалению все эти решения очень не стабильны, плохо масштабируемые и сложно поддерживаемые при наборе определённой массы тестов. В новом шоу «Ошибки выжившего» с Артемом и Всеволодом, можно в живую ощутить это. Ребята в режиме online попробовали инструмент QAWolf, результаты этого можете посмотреть сами. От себя скажу, что с моей точки зрения, подобные инструменты не могут решить сколь либо серьезную задачу, а в мире, где программирование становится базовым навыком в ИТ, имеет смутные перспективы в будущем.
#auto

https://youtu.be/2dyuveoW1ls

А вам дают обратную связь на работе?
Работа занимает большой кусок нашей с вами жизни. Я всегда топил за то, что работа должна приносить удовольствие. Один из важных факторов, с помощью которого можно это удовольствие получать - адекватная обратная связь от руководителя. Все мы хотим понимать, хорошо или нет мы делаем свою работу. Почему-то многие руководители не считают нужным встречаться 1 на 1 с членами своей команды, обсуждать текущее положение дел, слушать предложения / пожелания. Личные встречи и общение, одни из главных инструментов для построения здоровой и эффективной атмосферы в команде. Почему так случается, что руководители не уделяют внимание ментальной стороне работы? В ИТ среде, чаще всего, из-за незрелости руководителя .

Есть у меня история… В команде, где я когда-то работал, сделали разработчика Джека (имя выдуманное) руководителем группы. Не знаю , каким он был разработчиком, но руководителем он точно стал плохим. Я уже писал как-то, что хороший разработчик != хороший руководитель. Ситуация в команде была примерно такая: Джек приходил (если приходил) в совершенно в разное время, слово «Привет» он не знал, личные встречи с ним были большой редкостью. Фактически, Джек не знал, что на уме у нас, мы не знали, что у него. Встречались починенные с Джеком либо раз в пол года, на оценке за период, либо когда кто-то косячил. Ни о каких регулярных личных встречах и речи идти не могло, ему было совершенно не интересно заниматься людьми, для него люди были функциями, для решения его задач, не более. Что получалось на выходе? Люди потухали и уходили, набирались новые и так по кругу. Конечно, кто-то оставался из-за большой любви к продукту, но таких было не так много. Была ли работа с таким руководителем комфортна мне? Конечно нет.

ИТ рынок перегрет и компании держаться за тех, кого они набирают, поэтому, в развитых командах, очень большое внимание уделяют получению фидбека от сотрудников. Руководитель должен встречаться с каждым своим бойцом раз в какой-то период. Частота обычно зависит от числа подчиненных, но точно не реже, чем раз в месяц. Я очень надеюсь, что в вашей команде есть встречи 1 - 1 с вашим руководителем, и еще больше надеюсь, что вы не узнала в себе или в своем руководителе Джека. Однако, если с этим есть проблема, один из лучших рассказов о том, как строить обратную связь в командах, я слышал от Саши Черного. Саша очень хорошо объясняет зачем это надо и как это развивалось в Pandao. Не поленитесь и посмотрите классную историю про обратную связь, это действительно людям важно.
ps: Наверно вы подумали о том, почему же не уволили Джека? Тут все просто, если у тебя есть единомышленных по вредным привычкам которые не противоречат законам РФ, это дает тебе крутой нетворкинг с высшим руководством, которое иногда прикроет тебя в той диче, что ты творишь. Это плохой путь и никому не советую, не лучшая строчка в биографии руководителя, но иногда работает, к сожалению.
#team

https://youtu.be/n_BzTyakgBU

​​Путь инженера в технические руководители долог и тернист.

Расскажу свою историю... Не все могут разделять мои взгляды, поэтому, как говорил Саша Черный, «Защитные заклинания»:
1. Не претендую на роль программиста.
2. Не претендую на роль хорошего руководителя.
3. Моя история, это моя история. Она может вам не подойти.

Если вдруг у тебя нет головы
Я могу тебе легко одолжить свою
Но только чур, чтоб ты потом не ныл
Мол: "Ноиз, ты мне подложил свинью!"
Давай с тобой договоримся тупо
Твой поступок — это твой поступок
Свою ответственность перекладывать глупо
На чувака из какой-то там группы

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

По началу думал, что стану крутым руководителем через год. Оглядываясь назад понимаю, что это смешно. Даже за 10 лет не стал.

Было решено начать набираться опыта ручного тестирования API и Web, думал хватит и за год уложусь. Как я ошибался, конечно не хватит, да и потратил я не год, а больше двух.

Пока разобрался с API и Web, появился новый важный горизонт — мобильное тестирование. Стало ясно, что с ним тоже надо поковыряться, поработать руками. Специфики там много и снова время, время, время. Вроде закончил, теперь все? Нет.

Знания не систематизированны. Удачно сложилось, что удалось преподавать. Пока учил тестированию других, систематизировал свои знания. И вроде теперь то вот она, победа? Снова нет.

Новый тренд — автоматизация. На западе в почете, чтобы QA писали автотесты. Вообще разумно:
1. Мы тестируем руками, почему бы не сделать все то же машине? Например, мы используем Postman, давайте переведем это в код тестов, это же дает более гибкие возможности для проверок.
2. Зная основы программирования мы получаем возможность читать код. Черный ящик хорошо, но мы можем упустить какой-то важный сценарий при тестировании.
3. Дай бог, если девелоперы пишут юнит тесты. Все остальное больше всего надо самим QA. Да и со знанием языка QA понимает, что эти тесты проверяют.
4. Вы не будите всю жизнь тестировать руками. Все хотят развиваться, автотесты это классный вариант. Тут главное не начинать сравнивать разработчиков и QA которые пишут автотесты, люди решают разные задачи.

Стало ясно, что надо учить язык, но что делать человеку, у которого не было в вузе языков? Учиться самому. Попробовал Java Rush, базово зашло, но как приложить к тестированию не понял. Переключился на тренинг Алексея Баранцева по Java для QA, интересно, увлекательно. По итогу эти два действия дали мне возможность понять основы языка и теорию по автотестам.

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

В итоге я потратил много-много лет на самообучение, чтобы получить минимально удовлетворительный технический уровень для руководителя команды тестирования по моей мерке «представления прекрасного». Можно ли было пройти его быстрее? Конечно, но к сожалению, мне не улыбнулась удача, чтобы кто-то «провел за руку».

К чему я это все?
1. Когда рассказывают success story, как было легко вырасти - я бы не верил, все сложно и больно.
2. Сегодня QA должен учится писать код, иначе завтра этот код начнут писать сегодняшние школьники у которых Java в 10-м классе. Будите конкурировать с ними. Посмотрите видео Никиты Макарова о тестировании белого ящика, сможете это сделать без знания языка?
3. Круто, когда у вас есть ментор.
4. Если у вас ничего нет, но есть большое желание — не сдавайтесь, будет больно, но возможно.
4. Думайте своей головой.
#free #team

Appium или Espresso?
Автоматизация с каждым годом становится все популярнее. В первую очередь это связано, с нуждами бизнеса, но так же, немаловажную роль играет скорость развития этих инструментов, они становятся лучше, стабильнее, быстрее и легче.

Если говорить про web, там все более-менее стандартно, а вот за Android идёт борьба. На рынке воюют разные решения, но лидеры, это Appium и Espresso. Конечно, тема сравнения этих двух инструментов очень актуальна, а для меня особенно. Ведь мне не довелось попробовать с Appium, однако, удалось какое-то время писать Espresso тесты. Это упущение с Appium порождало во мне большой интерес к вопросу их сравнения. Перерыв много статей и видео, я нашёл достаточно интересный доклад от коллеги по цеху, с уверенностью советую его вам.

Если у вас когда-то возникнет потребность выбирать между Appium и Espresso, посмотрите видео про их сравнение, лишним не будет.
#auto