Тест дизайн VS дизайн кода

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

One common misconception is that when a programmer create a program, he simply sits down and start writting code.

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

А действительно, что еще надо то?) Сел и пиши код! А то, понимаешь, обсуждения ему подавай, ТЗ в нормальном виде пиши... Сел и пиши!

Однако, практика показывает, что такой подход превращается в разработку по стилю "code and fix". Это когда программист написал код, отдал тестировщику не глядя, тот нашел кучу ошибок "оно не запускается", программист поправил, тестировщик нашел ошибки "страница не открывается!!!", программист поправил, тестировщик наконец-то перешел к бизнес-логике и... ну вы поняли.

Чем плох такой подход? Тем, что очень много времени тратится на ошибки, которые стоило бы отловить на уровне компиляции проекта. Тем, что архитектура со временем превращается в "любая доработка = костыль!". Тем, что непродуманные решения приводят к такому исходу:

И именно поэтому! Существует так называемая "Sofware Design Documentation", которая включает в себя:

• Архетиктуру - документ, описывающий дизайн приложения в целом.
• Data Flow Diagram - диаграмма, показываюящая перемещение данных внутри программы.
• State Transition Diagram - диаграмма, показывающая переходы из одного состояния в другое.
• Flowchart - графическое изображение логики программы.
• Комментарии!!! Да да, самый простой и надежный способ вспомнить впоследствии, почему этот кусок кода в свое время был реализован именно так, а не иначе.

Таким образом, перед тем, как сесть, и что-то наваять, надо как минимум подумать над архитектурой.

И вы знаете, в этом мы очень похожи! Да-да! Ведь перед тем, как протестировать фичу, тестировщик тоже должен в первую очередь СЕСТЬ И ПОДУМАТЬ! Иначе никак, иначе это monkey-кликание, а не тестирование :)

Без элементов тест-дизайна тестировщик сможет сказать лишь "Bug looks fixed", потому что он протестирует ровно то, что описано в баге и ни шагу дальше. Ну или сделает шаг влево, шаг вправо, а все равно все не продумает, что-то да забудет. И в итоге - пропущен дефект. Кто виноват? ;)

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

И комментарии, кстати, комментарии! Даже в ручном тестировании они очень и очень полезны. Заливаете вы, например, файлик с данными для отчета. И все логично, все понятно. Файлик на всякий пожарный сохраняете. Потом проверяете другую ситуацию, делаете второй файлик...

А потом через месяц вам опять надо проверить этот отчет. Открываете вы папочку с файлами для заливки и... все. Какой файл для чего использовался? Где тут компании, где филиалы? Что же теперь, все открывать и изучать? А всего-то и надо было, добавить в папку description.txt, в котором сделать короткие комментарии - "*** - загрузка компаний, *** - загрузка филиалов" и тд. Самый тупой карандаш острее самой острой памяти!

Помните об этом! И будет вам счастье :)

Цель тестировщика

И снова вернемся к Рону Паттону и его книге "Software Testing".

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

The goal of a software tester is to find bugs.

Цель тестировщика - находить баги.

Как бы не так!

Просто найти баги - недостаточно. Ведь, если мы вспомним о стоимости ошибок:

То заметим, что, даже найденная тестировщиком, а не Заказчиком, ошибка может стоить проекту очень и очень дорого. Допустим, тестировщик внезапно обнаружил, что данное ПО не работает на Windows. Круто, молодец! Только завтра релиз и как, блин, это успеть исправить и протестировать? И где ты был раньше?

В общем, цель, на самом то деле, немного обширнее:

The goal of a software tester is to find bugs and find them as early as possible.

Цель тестировщика - находить баги и находить их как можно раньше.

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

Ну, теперь, казалось бы, все... Сами нашли, сами растоптали... Все довольны, да?

Не-а J

О чем же мы забыли? Чтобы это понять, достаточно сопоставить виртуальных вредителей с реальными. Вот обнаружили вы дома таракана и раздавили его. Все, дом теперь чист? Агащаз... Где один, там и много. Ну или другой пример, увидели таракана, кинули в него тапком - и что, вы думаете, он умер? Ага, от смеха, какой вы косой стрелок...

Помните важную истину - программистам верить нельзя! (я надеюсь, мои мой блог не читают :) ). Сказал, что починил? Сходи и проверь! Что действительно починил, и что ничего нигде не развалилось!

