Qa lead

Прямо сейчас в OTUS открыт набор на новый поток курса "QA Lead". В связи с этим Анастасия Шарикова - преподаватель курса поделилась с нами своей авторской статьёй. Передаём слово Анастасии:

Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.

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

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

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

Кого мы рассматриваем как начинающих? Это и Entry Level, то есть те, кто вообще не имеет коммерческого опыта, и Junior QA.

Плюсы

Итак, начнем мы с позитивной стороны: что же мы потенциально можем получить для своего отдела или команды в долгосрочной и краткосрочной перспективе, если начнем нанимать совсем зеленых специалистов?

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

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

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

• Мотивация и вовлеченность: вспоминаем про модель мотивации Хочу/Могу и понимаем, что большинство молодых специалистов (конечно, если мы не налажали при найме) относятся к категории хочу, но не могу и мотивированы на активное участие в работе и развитие просто потому что они смогли устроиться на работу.

• Свежий взгляд: да, этот пункт актуален далеко не для всех, но, например, для продуктовых команд может быть полезно посмотреть на свой продукт не умудренным взглядом, а послушать мнение о нем еще вчера далекого от It человека. Да-да, иногда снобизм стоит выключать.

• Вы можете словить настоящий талант: и я совершенно серьезно. Среди сотни соискателей без опыта, которые прочитали Савина и/или закончили курсы встречаются, как я их называю, прирожденные QA, которые находят и документируют баги или пишут тест-кейсы лучше, чем многие специалисты с 3+ лет опыта. Хорошо составленное тестовое задание - наше все в этом случае. И если уж вы нашли такой неограненный алмаз, то при должном усилии вы сможете получить в скором времени преданного крутого сотрудника.

• Лояльность: несмотря на то, что существует стандартное опасение, что "мол, мы вложим деньги и силы, а человек просто уйдет", можно провернуть и обратное - вырастить крайне лояльного сотрудника, который оценит, что вы ему помогли. Но, конечно, такое бывает не так часто, как хотелось бы.

• Использование внешнего бекграунда: если вы разрабатываете,допустим, сервис для медицинских работников, то идеальным кандидатом для вас может оказаться не middle/senior, а entry level/junior, который решил поменять профессию, и ушел как раз из нужной вам сферы. Он или она смогут принести вам крайне актуальную экспертизу и взгляд того, кто был погружен в тему.

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

Минусы

И, конечно же, надо рассмотреть часто встречающиеся сложности, связанные с наймом Entry Level/Junior QA:

• Надо тратить время на обучение. Будем честны: не у всех есть продуманная система наставничества и обучения сотрудников. Прямо скажем, не у всех есть хотя бы что-то, ее напоминающее, а джуны, которых вы наймете и просто кинете на амбразуру, могут быть мало того что бесполезны, но еще и вредны. Так что трижды подумайте, готовы ли вы этим заниматься.

• Контроль: если на опытного сотрудника довольно скоро после найма можно будет делегировать задачи и доверять самостоятельную работу, с новичками такое провернуть сложнее. Да и 1:1 и подобные встречи придется проводить чаще - стоит ли оно того?

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

• Testing vs QA: если вам нужно просто протыкать регресс, то проблемы не будет, а вот если в задачи входит не только проверка по ТЗ, но и более глубокое понимание процессов, возможностей к улучшению на всех этапах и подобное, то мягко говоря не каждый начинающий специалист сможет помочь вам с таким. Даже если на курсах его учили основам QA, то опыт тут все равно будет играть важную роль. И уверенность в себе, кстати, тоже.

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

• Завышенные ожидания: боль всех нанимателей (простите, дорогие джуны, если вы читаете этот текст) - если раньше новички были готовы работать за еду за небольшие деньги, то теперь каждый второй, кто закончил любые курсы сразу просит от 60 тысяч в Москве и от 100 через год опыта, даже если не умеет открывать DevTools и не знает, чем тест-кейс отличается от чеклиста. При этом всем, как ни парадоксально, все чаще заинтересованность начинающих QA в саморазвитии без наставничества сверху крайне низка, а требовательность к работодателю все растет и растет. И я, конечно же, не про базовые гигиенические факторы.

Что делать, если вы все же решились:

• Разберите бардак на проекте: knowlege managment на базовом уровне полезен даже если у вас нет постоянного найма новых сотрудников, а уж когда надо вводить в курс дела новичков, то он вам точно пригодится. Ну и конечно же стоит наконец завязать с ТЗ по телефону, баг-репортами по переписке, тикетами на бумажках и прочими подобными практиками.

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

• Признайтесь себе честно, насколько сложные у вас задачи: правда ли вам вообще нужны джуны? Может быть вам стоит попробовать выбить больше денег на ставку Middle QA, а не пытаться затыкать дыры теми, кто просто не справится?

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

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

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

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

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

Также приглашаем будущих студентов курса "QA Lead" и всех желающих посетить открытый демо-урок Оценка эффективности тестовой стратегии с помощью тестового покрытия.

На этом вебинаре рассмотрим:

