Home

Автор: Алессандра Морейра (Alessandra Moreira)

Оригинал статьи: https://roadlesstested.com/2017/08/24/motivating-testers/

Перевод: Ольга Алифанова

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

Дилемма немотивированных тестировщиков

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

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

Мотивация – это дорога с двусторонним движением: нельзя мотивировать тех, кто ничем не интересуется. Это важный момент, поэтому повторюсь: нельзя замотивировать тех, кто этого не хочет. Однако мы можем указать им путь, вдохновлять их личным примером и надеяться, что им захочется меняться.

Автор: ведущий специалист по тестированию компании "Лаборатория качества" Людмила Лихогляд

Оригинальная публикация: http://quality-lab.ru/lets-talk-about-testing-team-motivation/

Люди работают не только ради денег,
и если вы пытаетесь мотивировать людей,
деньги не самый эффективный инструмент.
© Акио Морита

Пару лет назад на просторах всемирной сети мне повстречалась интереснейшая история. К сожалению, я не помню ни автора, ни деталей, но суть ее в следующем. Как-то на одном предприятии все стало плохо: понизилась производительность, не выполнялся план, появилось много брака. Уже и зарплаты сотрудникам поднимали, и условия работы сделали на уровне – а предприятие, увы, терпит убытки. И как же тут быть? Выход оказался довольно неожиданным: проанализировав работу предприятия, выбрали работника с наилучшими показателями производительности, на общем собрании обсудили его работу, указали на все недочеты и недоработки, а потом… уволили за несоответствие занимаемой должности. Несправедливо? Жестоко? Возможно, но давайте посмотрим на результат.

Автор: Иван Бондарь, ведущий инженер по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/how-to-understand-cutomers-needs/

Нет ничего страшнее в тестировании, чем отсутствие единого понимания особенностей продукта (проекта) участниками команды. Последствия разнообразия взглядов могут быть различными: от заведения бесполезных дефектов, напоминающих «белый шум», до пропуска проблем, критичных для пользователя.

К сожалению, наладить единство понимания бывает не очень просто, так как:

- руководители проектов, выступающие в роли заказчиков тестирования, не всегда делятся «очевидной» информацией;
- специалисты по тестированию зачастую пытаются навязать проекту некое «правильное» (в их понимании) тестирование.

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

Автор: ведущий специалист по тестированию компании "Лаборатория качества" Виктория Юркевич

Оригинальная публикация: http://quality-lab.ru/questions-to-ask-testers-at-a-job-interview/

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

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

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

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

Автор: Шрини Кулкарни (Shrini Kulkarni)

Оригинал статьи: http://shrinik.blogspot.ru/2016/12/test-manager-vs-project-manager.html

Перевод: Ольга Алифанова

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

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

Рядом со мной сидит мой друг и коллега, прожект-менеджер. Он вечно взволнован. Каждый раз, когда кто-то из моей команды просит разъяснений, у менеджера сбивается сердечный ритм, потому что он думает – о боже, нет, они нашли еще один баг! Во время наших встреч, посвященных багам, я гордо говорю, что сегодня мы нашли 40 новых багов, то есть всего за эту неделю – 370, 80 из которых критические! ПМ, придя в себя, отвечает – ок, какие из исправленных багов уже прошли ретест? Какие области приложения относительно стабильны? Что хорошего мы можем сообщить нашим заказчикам?

Автор: Миронова Юлия

Оригинальная публикация: http://quality-lab.ru/casco-insurance-testing/

Материал основан на реальном проектном опыте.

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

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

Не удивительно, что в одной крупной страховой компании однажды возник вопрос: безупречно ли функционирует их система расчёта КАСКО? За ответом на этот вопрос они обратились к нам. Была поставлена задача: протестировать систему расчёта стоимости страховки, сделав упор в первую очередь на корректность расчетов. Мы имели предоставленные компанией подробнейшие системы принятого расчёта, составлявшие около 30 итоговых коэффициентов для 39 регионов (именно таков был размах этой страховой) и 39 больших файлов.

Автор: Юлия Бурматова

Оригинальная публикация

Все мы когда-то были новичками: в тестировании или в другой сфере – не важно. Мы одинаково спотыкались, блуждали в поисках правильного пути и далеко не всегда быстро находили решение. Порой у нас опускались руки от многократных ошибок, и в голове прочно утверждалась мысль: «Я – неудачник и все делаю не так!».

Я хорошо помню свой самый первый проект с реальными задачами, свои большие от страха глаза, когда мне поручили составление тестов. Я совершенно не знала, с чего начинать. И больше всего меня мучило не абстрактное «как это делается?», а «как это сделать правильно?».

С тех пор прошло почти три года, я многому научилась – самостоятельно и с помощью замечательных коллег, с которыми мне посчастливилось работать. А еще за все это время я успела неоднократно побывать в роли наставника новичков, которые приходили в нашу компанию, и стать одним из тренеров курса «Школа успешных тестировщиков» Натальи Руколь.

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

Оригинальная публикация

Автор: Наталья Руколь

Многие руководители проектов ищут универсальный ответ на вопрос: «Каким должно быть соотношение тестировщиков и разработчиков»? В некоторых компаниях дело доходит до утверждения нормативов: например, численность тестировщиков должна составлять 40% от команды разработки, или на каждого разработчика должен приходиться один тестировщик. Для обоснования этого соотношения нередко подбирается некая универсальная статистика по отрасли. Существует ли оптимальный рецепт?

Правильного соотношения не существует

Универсальные ответы всегда чреваты неточностью. Представьте: вы приходите к врачу и начинаете ему жаловаться на свою проблему. Он, не дослушав, выписывает лекарство:

— Какой у Вас вес? 80? Значит, по нормативу Вам надо пить 2 таблетки в день.
— Но подождите, доктор, у меня не простуда, а перелом ноги!
— Не отвлекайте, у нас норматив. Следующий!

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

Выступление Сергея Атрощенкова на онлайн-конференции для специалистов по ручному тестированию Fun ConfeT&QA.

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

«Ах он нехороший!» – могут возникнуть мысли. Так ли это?
А если вспомнить, как именно мы просили?
Конечно – как положено!
Но так «положено» только в нашей картине мира. Так, как мы считаем правильным. Так, как нас научил наш опыт.

А когда мы общаемся с тестировщиком-коллегой – эффективно ли наше общение? Достигаем ли мы цели коммуникации? А ставим ли осознанно цель?

Автор: Бен Келли (Ben Kelly)

Оригинал статьи: http://www.ministryoftesting.com/2016/05/managing-relationships-relationshipping-manager/

Перевод: Ольга Алифанова

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

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

- Привет, Бен, как там тестирование?

- Все окей!

- (неловкое молчание)

- (менеджер уходит)

- (моя почта сообщает, что мне пришло приглашение на встречу, чтобы обсудить прогресс тестирования).

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