И теперь мы подобрались к настоящей цели:

The goal of a software tester is to find bugs and find them as early as possible, and make sure they get fixed.

Цель тестировщика - находить баги и находить их как можно раньше, и убедиться, что их действительно пофиксили.

Последняя часть определения очень важна! Commit it in memory!

Ну а если хотите узнать больше - прочитайте книгу сами :)

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

Приоритеты проекта

Представьте на минутку, что вы - менеджер проекта. И что отдел маркетинга неожиданно требует создать продукт на месяц раньше срока. Какова будет ваша реакция?

• Вы отложите реализацию определенных требований до более поздней версии?
• Сократите запланированный цикл тестирования системы?
• Оплатите сверхурочную работу вашим специалистам или пригласите специалистов по контракту для ускорения разработки?
• Привлечете ресурсы других проектов для разрешения ситуции?

Не правда ли, что, читая эти варианты, вы мысленно прикладывали их к себе и возмущенно отклоняли или наоборот, кивали головой - "да да, именно так и поступлю!"

А правильного ответа то и нет! Удивлены?

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

Пригласить специалистов по контракту? Да, вот Рекс Блэк об этом хорошо писал в своей книге. Там тест-менеджер очень удачно нашел применение простаивавшему оборудованию. Просто нанял контрактников. Довольно дешевая рабочая сила, работает во вторую смену, помогает основной команде выполнять нудную работу, чем плохо?)

Только вот стоят ли переплаты того?

И вот тут всплывает оно - решение задачи... А решение может быть разным! И зависит оно от приоритетов проекта. Волшебной палочки в виде единственно правильного ответа не существует :)

PS - пример был взят из книги Карла Вигерса "Разработка требований к ПО". Все статьи по книге:

[1] [2] [3] [4]

Что же такое - баг?

Ron Patton дает следующее опеределение загадочному слову software bug:

1. The software doesn`t do something that the product specification says it should do.
2. The software does something that the product specification says it shouldn`t do.
3. The software does something that the product specification doesn`t mention.
4. The software doesn`t do something that the product specification doesn`t mention but should.
5. The software is difficult to understand, hard to use, slow, or - in the software tester`s eyes - will be viewed by the end user as just plain not right.

Переводя на русский:

1. Продукт не делает что-то, что, согласно спецификации (далее - ТЗ), должен делать.
2. Продукт делает что-то, что, согласно ТЗ, делать не должен.
3. Продукт делает что-то, что в ТЗ не указано.
4. Продукт не делает что-то, что в ТЗ не указано, хотя должно.
5. Продукт очень сложный для понимания, трудный в использовании, медленный, или - глазами тестировщика, который смотрит на продукт как конечный пользователь,  делает что-то... просто не правильно!

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

Что не плохо, но!

Очень важным является именно 4 пункт. Фактически этот пункт означает ошибку в ТЗ. А, как все мы знаем, ТЗ тоже надо тестировать. На полноту, корректность, осуществимость, необходимость, проверяемость и недвусмысленность.

Что будет, если мы этого не сделаем? А будет то, что пользователь, пройдя по своему сценарию использования, будет возмущаться поведением продукта. Потому что оно "само собой подразумевалось". Ну, это хороший вариант развития событий. Бывают еще и другие, когда, например, из-за тяжелой реализуемости съезжают сроки. Или из-за сложной же проверяемости...

Но пользователю то важна двусмысленность! А точнее, ее отсутствие. И еще желательно, чтобы его мысли прочитали и реализовали даже то, чего не было в ТЗ :) Но должно было быть!

Поэтому - не забываем о том, что мы здесь собрались не только для того, чтобы сверить то, что есть, с тем, как это описали. Не забываем про 4 и 5 (!) пункты.

В пятом пункте говорится о том, что после нас - все. Обратного пути нет. Дальше с приложением будут работать уже реальные пользователи. И мы - та последняя инстанция, которая должна взглянуть на продукт не только с точки зрения "оно работает, как написано", но и с точки зрения того, кто в итоге будет с ним работать.

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

Просто помните о том, что тестирование - не поиск ошибок! :)

Несколько слов в защиту работодателя

Навеяно постом Александра Селяева и ссылкой на эти ужасные комиксы.

Ребята! Они вам правда нравятся?
Может, я чего-то не понимаю в этой жизни или перечиталась книг по уважению друг к другу, пора уже и сборник молодого троля перечитать?