- Оценка эффективности работ по тестированию
- Что такое тестовое покрытие?
- Создание дерева требований
- Структурные методы построения тестовой модели
- Как достигать хорошего покрытия
- Зачем нужны метрики тестового покрытия
Присоединяйтесь!

Всем привет! Меня зовут Анастасия Шарикова, я Technical Project Lead в Bookmate и веду телеграм канал Yet another QA.

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

• Никто не откликается на вакансию

• Отклики есть, но почему-то не от тех, кого хотелось бы

• Никто не может пройти собеседование с HR/Техническое/Любое другое

• Те, кто получают оффер, его не принимают и не говорят причины

• На рынке мало экспертов по нужному направлению

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

Что же делать? Конечно, вариантов много, как и статей, где дается миллион советов о том, как нужно делать правильно, например, такие:

• Будьте лучшими в своей сфере!

• Расширяйте сетку поиска!

• Напишите крутое описание вакансии!

И прочие, прочие общие рекомендации. Так что сегодня я решила пойти по другому пути дать вам настоящие советы, которые помогут вам понять, что что-то вы делаете не так. Или расскажут о том, как не надо делать в будущем :)

Подготовка к найму

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

• Составление профиля должности лишняя трата времени.

• Нанимаете первого QA в компанию? Что ж, звучит довольно просто, так что можно не консультироваться со специалистом этого профиля, ведь все и так знают, что тестить может любой.

• Совет для молодых стартапов берите первым тестировщиком Junior QA, лучше сразу после курсов его голова пока не забита ненужными знаниями и он отлично сможет выстроить процессы с нуля.

Вакансия

• Чем более творческой будет вакансия тем лучше! Ведь что может быть лучше вирального классного текста без конкретных подробностей с ним охват намного выше, так как каждый захочет именно к вам!

• Конечно же, мы понимаем, что QA без высшего технического профильного образования нонсенс. А как вы себе представляете прохождение ручных регрессов для приложения со списком задач без магистратуры? Так что обязательно пропишите это в требованиях. И не забудьте упомянуть, что выпускники курсов могут вам не писать пусть кто их учил, тот их и нанимает.

• Название вакансии дело требующее серьезного подхода, да и путаницы не хотелось бы так что будьте проще, так и пишите Тестер или Q&A профессионалы сразу поймут, о чем речь.

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

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

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

• В наше время все больше становится актуальной тема T-shape развития, и для сферы QA это тоже актуально. Так что Senior+ специалисты особенно ценят вакансии, где нужно проводить ручное тестирование, и автоматизированное, и заниматься DevOps циклом, но большее время, конечно, отдавать найму, обучению, менеджменту и консалтингу.

• Ищите специалистов с как можно бОльшим опытом, и желательно, конечно, мужчин около 25-30 лет. Это лучший выбор, и лучше написать об этом сразу в вакансии, чтобы все поняли серьезность ваших намерений.

Собеседования

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

• Чем больше будет этапов собеседования тем лучше. Это позволит вам выяснить все аспекты профессиональных качеств претендента, к тому же именно многоступенчатое собеседование сейчас в тренде, благодаря таким компаниям, как Яндекс.

• Чем больше будет человек на собеседовании тем лучше. Это позволит вам понять человека лучше, да и легко совместить со стресс-собеседованием. А вот QA специалиста можно и не звать достаточно получить от него или нее заранее подготовленный список вопросов.

• Акцент на собеседовании лучше делать на теории и на содержании резюме ведь именно они в полной мере смогут показать, как человек будет действовать в рабочих ситуациях и насколько подходит команде, если она уже существует.

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

Организационные процессы

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

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

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

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

• Тестовое задание отличный способ отсеять лучших претендентов. Тут два важных момента отвечайте только лучшим из них, кто прошел испытание, остальные и так поймут, что они не так хороши и по молчанию. Второе старайтесь описать задачу в ТЗ более запутанно ведь и рабочие задачи обычно тоже сложны.

Подведем итоги

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

Узнать подробнее о курсе "QA Lead"

Привет, Хабр!Анастасия Асеева-Нгуен (эксперт по инженерным практикам в Tinkoff Group) приглашает специалистов по тестированию на бесплатный Demo-урок Метрики, который пройдёт в рамках нового профессионального курса OTUS QA Lead. А мы публикуем статью Анастасии Шариковой руководителя отделом тестирования в Bookmate.

Всем привет! Меня зовут Анастасия Шарикова, я руковожу отделом тестирования в Bookmate и веду телеграм канал Yet another QA.

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

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

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

Варианты использования чек-листов

Как верно было написано у С. Куликова в Тестирование программного обеспечения. Базовый курс

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

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

• Ad-hoc/Исследовательское тестирование структуризация идей и задач в случае проведения таких видов тестирования+ отметка для себя о том, что уже проверено.

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

• Mind Maps несмотря на то, что чаще всего чек-лист выглядит как перечень блоков, секций, страниц, других элементов, которые следует протестировать, он может быть и визуализирован в виде майнд карт. А еще их можно не только составлять самим, но и находить уже готовые, что позволит сэкономить время и посмотреть на задачи проверок свежим взглядом.

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

