Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Непрофессиональные проблемы тестирования в постсоветском государстве
06.10.2008 11:03

Автор: Ростислав Борук

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

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

На протяжении своей карьеры тестировщика мне приходилось слышать очень много различных вопросов на одну наболевшую тему «Когда же наше руководство начнет относится к тестированию как к одному из основных этапов разработки ПО? Неужели они там этого не понимают?». Рискну предположить, что 99% тестировщиков на постсоветском пространстве, так или иначе, сталкивались с подобной проблемой. А даже если и не 99%, а 75%, то это особо картину не меняет. И самое неприятное, что эти проблемы никоим образом не относятся к профессионализму тестировщиков или его отсутствию. Это проблемы, которые чаще относятся к некомпетентности руководства. И вот тут я задумался, а всегда ли это вопросы некомпетентности руководства? Может иногда сами же тестировщики не понимают тайный смысл их руководителей. Или просто не обладают нужными знаниями что бы суметь оценить ситуацию. Вот теперь, когда задача стала более понятной, попробуем ее проанализировать с двух сторон: тестировщика и руководителя.

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

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

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

Недостаточно ресурсов для тестирования

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

Нет возможности добавить ресурсы

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

Руководителю следует не стесняясь сказать об этом коллективу. Приведу пример из собственной практики. Когда я работал в молодой компании, в один прекрасный день наш руководитель всех собрал и объявил, что в компании осталось денег ровно на полтора месяца. Если мы не найдем заказчика(ов) в течении этого времени то компания будет закрываться. Мы все получили право на поиск работы и поездки на собеседования, однако все работали до последнего. Заказчика мы нашли и эта компания успешно работает уже более 5-ти лет после этого случая. Такая практика, к сожалению, больше распространена за рубежом, а не в постсоветском государстве у «наших» руководителей. По этому не бойтесь говорить людям правду. «Наш» народ не умеет отступать, и не любит сдаваться. Тут Вы узнаете истинный дух компании, и увидите на кого можно положиться.

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

Непонимание руководства в целесообразности добавления ресурсов

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

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

Жадность власть имущих

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

Их ненадобность

Если Вы не понимаете что происходит — это еще не повод ругать других.

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

С другой стороны, это большой недочет руководства, что оно не донесло свои стратегические планы, по данному продукту, до подчиненных.

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

Проблемы в процессах разработки, которые «сваливают» на непрофессионализм тестирования

Если у Вас всего достаточно, и Вы страдаете от того, что разработка ведется «из рук вон» плохо, тогда Вам стоит пообщаться с руководителем проекта и директором НЕМЕДЛЕННО. Сразу как только появляются проблемы. Не накапливайте их. Вам необходимо описать Ваши проблемы. Сразу оговорюсь, не стоит описывать проблемы в других отделах. Во-первых, Вам надо в этом разбираться самому, для того, что бы указывать что правильно, а что нет. Во-вторых, Вы, скорее всего, переведете фокус с Вашей проблемы. Итак, Вы описали Ваше видение того, что идет не так в Вашем отделе. В общем случае, после обсуждения этих проблем с руководителем и начальником проекта, практически все проблемы решаются. Можно все обсудить записать и работать по писанному. Можно договориться устно (лучше письменно), если Вы доверяете друг другу. В любом случае выход есть.

Но что делать если у Вас не общий случай. Приведу пример из личной практики. Когда я только начинал работу тестировщиком мне пришлось работать с руководителем проекта, основное кредо которого: «Главное прикрыть свой зад колышками». Честно говоря и сейчас встречаются такие, но к счастью, меня пока судьба отводит от таких.(Наверное с первым наработал на всю жизнь.) Так вот этот руководитель проекта, сам по себе был действительно молодцом: Он поднял проект без документации, знал практически все, что было в этом проекте. Но вот беда, он не хотел это нести в массы. Он считал, что чем больше он знает, тем более он не заменим. Ну не правда ли «наш» человек. Набирал он эти знания в течении полутора лет, пока не появился я, и мои коллеги тестировщики. Типичная проблема большинства «наших» проектов — это нет никакой документации, а если и есть, то она катастрофически не успевает за развитием событий в проекте. Вот в таком режиме мы поработали пол года. Даже выставку в Ялте прошли успешно. Но в срок, к сожалению, не уложились. Слишком много проблем оставалось в продукте. Казалось бы, ну вот и молодцы тестировщики, славно потрудились. А не тут-то было. Наш начальник был перед выбором, сказать руководителю проекта что он и его команда работают неудовлетворительно и искать пути выхода, при этом рискуя что руководитель обидится (сказать по правде, он бы точно обиделся, все-таки «наш» до мозга костей). Либо указать на нерадивое тестирование, что плохо ищем ошибки, продукт до сих пор имеет много проблем, и далее по тексту. Начальник выбрал второй вариант. Тоже «наш» человек. Не обсудив с начальником отдела тестирования, он его просто просит искать другое место работы. Вот это «наш» подход. Вполне допускаю, что наш руководитель сделал стратегическое решение, при чем правильное. Но вот воплотил он его по «нашему». Мораль примера проста: если у Вас такой расклад, подумайте о смене работы.

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