Началось все с того, что утром, открыв software-testing.ru, я увидела там новые ссылки и пошла почитать. А потом минуту разглядывала картинку под заголовком "Нам интересно, но вы позвоните сами. 5 проверенных способов отпугнуть кандидатов от вашей компании", не понимая, после какой буквы в слове "лопата" надо смеяться.

Нет, теоритически оно, конечно, понятно. Это типа меткий и колкий ответ, ставящих работодателя с его тупыми вопросами на место. На разве это смешно?

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

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

Но допустим, что мы аналогичным образом рассылаем отклики на вакансии "Ваша вакансия меня заинтересовала. Мой опыт NN, резюме - ссылка". И нам даже отвечают, куда-то приглашают. Не будем лукавить, прежде, чем выбрать, мы пройдемся по нескольким местам.

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

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

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

И кстати, люди, не считающие нужным изучать место, в которое идут собеседоваться, вполне могут возмущаться "обезличенным хантам". Это не камень в сторону Александра, я не знаю, проявлял ли он ответное уважение :)

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

Вот... А еще в комиксе высмеян вопрос "Расскажите о себе". А что в нем-то плохого? Рекрутер вас в первый раз жизни видит! Да даже если он прочитал ваше резюме, ему все равно надо узнать про вас немного больше. Да, отвечать на этот вопрос в 10 раз подряд утомительно, но то, что вы часто ходите по собеседованиям - исключительно ваша проблема и ваше желание. Работодатель то чем виноват?

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

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

Нэнси Дуарте. Resonate. Захвати аудиторию своей яркой историей!

Ссылка на OZON.

Это вторая шедевральная книга Ненси Дуарте, мастера своего дела - создания презентаций.

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

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

Вся книга построена на эффекте резонанса. На грамотном переходе между тем, что было, и тем, что может быть...

Хочу процитировать отзыв Гая Кавасаки, который он дал еще для первой книги, но, я уверена, он применим к обеим:

После того, как Нэнси опубликовала свои книги, как вы будете оправдываться за свои длинные, скучные, бесполезные презентации?

Мне же особенно сильно врезалась в память одна фраза в начале книги, и рисунок рядом с ней:

Просто спроси себя: насколько сильно я хочу, чтобы моя идея жила?

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

Почему-то у меня именно такой ответ приходит на воспроминание о вопросе "хочешь ли ты, чтобы эта фраза жила?". Живи... "Живи, чтобы сказать", если говорить о человеке, который пытается донести эту мысль.

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

Прочитайте книги Дуарте и больше не оправдывайтесь за скучные и унылые презентации!



PS - Добавила книгу в общий список прочитанных мною книг.

Посиделки тестировщиков

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

Да, так вот. Встретили всех гостей, уютно расположились в комнатке, в которой есть и проектов, и доска для рисования... И даже выдали докладчикам презентор :)

Да-да, на нашей маленькой встрече были доклады. И даже не один, а целых два! Но об этом чуть позже... Вначале мы решили перезнакомиться. Люди рассказали, где работают и чем занимаются. Я тоже поделилась такой информацией. А так как мы встречались именно в "Human Factor Labs", то я заодно и показала, как мы работаем. С прошедшей ретроспективы осталась надпись: "плохое в релизе - нет разработки!!!". Ну, как нет... Вы же знаете этих гениев :) Все сделали и ворчат, что задачек нет ))))

А народ все подтягивался, вот и Виктория Птицина пришла :)

Ребята из Undev приветственно машут ей ручкой))

Да и остальные улыбаются, общаются. Нам, тестировщикам, есть о чем поговорить :))

А Андрей Мясников настраивается - он у нас первый докладчик, ответственная роль!

А мы проверяем. правильно ли он это делает - тестировщики же, как не проверить?

И вот! Настройка закончена! Начинается доклад!

Слушатели заинтригованы :)

А Андрюха продолжает свое выступление, не только рассказывая, но и показывая все сложности постановки процесса тестирования :)

А потом выступала Рина Ужевко. Да да! Та самая Рина, у который были самые афигенные слайды на SQA Days 11  Посмотрите ее выступление, если еще не видели)) А вот и новые красочные слайды made by Rina

Андрей мужественно снимал ее выступление на камеру (потому что я снимала его и рука уже устала)