• Приемка задач и в этом контексте мы можем говорить и про визуализацию стадий тестирования, и про визуализацию готовности взятия задачи в работу. В первом случае мы можем составить список, пример которого можно найти, например, тут . Во втором случае мы можем создать, например, чек-лист в таске в Jira, который будет требовать наличие документации, макетов, информации об окружении и прочей важной информации для перевода задачи в статус Testing.

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

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

• Матрицы трассируемости - по сути основой этой матрицы и будет служить чек-лист. Подробнее о примере, можно почитать, например, тут.

• Планирование тестирования - один из вариантов составления тест-планов, который вполне имеет место.

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

Способы составления чек-листов

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

Преимущества и сложности в использовании

Рассмотрим основные преимущества и сложности, которые могут появиться при использовании чек-листов для различных кейсов и задач:

Плюсы:

• Гибкость - этот вид проверки может быть использован во всех уровнях и типах тестирования, хоть и в разной форме, помимо этого, его легко адаптировать под нужды конкретной задачи.

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

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

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

• Расширение тестового покрытия за счет отличий при прохождении - тут и возможность избежать парадокса пестицида (подробнее можно почитать у автора термина), и возможность по-разному комбинировать проверки, в случае тестирования, например. функционального.

Минусы:

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

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

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

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

Инструменты

Как итог, перечислю одни из самых популярных инструментов для составления чек-листов:

• TestRail, TestLink и прочие системы тест-менеджмента.

• Trello тоже имеет функционал составления чек-листов в рамках задач.

• Google.Sheets этот инструмент в представлении не нуждается. Тем не менее это, конечно, не единственное решение с таблицами, Exсel тоже подойдет!

• To Do перерождение Wunderlist и отличное решение для чек-листов, особенно для личного использования.

• Miro а вот тут будет удобно создавать уже Mind Maps.

• Jira в этом случае есть много вариантов встраивания под разные задачи + доп. Инструменты, такие как этот.

Знаете еще крутые инструменты и кейсы использования? Пишите в комментариях!

Интересно развиваться в данном направлении? Запишитесь на бесплатный Demo-урок Метрики, а также приходите на другие Demo-уроки для QA-специалистов:

• Основы puppeteer трансляция в рамках курса Автоматизация тестирования на JavaScript

• Скрипты и сценарии нагрузочного тестирования Performance center (PC) и Vugen трансляция в рамках курса Нагрузочное тестирование

Для будущих студентов курса "QA Lead" и всех интересующихся областью тестирования подготовили перевод полезного материала.

Приглашаем также всех желающих на открытый вебинар по теме Организация процесса тестирования в agile и не agile-командах. На этом бесплатном демо-уроке мы рассмотрим вопросы:
1. Организация процесса работы в waterfall проекте;
2. Организация процесса тестирования в scrum команде;
3. Организация процесса тестирования в команде, работающей по kanban методу;
4. Организация процесса работы в масштабируемых agile-подходах.

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

1."Будущее тестирования программного обеспечения"- публикация Angie Jones

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

2. Эвристики для сбора грибов (и тестирования) - публикация Helena Jeret-Mae

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

3.Три желания с Волшебной Лампой Аладдина - публикация Luke Liu

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

4.Книга Позитива от David Williams

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

5.Получение отзывов онлайн-сообществ о продуктах - публикация Rosie Sherry

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

6.Хрустальный шар будущего - Автоматизация через десять лет - публикация Richard Bradshaw

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

7.Состояние автоматизированного тестирования: 7 Ключевых тенденции для наблюдения - публикация Joe Colantonio

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

8.Я не думаю, что это значит то, что ты думаешь, это значит. - публикация Keith Klain

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

9.Как попросить о помощи - публикация Alan Richardson

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

10.Поощряем живое мышление - публикация James Bach

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

11. Ошибочный вывод о бездефектности - публикация Jeff Nyman

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

12.Не верьте этим 4 мифам о клиентах - публикация Kristel Kruustuk

Кристель написала эту статью для журнала "Entrepreneur" (Предприниматель). Публикация содержит отличные практические советы по проведению QA-тестирования. Ее внимание к людям как конечному пользователю важно и практично. Это то, о чем необходимо помнить каждому QA специалисту. Не может быть такого, чтобы все это было бы связано с автоматизацией.

13.Каково будущее тестирования программного обеспечения? - публикация Grace Barnott

В этой статье, найденной в журнале Software Testing News, посвященному тестированию программного обеспечения, рассказывается о том, куда движется индустрия и что необходимо тем, кто работает в сфере QA. Статья признает предстоящие вызовы, но рассматривает и положительные моменты, а также переход к тестированию в следующем десятилетии.

14.Таблица как инструмент тестирования нуждается в вас- публикация Kate Falanga

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

Узнать подробнее о курсе "QA Lead".

Смотреть вебинар по теме Организация процесса тестирования в agile и не agile-командах.