דָּוִדdavidov777 (daviddavidov777) wrote,
דָּוִדdavidov777
daviddavidov777

мозговой штурм

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

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

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

Вначале одного из проектов, моей задачей было провести нагрузочное тестирование приложения. Вот, только незадача: у меня не было всего необходимого доступа к приложению, я это приложение в глаза никогда не видел. Я не знал, как оно работает. Я не знал, с какими данными оно работает, и понятия не имел о том, как им пользоваться. Я чувствовал, что нахожусь в тупике.
Но, у меня был доступ к физическому серверу приложения. Я мог поговорить с другими участниками проекта. У меня был доступ к документации на Sharepoint, только, к сожалению, документации там было настолько много, что я просто не знал, за что взяться. Но, я видел тоже, что видит сейчас мой знакомый – тупик, а не начало успешной работы над проектом.
Я был очень расстроен. Придя домой с работы, даже не включая компьютер, я включил свет, взял блокнот с ручкой, присел на кровать и спрашивал себя: Что я могу сделать? После первой записи в блокнот, я почувствовал себя лучше, и дело пошло намного быстрее. А записал я вот что:
Я могу поговорить с ведущим программистом П., возможно он сможет немного рассказать о приложении.
Я могу поговорить с разработчиками, и спросить их о том, чем они обеспокоены при работе с приложением.
Я могу попросить повышения уровня моего доступа к приложению у моего менеджера, а если не поможет, то на митинге с заказчиком.
Я могу начать писать тест план без доступа к приложению. Я знаю, что я буду тестировать, когда у меня будет возможность начать работать с приложением. А потом, я могу подправить план, по мере того, как я буду узнавать новую информацию. Кроме того, набросок плана тестирования поможет мне при разговоре с заказчиком.
Я могу представить себе, что уже получил доступ к приложению. Так что же я сделаю в первую очередь? А что следующее?
Я могу поговорить с менеджером проекта, и спросить ее, чего она ожидает от меня.
Я могу поговорить с другими тестеровщиками, и выяснить у них, какие узкие места есть у приложения, что они думают о тестировании приложения, в общем, все то, что только может быть мне полезным.

Тем же вечером, я отправил сам себе email со списком can-do на рабочую почту, и со следующего дня я начал делать все, чтобы начать работу с приложением, и преодолеть препятствия на моем пути. Через пару дней я начал работу и, что немало важно, показал свою заинтересованность в качественном выполнении задания перед начальством. Я вышел из тупика.

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

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

Can-Do против To-Do

Если вы дочитали до этого параграфа, то, скорее всего, задаетесь вопросом: А чем этот твой список Can-Do отличается от старого доброго To-Do? Очень, очень мало чем. Разница лишь в мотивации. Мне гораздо приятней помнить о том, что я могу сделать, чем о том, что я вынужден сделать. А вам?
Что лучше:
Я могу сходить завтра к стоматологу.

Или,
Сходить завтра к стоматологу. (Скрытый смысл: Я вынужден завтра сходить к стоматологу)

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

Списки Can-Do придают мне энергии. Если я чувствую себя в тупике – то я думаю о том, что я могу сделать, а не о том, что я вынужден или должен сделать.
Так что, если в следующий раз вы почувствуете себя в тупиковой ситуации, то спросите себя, что же вы можете сделать?

P.S: Список Can-Do – это результат мозгового штурма собственного мозга. Лично я предпочитаю текстовый вариант записи списка возможностей, но удобным будет и графический вариант, используя интеллект карты (Mind Maps)


Еще больше возможностей для мозгового штурма вы найдете тут! Заходите обращайтесь!
Tags: штурм
Subscribe
  • Post a new comment

    Error

    default userpic

    Your IP address will be recorded 

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 1 comment