А потом... Потом ребятам из Undev позвонили и в 9 часов вечера они побежали на работу, спасать свою команду! Вот где доблесть и мужество, в такое время - и работать!

Ну а мы не унывали! Ведь у нас был Alias! Так что посидели мы душевненько и без ребят (Алексей Баранцев тоже вскоре уехал, готовиться к тренингу). Разошлись только в 11 вечера и чисто потому, что на утро всем надо было идти на работу...

Эх, а так хорошо сидели! И так мало времени было! В общем, мы решили - на этот раз (который будет завтра) никаких докладов. Только небольшое упражнение для разминки по тест-дизайну (мы, тестировщики, такие, нас хлебом не корми, дай что-нибудь потестить или умных коллег послушать, знаний понабраться). А потом перейдем сразу к основной части доклада!

И кстати, по секрету расскажу - на завтрашнюю встречу еще есть пара мест. Так что кто успеет мне написать на почту ok.molechka@gmail.com - тот и молодец :) Первые 2-3 человека получат приглашение прийти :)))

Время встречи - 19.00. Место встречи вышлю успевшим ))
Плата за вход - печеньки

Цельная жизнь. Джек Кэнфилд, Марк Виктор Хансен и Лес Хьюитт

Ссылка на OZON.

В самом начале книга вызвала весьма противоречивые чувства.

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

• Неумение перезванивать вовремя;
• Привычка опаздывать на встречи;
• Неверный расчет времени на дорогу (слишком мало);
• Привычка несколько раз отключать будильник, прежде чем встать утром.
• и другие ...

Вот, кстати, последний пример плохой привычки меня сильно возмутил. Чем она плоха? Кому я, в конце концов, мешаю, переставляя будильник утром??? Да, я привычкла проснуться в 5.30, поспать полчасика, потом еще 10 минут и еще и еще... Чем плохо то? Если на работу я приезжаю или вовремя (если к 7 утра) или на полчаса раньше начала рабочего дня (если к 9)? Не считаю плохой и менять не собираюсь! И вообще. Дети будут - надо будет уметь вставать ночью!

Вот... Хотя приятно то, что некоторые распространенные привычки у меня отсутствуют. Например, я предпочитаю прийти пораньше, чем опоздать :) А, вот еще, странная "вредная" привычка - "привычка все время держать включенным сотовый телефон". Долго думала, чем это плохо о_О

ТМ-кейс. Рано пришел = больше успел?

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

Но зато! Куча плюшек. Можно доехать на машине, абалдеть как. В 6.40 вышел, в 7.05 уже на работе, в то время как на метро тебе час добираться. Можно и на метро, в конце концов, не у всех есть машины.

Основная часть народа приходит в 9-10 утра. Итого, в 7 пришел - два часа чистого времени. В первые недели мне это казалось дико - выходить, например, на работу в выходной. Сидишь себе там один (ну, почти)... Даже совета не у кого спросить! А вдруг застопится задача?

Но, с накоплением опыта работы ситуация стала видеться по другому :) В конце концов, у меня и вариантов было не много, часто отгулы брала в мае, постоянно в субботу выходила. Так вот! В конце концов ты наконец-то понимаешь. Что поработать и тишине и спокойствии - просто счастье :) Никто не отвлекает, не торопит... Хм, в общем то, в будни тоже никто не отвлекает и не торопит... Но это как-то не то :)

Все таки атмосфера одиночества... Помогает думать. И вот пожалуйста! Хоть каждый день - по два часа тихого-мирного отдыха. Да еще и уйти в 4 можно (если работу не провафлил обещанную). Представляете - вот только только на обед сходил - и уже уходить можно :))

Вот только отведенное вам время надо использовать с умом. А то, знаете как, если внезапно богатство в сказках привалило, народ начинает сходить с ума ))

А я вот попалась на ту же удочку, что и раньше. Иногда общение с Заказчиком отнимает много времени. Очень много. Весь день :((

Как и в тот день, который описан в ссылке выше, я сегодня попыталась "объять необъятное". С утра все начиналось хорошо, задач на мне мало, сыжу себе, втыкаю потихоньку в строчки кода, не покрытые автотестами, пытаясь понять, "о чем разговор" и стоит ли увеличивать тут покрытие. Заодно джиру новую попинала, посмотреть, как она отреагирует...

А потом... Потом, после 10 утра все вокруг внезапно проснулись. Посыпались вопросы и предложения от Заказчика. Раз, два, три, четыре, охохо, везде же ответить надо. А ответить, я вам скажу, дело не быстрое. Особенно, когда смотришь на монитор и размышляешь, как корректно свою мысль сформулировать. Я не хочу сказать, что на уме один мат)))) Я хочу сказать, что деловая переписка - это немного сложнее простого трепа в аське.

