Поставьте себе тайную цель никогда не позволить этой программе достичь стадии производства (и не забудьте скрыть довольную улыбку, когда вам это удастся)…

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

Вот они:

Цитата 1:

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

Цитата 2:

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

Цитата 3:

Я выполнил много ручного тестирования в свое время, и много управлял ручным тестированием. Что я обнаружил, так это то, что нет ответа на ваш вопрос. Мои рекомендации:

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

И потом, вам просто нужно продолжать управлять вашей компанией и тестировщиками, используя хорошую практику управления персоналом – предоставление тем, кто хочет расти, возможности сделать это, сохраняя рабочую атмосферу приятной и веселой, и т.д.

Цитата 4:

Я думаю, что скука не проблема, если вы можете найти пути для реализации своего творческого потенциала. Failure Mode Analysis – это прорыв. Model Driven Testing – помимо того, что является более эффективным и экономичным, чем традиционное функциональное тестирование – может приносить много веселья в современный Agile мир, так как большинство разработчиков, похоже, никогда не слышали о Finite State Machine, поэтому вы как тестировщик должны построить модель самостоятельно.

Цитата 5:

Вот сумасшедший пример для вас, но это работает:  однажды, когда у нас было свободное время и было скучно, мы придумали  »генератор случайного нажатия клавиш «, который был вентилятором (небольшим вентилятором баскетбольной формы для охлаждения банок). Тогда мы открыли приложение, и начали крутить нашим генератором возле клавиатуры. Бред? Да. Эффективно? ДА! Мы обнаружили некоторые интересные ошибки таким образом. Что касается скуки … ее не было. Иногда мы воспроизводили ошибку за пару минут, и втроем целый день пытались узнать, что мы сделали для этого. Но это было весело, и мы нашли ошибки, которые иначе остались бы незамеченными. Просто помните:  вы тестировщик. Вам единственному во всей команде платят за то, что вы закрашиваете за линиями, а не в их пределах. :-)

Цитата 6:

Я думаю, что вопрос, который вы подняли, охватывает довольно широкую область. Я занимался ручным и автоматизированным тестированием, а также был Тест-менеджером. Лично мне становилось скучно ручное тестирования после определенного периода, но как долго этот период продолжается, зависит от ряда вещей, и я видел эти же вещи у моих коллег тестировщиков тоже.
1. Лидерство: ваших тестировщиков бросают в работу или их ведут? Ценит ли их менеджмент? У меня были ситуации, когда я понимал, что меня не ценят, потому что я видел вещи, которые должны быть изменены, говорил с менеджерами, но ничего не менялось.
2. Организация, процессы и стандарты: Как тестер я видел достаточное количество команд, где проблемы морального духа для команды связаны с тем, что руководство требует высокого качества, но организационные структуры, стандарты и процессы не позволяют команде удовлетворить эти ожидания. В частности, там, где код «бросают через забор» команде тестировщиков лишь за небольшое время до релиза. Снова и снова, хорошая работа тестеров была испорчена тем фактом, что жизненный цикл разработки позволил выполнить отличную работу с учетом ограничений, и еще одна или две ошибки проскользнули в продакшн. Конечно, менеджмент винит в этом команду тестировщиков. Людям надоедают напряги за то, что не является их виной.
3. Личный вызов: Людям всех профессий нужны новые вызовы и изменения в том, что они делают. Может быть, это означает изменения проектов, изменение команд или изменение роли – например, перетасовка тестеров в команду, где они могут помочь пересмотреть стандарты и процессы. Таким образом, если они видят что-то неправильное в процессе тестирования, они имеют возможность принять участие в его устранении.

Я также помню, что у Джеймса Баха и др. ,возможно, было несколько моментов об этом в книге » Lessons Learned in Software Testing «.

Цитата 7:

Никогда не думайте, что продукт, который вы тестируете необычайно крут. Наоборот он, очевидно, имеет много недостатков и может быть сломан 33-ю способами – просто найдите их. Никогда не верьте никому, кто утверждает, что продукт работает каким-то образом – вы найдете много других (недокументированных) возможностей точно. Наградите себя кусочком шоколада за каждое неперехваченное исключение (uncaught exception). Относитесь к этой программе как к вашему личному врагу и исследуйте ее архитектуру, компоненты, специфику и связанные недостатки. Поставьте себе тайную цель никогда не позволить этой программе достичь стадии производства (и не забудьте скрыть довольную улыбку, когда вам это удастся). :)

На сегодня все. А что для вас ваша работа? Получаете ли вы от нее удовольствие?

Share
,
Trackback

no comment untill now

Add your comment now