Как автотесты ускоряют релизы в Одноклассниках

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

Несколько лет назад я был на выступлении Никиты Макарова и оно произвело на меня большое впечатление. Думаю, что именно после этого выступления, у меня появилось большое желание работать в технической команде Одноклассников. Основное, что поразило - трансформация команды тестирования. Было много ручных тестировщиков, а их всех научили писать автотесты на Java, как минимум, на API и Web.

Не хочу спойлерить, скажу только то, что в докладе нету технических деталей, однако, можно понять, куда двигаться на пути перехода от ручного тестирования к автоматизированному, зачем вообще нужна автоматизация и что она может дать.
#free
https://youtu.be/2IRlRRycaTw

⁠Пять пороков команды.

Когда я слышу фразу: «Я работаю в команде мечты», снимаю шляпу перед руководителем этого человека. Обычно за этой фразой стоит огромная работа.

Очень часто встречаю людей, которые думают, что наладив разные технические процессы, например банальное внедрение Jira, настройка CI, переход на новый, модный язык программирования и.т.д, можно расслабиться. Команда должна быть этим довольна, ведь у нас все модно и молодежно. К сожалению этого не достаточно. Кроме технических моментов надо вкладываться и в атмосферу в команде. Многие недооценивают, как бы это назвать, «ментальную составляющую», а она важна для продуктивной работы. Что можно сделать, чтобы улучшить атмосферу? Прежде всего бороться с так называемыми «пороками».

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

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

Итак, давайте по всем пунктам, которые затрудняют создать команду мечты:

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

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

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

Нетребовательность к другим
Я часто слышу от людей фразу «Это не мое дело». Причем эту фразу используют даже тогда, когда понимают, что какие-то действия (или, наоборот, бездействие) вредны для компании. Возможно это пережиток прошлого, ведь во времена СССР был лозунг — не высовывайся. Я убежден, что в первую очередь, надо руководствоваться интересами компании, а не страхом того, что ты скажешь кому-то, что-то неудобное. Надо быть требовательным к себе, и в разумной степени, к другим.

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

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

Вернемся к техническим темам, поговорим об энергопотреблении приложений.

Страшный сон разработчикам мобильных приложений - попасть в топ энергопотребления на телефонах своих пользователей. Одно время люди удаляли приложение Facebook и переходили на использование мобильной версии сайта, большой расход энергии. Наверно именно поэтому, часто слышу идеи: «Давайте мерить энергопотребление в мобильных приложениях!»

Дело важное и нужное, но обычно это ничем не заканчивается. Потыкались > с ходу не нашли решение, или нашли, но данные не ясны > бросили. Почему так бывает? Прежде всего потому, что об этом мало где пишут. На самом деле, измерение энергопотребления приложений, это достаточно сложная задача. Она не решается за пару часов. Те, кто начинают детально вникать, понимают, что там спрятано множество подводных камней.

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

И да, если понравился какой-то пост, поделитесь с другом или подругой, пусть в профессии будет больше профессионалов.
#mobile

https://youtu.be/FRWvJpwyYrU

Краудсорсинг в тестировании

Вернемся к свободным темам. С каждым днем программное обеспечение становится все сложнее и сложнее. Но люди все так же хотят: быстро, качественно и дёшево, классический оксюморон. Не смотря на то, что в этом требовании есть явное противоречие, с этим надо жить. Классическое решение части этих проблемы «в лоб»:
🌀Оптимизировать процессы.
🌀Раздувать штат пропорционально увеличению загрузки, если оптимизировали все, что только можно.

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

Краудсорсинг - это замена экспертизы одного конкретного специалиста на так называемую «мудрость толпы» в тех случаях, когда экспертиза специалиста или очень дорога, или сложно масштабируется (с) Ольга Мегорская.

Где это можно применить? По моим наблюдениям, краудсорсинг в тестировании, чаще всего используется в игровых проектах (Innova Systems, Wargaming.net, Mail.ru Group, и другие). В первую очередь это связано с миксом сложности самого функционала ПО и сложности его автоматизации. Я думаю, что подобное применений краудсорсинга полностью оправдано. Есть и не игровые проекты, где этот подход используется, например в Mail.ru Group на проекте ВКонтакте, тестирование ассессорами в Яндексе, различные отдельные площадки, на которых можно заказать такую услугу / стать бета-тестером. Гугл выдает массу ссылок на эту тему.

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

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

Анастасия Семенюк — «Бета-тестирование ВКонтакте»
Ольга Мегорская — «Краудсорсинг в тестировании»

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

Материал будет полезен тем, кто занимается оптимизацией процессов, ну или для общего развития в области тестирования. Тем у кого нету ни первой ни второй задачи - просто ставьте лайк и идите пить чай. К сожалению, вы не сможете применить эти знания здесь и сейчас.
Ps: конечно, тут нет рекламы. Названия некоторых компаний в посте принудительно превращаются системой в урл. Чтобы было одинаково, прилепил ссылка на сайт всех упомянутых компаний.
#free

Деньги в мире ИТ.

Часто слышу фразу: «Вам слишком много платят, посмотрите, как люди живут!». Да, платят очень хорошо, но это по меркам России. По меркам мира, ИТшники зарабатывают просто нормально, а вот другим - недоплачивают. Приведу несколько цифр, это цифры не точные, но температура по больнице будет правильной. Врач в Германии, в среднем, получает около ~4k - 5k €, разработчик получает так же, ~4k - 5k €. И пусть будет разброс от квалификации, но порядок примерно сопоставим. Если посмотреть на ситуацию в России, то я вижу разницу зп (заработная плата) в 5 - 10 раз. Люди, которые создают сервисы, чтобы лайкать котиков имеют в разы больше, чем люди, которые спасают других людей. Это ужасно. Но почему у нас так? С моей точки зрения нет конкуренции с внешним миром для 90% профессий.

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

А теперь о совсем плохом. Большие зарплаты негативно влияют на модель мира молодых ИТшников. Многие хотят на старте зарабатывать много. Гонятся не за опытом, а за деньгами. Лично я, первые 5 лет, выбирал место работы по принципу: «Чему я там научусь?», а не: «Сколько буду зарабатывать?». И только после набора определенной массы знаний, стал продавать свои знания на рынке. С моей точки зрения, это самый правильный путь, чтобы получить больше денег в перспективе. Я думаю, что если взять человека, который гнался за деньгами и человека который гнался за опытом, посмотреть их зп через 10 лет после старта, второй будет иметь больше, ну или в крайнем случае столько же, но знать он будет точно больше.

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

«Место где ты получаешь опыт, и место, где ты его продаешь - это два разных места»

Каждая ваша ошибка, которую вы совершаете на работе - деньги для компании. Эти деньги - прямая инвестиция в вас, как в работника. Чем меньше компания в вас инвестирует, тем больше вам платят.
#team #free

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

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

Один из таких инструментов - 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