Да, так вот. Там написали, тут написали. Сижу, размышляю. Тут ответила, там пошла по коллегам за консультациями, стала составлять ответ... А тут уж и 12, и час... Ушли на обед. Вернулись - туда сюда, час пролетел незаметно. А там и ретроспектива. А там и "дом, милый дом". Не совсем дом, правда, вначале по делам...

Но суть то в чем? Да все в том же! Не поддавайтесь ежедневной суете! До 10 утра так у меня все хорошо шло. Я и посидела, помедитировала, вытащила на свет божий старые задачки, бережно смахнула с них пыль и перевела в правильный статус. И непосредственную работу поделала...

А как начала сразу 5 задач мониторить, так все. Ушла с чувством того, что весь день отвечала на письма. У Адама Джексона есть на эту тему замечательная глава "сила мгновения". Занялся работой? Нефиг отвлекаться! Сиди и делай. Сделал одно дело - бери другое. Ну и так далее. Намного эффективнее, чем взять все и сразу.

Фуф. В общем, на работе постоянно срываешься на сиюминутные цели (закрыть задачу, проревьюить, потестить, проверить...) и порой забываешь смотреть хоть немного шире. Отмахиваешься от того, чтобы дать себе минутку просто подумать - а была ли эта задача вообще интересной. Некогда, некогда... А жить то когда, если вечно некогда?

Если любая задача нейтральна, потому что "быстрей, быстрей и поехали дальше", то и работа надоест. Неинтересной станет. А ведь стоит остановится на мгновение, обернуться назад и... Поразиться тому, что это, оказывается (внезапно, да?) было интерсно! Поверьте, лучше дать себе эту минутку, которая наполнит вас покоем и чувством удовлетворения. И тогда можно будет совершать дальнейшие подвиги!

В общем, у меня уже есть план на понедельник :) И будет он не повтором неудачи, а другим - "Успеваем задуманное"! Куча дел. И главное - интересных дел :) Осталось только прийти пораньше и посидеть в тишине, подумать над тем, как все сделать лучше )) А сделав неотложное, выяснится, что торопиться больше то и некуда...

Учитесь слышать, а не слушать...

Часто во многих умных книжках можно прочитать о том, что не стоит сразу поддаваться волне праведного гнева, всегда можно спокойно обсудить ситуацию, какой бы возмутительной она не казалась вам на первый взгляд. И полезно задавать наводящие вопросы (спокойно и без наездов!) - возможно, вас даже не думали обижать?

Но как же так! Какие вопросы еще нужны, когда "из его слов и так все понятно!!!". Обиды, непонимания... Вы, наверное, думаете, что я опять отвлеклась от темы тестирования... Ан нет. Навеяно как раз случаем из практики.

На тестовом стенде, как вы знаете, всегда полезно воспроизводить ситуацию "с нуля". Что не очень удобно, когда у тебя уже есть куча тестовых данных. Поэтому на локальной машине я часто гоняю скрипты truncate + truncate {customer} + recreateSequences.

Тоже, согласитесь, утомительно. Особенно, когда воспроизводишь что-то - постоянно накатывать по 3 скрипта...Ну или объединить их в один, но все равно! Для простоты прогона в тестовых целях была создана специальная джоба.

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

И вот, очередной релиз. На тестовую платформе Заказчика поставку делаю я. Обновляю ПО, накатываю скрипты миграции на БД... А потом красочно описываю этот процесс для поставки на прод и пересылаю Заказчику с указанием новых фишечек релиза. В процесс для поставки боевой версии также вкрадывается пожелание делать бекапы всего и вся, а то мало ли...

Поставила, сообщила...

Приходит письмо - "Ольга, а вы случайно бекап БД не делали при поставке?"

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

Побежала узнавать у коллег - а должна была? Фуф, не должна... Так и пишу - "нет, не делала, а что-то случилось?"

"Хм... А после выполнения вашей джобы (транкейта, ага) можно как-то данные вернуть?"

Оп-па... Контекст то оказался совершенно другой. Причем, я бы сказала, кардинально другой.

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