Принципиальное отличие, в данном варианте, от предыдущего в том, что здесь у Вас даже нет шанса успеть за разработкой. Изначально. Из-за этого, данная проблема выглядит, мягко говоря, подготовленной, что ли. Решение то же. Идти и говорить с руководством. Сразу. Не медля. И здесь шансов намного меньше, чем в предыдущем типе, что у Вас получится решить данную проблему. Именно потому, что она намного очевиднее и может быть спрогнозирована гораздо раньше чем возникла. Если люди не понимают того, что происходит, то им просто нужен крайний для каких-то своих тайных целей. Это вполне в «нашем» духе. Мораль все та же. Ищите новую работу.

Проблемы в процедурах самого тестирования

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

В некоторых случаях проблема может быть не в вашем начальнике. Приведу пример из моей практики: у нас в компании не было отдельно выделенного отдела тестирования. Каждый проект имел набор своих тестировщиков во главе с их руководителями. И вот, в очередной рабочий день, меня вызвал большой начальник и говорит: «Вот я плачу тестировщикам зарплату. Регулярно ее повышаю. А кто мне может сказать соответствует ли она действительности? Действительно ли я поднимаю ее заслуженно? Кто мне расскажет действительно ли один тестировщик лучше чем другой?» Тут есть проблема доверия к руководителям тестирощиков. Но нам более важна другая проблема — в организации не было единой системы. Не было единой культуры тестирования. Такой метод хорошо работает когда тестировщиков немного, все сидят рядом и делятся друг с другом информацией. Кто как работает, что и чем тестирует. Как рапортует и т.д. В таком случае есть человек который может охарактеризовать всех тестировщиков, пусть даже он и работает не в его проекте. Однако когда в организации становится много тестировщиков, получается, что вы можете просто не знать друг о друге. Вы можете сидеть за стенкой, делать одно и то же. Решать те же проблемы и даже не подозревать, что рядом есть человек, который может помочь. Не было системы обмена знаниями. Это уже проблемы более высокого уровня компетенции. В таком случае необходимо организовать отдельный тестовый отдел. Выбирайте самого уважаемого руководителя тестировщиков и делайте его главным. Что бы он знал, где сколько людей. У кого какой уровень знаний. Кто в чем силен. Кому какие ресурсы нужны, и т.д.

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

Руководство вмешивается в работу тестировщиков не обладая достаточной компетентностью в области тестирования

Если предыдущая проблема была, большей частью, по вине тестировщиков, то данная проблема существует только лишь по вине «наших» всезнающих руководителей. Что тут посоветуешь. Если Вы хорошо знаете свое дело, то скорее всего Вы будете часто ругаться с начальством и Вас либо попросят, либо Вам это самому надоест. Если же Вас это устраивает, то и проблемы нет. Из опыта скажу, был у меня такой начальник, в бытность мою разработчиком. Он даже в дизайны лез и, глядя на запущенную программу, менял графический пользовательский интерфейс «на лету». Компания, видимо, существовала не для того, что бы сделать продукт. Та еще «наша» компания. Закончила она, как и полагается, плачевно. Лучшие умы ушли довольно быстро. Была еще попытка что-то продолжить со студентами. Последнее что я слыхал об этой компании, что ее сотрудники судились с директором. А компанию закрыли. Делайте выводы сами.

Сроки на тестирование заведомо недостаточные (безобразное руководство)

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

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

На тестировщиков возлагают работы несвязанные с тестированием

Тестировщика «заставляют» писать требования, поддерживать их в актуальном состоянии. Просят собирать разнообразную информацию, которую не успевают или не желают собирать те, кто должен это делать. Но в большинстве своем, как это ни печально, это «черновые» работы, которые, якобы, некому больше делать. Данная проблема появляется по нескольким причинам: 1. простого непонимания руководством обязанностей тестировщика; 2. Неправильным процессом разработки, см. п. 2 а; 3. Желание «спихнуть» нудную работу на кого-нибудь; 4. Нехватка ресурсов см. п 1. Мы не будем здесь останавливаться на причине неправильного процесса или нехватки ресурсов. Это отдельная проблема которая описана выше. Просто отметим, что данные проблемы перекликаются и, как одним из результатов неправильного процесса или нехватки кадров, мы получаем работы не связанные с тестированием. Сосредоточимся здесь на причине непонимания руководством целей, которые стоят перед тестированием в целом и перед конкретным тестировщиком в частности, а так же затронем вопрос о статусе тестировщика в некоторых компаниях.

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

Еще одна весьма трудная тема — это статус тестировщика в компании. Нередко приходилось читать, что на тестировщиков никто не обращает внимания, никто ими не занимается, тестируем что скажут без подготовленных документах, так сказать «на коленках», и т.п. Если у Вас в компании такое же отношение, то не удивляйтесь почему вы распечатываете документы для руководителя проекта или меняете картридж в принтере. В такой компании хорошие тестировщики не нужны. Там нужны разнорабочие которые, ко всему прочему, еще немного и тестировщики. Если Вы хотите стать хорошим специалистом в области качества ПО, тогда уходите (скорее всего это Вам и предложат когда Вы начнете выполнять Ваши непосредственные обязанности.).

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

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

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

Совет тестировщикам. Запомните коллеги: чем больше непрофессиональных тестировщиков, тем больше компаний, в которых есть все вышеперечисленные проблемы. Учитесь, стремитесь и откроются перед Вами «правильные» двери.