Тендер на тестирование главного системного билда одной всем известной компании по производству программного обеспечения.
Мой коллега - менеджер по продажам (salesman), я считаю себя профессиональным тестировщиком и всегда пытаюсь применять контекстно-зависимое (context-driven) тестирование.
Сразу после встречи мой коллега сразу же поехал домой.
Я увидел ужасную пробку на дороге, поэтому решил выпить еще чашечку кофе, проверить почтовый ящик с помощью iPad перед тем как отправиться в путь.
Когда я получил свой кофе и "установил" себя за столик в лобби, ко мне подсел мужчина, которого я видел во время встречи. Он решил поговорить со мной о всяких неинтересных вещах.
Я уже был достаточно раздражен, когда мой собеседник сказал:
"Это настолько же сложно, как тест-проект, который они презентовали сегодня на встрече, Вы так не думаете?"
На самом деле я думал, что это несложный тест-проект для профессионального тестировщика, но я не знал что сказать. Поэтому промолчал.
"У вас большой опыт в тестировании, не так ли?" - сказал он.
"Думаю, что да" - сказал я, пытаясь понять чего этот парень хочет от меня.
"Да, ставлю на то, что Вы самый настоящий профессионал высочайшего уровня"
"Ну, я не знаю" - скромно ответил я.
"Не нужно скромничать. Мне было бы интересно узнать, чтобы вы делали в тестовом проекте такого уровня?"
Я взглянул на этого человека внимательнее. Этот парень выглядит как продавец, он одет как продавец, он говорит как продавец и он приехал на встречу salesman. Этот парень, вероятно, менеджер по продажам. Менеджер по продажам одного из наших конкурентов в этом тендере... И как мне кажется, у него нет ни малейшего представления о тестировании. Он пытается получить от меня информацию о том, как лучше реализовать такой тест-проект, чтобы улучшить собственные шансы на победу в тендере! Поэтому я решил дать ему несколько вредных советов для того, чтобы увеличить наши шансы на победу.
1) "Первым делом, всегда создавайте всеобъемлющий тестовый план".
Он тут же записал это.
"Тестовый план должен покрывать все виды деятельности в тестовом проекте. Абсолютно всё нужно обсудить и детально описать".
"Абсолютно всё?" - парень был сильно удивлен.
"Конечно! - сказал я. - Всё должно быть кристально понятно для всех, чтобы избежать в дальнейшем сюрпризов. И все должны с этим согласиться".
"Все? Искренне?"
"Конечно же. Я никогда не стану начинать подготовку тестов прежде, чем мой тест план не будет подписан всеми заинтересованными сторонами".
"Насколько большой обычно получается такой тест план?"
"Ну... Как правило, от двадцати или тридцати страниц", - солгал я. На самом деле последний мой тест план был mind-картой - но такой практический совет я никогда не дам своему конкуренту.
"Сколько времени понадобится для создания такого тест плана?"
"Около трех недель, но это зависит от того, сколько времени заинтересованные стороны будут читать его".
"Они действительно должны прочитать его? Полностью?"
"Конечно" - сказал я.
2) "Всегда заранее выбирайте детализированную стратегию тестирования и тестовые подходы, которые будете использовать в тестировании".
"А что такое стратегия тестирования и подходы в тестировании?" - спросил он. Этот парень действительно ничего не знает о тестировании.
"Стратегия тестирования это описание всех видов тестов, которые вы собираетесь выполнять. Тестовые подходы - это то, каким образом вы собираетесь тестировать. Они базируются на целях проекта и оценках рисков".
"Ага, окей, но можно ли решать это заранее?"
"Вы обязаны. Иначе вы не сможете сделать свой план тестирования. То, что вы собираетесь делать и то, как вы собираетесь это делать останется непонятным для окружающих. Подготовиться заранее - это хорошая практика управления проектами".
Парень кивнул.
"И, конечно же, нужно заморозить тест стратегию, список подходов и план тестирования, прежде чем начинать разработку".
"Заморозить? На протяжении всей разработки проекта?"
"Конечно. Вы не сможете сделать хорошо управляемый тестовый проект, если вы постоянно меняете стратегию, подходы и планирование. Соглашение является соглашением! В противном случае - вы ненадежный партнер".
"Согласен, это очень важно", - сказал парень и продолжил делать заметки.
Я заметил, что этому человеку достаточно трудно следовать за моим ходом мыслей. Может быть, я все усложнил. Я должен сделать свои советы более доступными.
3) "Всегда следуйте руководству по тестированию, которое используется в вашей компании."
"В компаниях обычно есть такое руководство?"
"Да, конечно же. Эксперты, которые пишут такое руководство, вкладывают в него огромное количество сил и мыслей. Эти консультанты очень высокооплачиваемые, поэтому в итоге у них получается хорошее руководство. Кем себя возомнили тестировщики, чтобы спорить с руководством?"
"Но разве каждый проект - не уникален? Ведь уникальный проект требует уникального подхода?"
"Ох, да ладно вам. Все проекты тестирования одинаковые. Поэтому, на мой взгляд, все они могут выполняться на основе одних процессов".
"Как скажите".
После того, как парень дописал мой очередной совет, он спросил не хочу ли я выпить еще чашечку кофе. "Черный без сахара", - сказал я. Когда он вернулся с двумя кофе сразу же задал вопрос: "А Вы не думаете, что ваш тестовый проект слишком сложный? Комплексный план, тест стратегия, руководство..."
"Вы абсолютно правы" - сказал я.
Поэтому мой четвертый совет:
4) "Используйте ограниченный набор техник и подходов тестирования, независимо от характеристик системы".
Мой собеседник посмотрел на меня, и я увидел знаки вопроса в его глазах.
"Да", продолжил я, "Всегда лучше, если тестировщик очень хорошо знает 3-4 подхода в тестировании, чем если он имеет небольшие знания о множестве подходов".
"Вы уверены?"
"Абсолютно. При постоянном применении одного подхода, вне зависимости от ситуации - ваш опыт использования этого подхода увеличивается и доверие к вашему тестовому покрытию будет только рости".
"Да, тестовое покрытие очень важно..."
"К тому же, если вы всегда пользуетесь одними методами - вы быстро научитесь достигать высокого уровня тестового покрытия с наименьшими усилиями".
"Звучит разумно, но я думал, что системные характеристики определяют какие тестовые подходы вы используете в тестировании".
"Это заблуждение, вы можете использовать любой понравившийся подход в любой ситуации, поэтому мастерское владение 3-4 техниками сработает".
"Ох".
Было очевидно, что сейчас мой собеседник очень впечатлен.
5) "Никогда не начинайте подготовку, если у вас нет исчерпывающей системной документации"
"Системная документация?"
"Да, требования, функциональный дизайн".
"Но я слышал, что кто-то говорил, что в наше время работающее программное обеспечение важнее, чем документация".
"Это может быть правдой, но тестировщик не может работать с не строгой тестовой основой. Он должен основывать свои тестовые скрипты на чем-то бесспорном. Таким образом, характеристики системы должны быть точными, полными и окончательными. Что еще может быть справкой, которой вы сможете доверять?"
"Может быть специалисты в этой системе, такие как, например, супер-пользователи - могут быть справочной системой?"
"Ох, да ладно. Если Вы спросите один вопрос у двух разных пользователей - они никогда не согласятся друг с другом. Общение с пользователями займет целую кучу времени. Ценного времени!"
"Может быть тогда хороший тестировщик сможет использовать свои личные опыт и ожидания от системы?"
"Не очень хорошая идея. Каждый тестировщик имеет свое мнение о качестве программного обеспечения. Его мнение должно быть основано на бесспорном постулате - утвержденной документации. В противном случае вы получите только мнения и споры".
"Да, это плохо".
"У меня есть еще один вопрос, - сказал парень. - Я всегда немного удивлялся, когда видел тестировщиков, которые много работают и тратят много своего времени до того, как появится само программное обеспечение. Это действительно необходимо?"
"Абсолютно!" - сказал я.
6) "Всегда описывайте каждый тестовый скрипт заранее очень подробно, прежде чем начать выполнение тестов."
"Почему? Ведь это занимает так много времени".
"Хороший вопрос. Методы тестирования и виды систем, о которых мы говорим, настолько сложны, что непосредственно в процессе тестирования вы потеряете правильное представление о системе. Создавая заранее подробные тестовые скрипты вы точно знаете, что делать во время выполнения теста".
"Но разве создание всех этих сценариев не займет огромное количество времени?"
"Конечно, но... Вы ведь всегда можете потребовать больше денег".
"Да, это правда. Но что насчет заинтересованности в этом клиентов?"
"Клиент так же может сэкономить время и деньги, когда вы заранее создаете подробные сценарии тестирования. Во-первых, потому что выполнение теста занимает меньше времени, и точно так же как в случае со скриптами вы точно знаете, что делать. Так выполнение тестов становится очень эффективным".
"Меньше времени тратится!"
"Вот именно! Но есть и другие преимущества. Скрипты можно сколько угодно использовать в дальнейшей разработке. Кроме того, тестировщиков можно отправить в отпуск или перевести в другой проект, ведь все написано! Есть эмпирическое правило - сценарии должны быть написаны настолько подробно, чтобы случайный прохожий, с которым вы встретились на парковке, смог бы выполнить тест".
"Звучит очень хорошо!" сказал мой собеседник и принялся снова записывать.
"Кое-что еще, - добавил он. - Я услышал, что во время конференции кто-то говорил про мультидисциплинарные команды. Ну знаете... Agile, DevOps, дизайнеры, разработчики, тестировщики - все в одной команде."
"Ох, не воспринимайте всё это так серьезно. Они быстро поменяют свое мнение по этому поводу. Мой шестой... Хм... На каком я остановился? Седьмой совет!"
7) "Попытайтесь получить тестовую команду изолированную от других проектных команд и представителей бизнеса".
Парень посмотрел на меня, чуть смутившись.
"Но когда они работают в одной команде - они работают ради одной цели". Может быть мой собеседник не так уж и глуп.
"Это в теории. Но на практике вы видите, что тестировщики работают над не-тестерскими задачами, а тестирование не получает должного внимание в мультидисциплинарных командах. Понимание качества со стороны дизайнеров и разработчиков очень слабое. Мы - стражи качества! Поэтому вы не хотите, чтобы работа тестовой команды зависела от разработчиков, менеджеров проекта или пользователей".
Мой собеседник смотрит в окно. Не слишком ли я далеко зашел?
"Но после всего этого уже можно начинать тестирование?" - продолжил он.
"Да, конечно. Но вот мой восьмой совет".
8) "Перед началом тестирования - убедитесь в том, что все предварительные условия, предположения, зависимости, критерии, риски, требования и тестовые условия - выполнены или одобрены командой проекта".
"Все?" - переспросил собеседник и немного побледнел.
"Конечно, - сказал я обиженно, - Вы же не хотите менять свой тестовый план уже во время выполнения тестов? Это не так эффективность, к которой вы стремитесь. И если не все предварительные условия, предположения, зависимости, критерии, риски, требования и предварительные условия... Ох, я сказал дважды "предварительные условия"? Я имел ввиду "тестовые условия". Если всё это не соблюдено, существует некая неопределенность. Неопределенность приводит к неэффективности. Тратится больше времени впустую. Вы хотите чтобы это случилось?"
"Нет, конечно, нет".
"Это именно то, о чем я говорю. Значит все предварительные условия, предположения, зависимости, критерии, риски, требования и тестовые условия должны быть соблюдены".
"Но теперь-то мы уже можем начинать тестирование, я полагаю?"
"О, да. На всех парах. И мы не будем терять времени зря - мой следующий совет:"
9) "Никогда не отходите от намеченного тестового сценария во время выполнения теста".
"Но что если что-то отличается от того, что мы обсуждали раньше?"
Я откинулся назад и махнул правой рукой.
"Обдумывание было сделано на этапе подготовки, поэтому вы не должны допускать никаких обсуждений во время выполнения тестов. Вы должны объяснить это "правило" заранее, иначе ценное время будет потрачено впустую, когда люди захотят обсудить сценарии, потому что плохо себя чувствуют, случилось что-то неожиданное или по другой глупой причине. И это займет уйму времени".
"Да, и никто не хочет, чтобы подобное случилось".
"Вот именно, Вы начинаете понимать это!" - с энтузиазмом сказал я.
"Значит, именно так Вы можете узнать, что тестовый проект - успешен?" - спросил он меня.
"Да. Последнее по списку, но не по значению - мой десятый совет".
10) "Тест-лид должен быть всегда уверен в том, что команда тестирования не отходит от плана тестирования."
"План настолько важен?""Конечно же! Вы одобрили его с клиентом и другими заинтересованными сторонами - значит вы должны это соблюдать. Когда план одобрен, единственное, что должен делать тест-лид - это мониторить следование плану и корректировать работу тестировщиков, которые из плана выпадают. Как тест-лид Вы решили, что тестируют ваши подопечные и как они тестируют - без каких-либо изменений по отношении к первоначальному плану."
"Но разве тестировщик не должен решать, что делать и как делать?"
"Абсолютно нет. Тест-лид обладает более богатым опытом, поэтому тестировщик должен его слушаться. Тест-лид знает план. Случится настоящий хаос, если каждый тестировщик начнет думать сам за себя".
"Да. И мы не хотим, чтобы наш тестовый проект стал хаотичным проектом".
"Именно так, мы этого не хотим. Поэтому всегда следуйте плану, чтобы ни случилось".
Я проверил дорожный траффик на моем айпаде - пробки уже не было.
"Что ж... Мне пора домой", - сказал я.
"Да, мне тоже. Спасибо вам за ваши советы. Вы мне очень помогли", - сказал парень.
"Ок, всего наилучшего, до скорых встреч" - сказал я перед тем как сесть в машину. Я улыбался всю дорогу до дома. Победа в этом тендере стала намного проще!
Авторы - Jan Jaap Cannegieter и Steven van Voorst.
Эта статья не основана на реальных событиях.
Хоть может показаться, что это шутливый рассказ, тем не менее он несет в себе серьезное сообщение.
Читатели могут подумать, что у авторов сложилось определенное мнение по поводу менеджеров по продажам. Но это не так. Менеджеры по продажам, как и тестировщики - все очень разные. Некоторые из них мало знают о тестировании, а у некоторых хватает знаний и энтузиазма для тестирования. И Ян, и Стивен очень счастливы работать вместе со вторым типом менеджеров, и поэтому призывают вас не судить о людях только по их должности или выполняемым функциям.
Оригинал:
Комментариев нет:
Отправить комментарий