Немного приятностей: меня приняли в роли докладчицы на SQA days 25, конференцию, которая будет проходить 31 мая и 1 июня в Питере.
Начинаем подготовку, чтобы не посрамить прекрасное имя компании и зарядить аудиторию настроением на то, что всё получится 💪🏻

О небезразличии

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

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

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

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

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

Я ответила: "QA-engineer should care" и пояснила, что лично мне бы хотелось искренне любить свой продукт - вот и всё, что нужно: тогда и средства организовать работу найдутся, и проверки не будут дежурными и, главное, мотивация будет неугасимая и искренняя.

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

Отличной всем недели. И увлекательных, интересных задач ☺️

Тема стара как мир, но вот, прочитав отличную статью на хабре о постановке QA-процесса в команде, где тестировщика ранее не было, я поняла, что готова сформулировать собственную точку зрения по этому поводу. Я не претендую на истинность, но хочу закрепить все свои размышления на тему - и таким образом поставить для себя точку в этом вопросе.

Как обычно, я рада обсуждению вопроса в ЛС. Если вам есть, что добавить, оспорить или уточнить - велкам!

Итак...

...Чем тестирование отличается от QA? И нужно ли искать отличие?

Чтобы ответить на этот вопрос, надо определить, что мы понимаем под каждым из этих процессов.

Силлабус ISTQB говорит на этот счет следующее:

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

Проще говоря, тестирование - процесс оценки состояния продукта, поставляемого пользователю, и всё, что для этой оценки нужно (в т.ч. подготовка, планирование, заведение дефектов и т.д.).

Wikipedia дополняет это определение термином QA:

Обеспечение качества (англ. Quality Assurance, QA) — это процесс или результат формирования требуемых свойств и характеристик продукции по мере её создания, а также — поддержание этих характеристик при хранении, транспортировании и эксплуатации продукции.

Таким образом, из двух определений выше можно сделать выводы:

1. Тестирование - часть процесса обеспечения качества (Quality Assurance, QA). Тестирование позволяет определить уровень качества продукта(ов) или функциональности, поставляемой клиентам.
2. Обеспечение качества - задача не только тестировщиков. Вся команда должна вносить свой вклад в обеспечение высокого уровня качества поставляемых продуктов и услуг.

Поэтому мне кажется, что сама формулировка "отличие тестирования от QA" не до конца корректна. Тестирование - не параллельный QA процесс, а лишь его часть. Более того, аналитика, разработка, менеджмент - тоже составляющие обеспечения качества продукта. Следовательно, для полноценного обеспечения качества продукта или функционала тестирование необходимо не противопоставлять QA, а грамотно сочетать эти два процесса для достижения лучшего результата.

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

Как тестировщик может улучшить качество продукта и помочь наладить процесс QA в команде?
Я не могу достоверно ответить на этот вопрос. Скорее всего, новые и новые ответы на него я буду искать в течение жизни :) Однако сейчас у меня есть ряд своих best practices, проверенных опытом, поэтому, пожалуй, сказать о них пару слов - неплохое начало этого пути.

Итак, как тестировщик я могу...

1. Контролировать качество продукта, начиная с ранних этапов: в первую очередь, проверять требования/спецификации на непротиворечивость и полноту.

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

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

4. Планировать работы по тестированию на этапе согласования требований.

5. Составлять и анализировать тестовое покрытие, а ещё поддерживать в актуальном состоянии тестовую документацию, по которой и происходит контроль состояния продукта.

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

7. Уметь понятно и подробно описать состояние продукта, количество готового, неготового и не полностью готового функционала, а также вывести риски, которые из этого вытекают, и дать рекомендации по оставшимся доработкам.

8. Помогать другим членам команды разделить ответственность за качество: объяснить разработчикам простые методики тестирования, поделиться своими чек-листами с командой, объяснить, насколько важна критичная для работы продукта фича и т.д.

Как остальные члены команды могут улучшить качество продукта?
Вопрос, так же, непростой. Вот мои докадки о возможных ответах на него:

1. Помнить, что каждый в команде сам по себе тестировщик: все тестируют то, чего они касаются. Написал код - протестируй его, или хотя бы разверни и посмотри, насколько результат близок к заданию (улыбка)
2. По возможности ввести в обиход практику код-ревью, следить за чистотой, читаемостью и понятностью кода.
3. Писать юнит-тесты и запускать их перед каждой сборкой для уверенности в том, что билд соответствует мнимальным требованиям качества.
4. Обращаться за помощью к QA-специалисту - в данном случае, тестировщику в команде, - при недопониманиях того, как работает (или должен работать) функционал. Время, потраченное на обсуждение и уточнение требований, всегда будет меньше, чем время на переделывание неверно понятой задачи, а ещё сэкономит нервы и команде, и тестировщику.
5. На начальных этапах обсудить, необходимы ли автотесты (как правило, GUI) со стороны тестировщика, и если да, учитывать это при создании элементов страниц - не делать динамические ID, давать понятные названия локаторам и т.д.

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

This. 👇🏼

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

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

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

Но чем дальше, тем проще.

О формуле лучшего проекта

Так получилось, что нынче я немного аутстаффер. Меня поставили на проект, в рамках которого я прошла собеседование во французскую команию, и теперь работаю с их задачами 100% своего времени. Это, конечно, дает бесценный опыт: во-первых, бизнес-отрасль для меня совершенно новая, во-вторых, работа в продуктовой компании всё же отличается от работы в аутсорсных проектах и психологией, и задачами, и командами, и ещё кучей факторов, и в-третьих, что самое важное (!), я без ума от всего происходящего :)

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

Кстати, на собеседовании один из вопросов был примерно о том же: что нужно, чтобы вы чувствовали себя комфортно при работе над проектом? Что заставит вас с радостью порсыпаться каждое утро и идти на работу с нетерпением?

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

Из внешних источников я узнала, что часто причиной потери интереса становятся либо непосильные задачи и завышенные ожидания от себя и от других, либо некомфортные условия труда - например, трудно дающееся общение в команде, пассивная агрессия, плохая коммуникация, либо отсутствие видимого результата. Все три пункта я у себя смело вычеркнула: ничего сверхъестественного от меня не ждут, я тоже вполне трезво оцениваю свои возможности; команда у меня замечательная (искренне желаю, чтобы всем удалось хоть раз поработать в таком коллективе, как у нас в Noveo), результат совершенно точно виден: и мой, и общий. Где же тогда лужа, Робин?

А лужа оказалась в самом неожиданном для меня (и, возможно, очевидном для остальных месте) - специфика проекта. С одной стороны, я четко понимала, какие задачи он решит и как всем поможет, но легче от этого не становилось. Из-за того, что это было b2b-решение, я не до конца понимала, что и зачем делаю. Вернее, я понимала, что нужно проверить, исходя из спеки и описаний, но я не представляла, зачем это нужно и почему именно эта часть функционала может быть важна.
Можно смотреть на ситуацию по-разному: не понимала предметную область работы - сама виновата; а может, и не стоит пытаться вылезти за рамки своей профессиональной компетенции и лезть в область бизнеса, оставляя это аналитикам. Я для себя решила, что мой девиз в даном случае - "делай что должен, и будь что будет" - и так как я делала что должна, винить себя мне не в чем.

И вот, получается, здесь и сидело моё маленькое лукавство: на самом деле, мне важно не столько то, чтобы проект решал чьи-то задачи и жизнь упрощал (потому что, по большому счёту, любой проект/продукт решает чью-то задачу и удовлетворяет потребность). Формула лучшего проекта в моем случае - это то, что я сама понимаю важность системы, могу поставить себя на место пользователя и разбираюсь в предметной области хотя бы немного.
Это простое и в то же время важное осознание накрыло меня внезапно на эскалаторе в метро, и я посчитала, что было бы грустно и нечестно не записать этот опыт - для себя будущей и, хочется надеяться, для кого-нибудь в аналогичной ситуации, кто не понимает, почему всё с проектом хорошо, но комфорта нет.

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

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

Детективные истории

Сидеть и выверять точные условия воспроизведения "мигающего" бага, который воспроизводится через раз, чтобы найти их в итоге И ЗАВОСПРОИЗВОДИТЬ ЕГО РАЗ 10 ПОДРЯД - это, пожалуй, одна из самых кайфовых деталей моей работы!!!

Вот представьте, если у вас есть онлайн-звонки с кучей параметров конфигурации, и почему-то иногда при одних и тех же конфигурациях и порядке действий звонок "падает", а при других нет.

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

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

Чувствую себя детективом, который по ниточке распутывал-распутывал сложное дело, и распутал. Как же меня прёт от этой работы! 🤩

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

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

Не секрет, что обучая других, ты и сам лучше вникаешь в темы. Я всегда думала, что это происходит за счёт повторения - а нет, не только, в ход идёт и анализ, который волей-неволей проводишь при проговаривании. В общем, учить — круто, учиться — ещё круче. Надеюсь, я никогда не перестану это делать.

Минутка ностальгии :)

Нашла сейчас в почте — случайно, по ключевому слову в архиве — тест-план, который я делала для Noveо, кажется, ровно 2 года назад, когда стремилась попасть на летнюю стажировку по направлению тестирования. Перечитала его и чуть не заплакала.

Помню, это был очень солнечный апрель, диплом был уже написан, стажировка PM подходила к концу, и я срочно искала, куда бы вложить свои силы и энтузиазм. В тот момент я уже загорелась тестированием и взахлеб штудировала http://www.protesting.ru/, книгу Савина, книгу Куликова (даже конспектировала в тетрадку и сама себе тесты составляла, простигосподе) и все разделы Хабра по тегу #тестирование. И вот — о счастье! — в Noveo открыт набор на летнюю стажировку по новому направлению: QA.

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

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

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

Кстати, если интересно подробнее о стажировках и прочем — ищите тут https://university.noveogroup.ru. Это на правах не рекламы, но искренней любви к месту, где начался и до сих пор продолжается мой профессиональный путь 🧡

Не надо учить технологии — учитесь решать задачи

В личке много ребят задают вопрос — как правильно выбрать технологии? Что учить, чтобы не отстать от прогресса?

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

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

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

Чем вы построите этот дом: шуруповертом, подъёмным краном или нанятой командой монтажников — не так уж важно. Важно ваше умение решать задачи, при необходимости включая в свой арсенал неизвестные ранее инструменты.

Общаемся с тимлидом команды тестирования в компании, над проектом которой я сейчас работаю (вроде подрядчицы).
Тимлид уж очень любит бюрократию.

Ситуация: есть новая фича, относительно крупная, которую нужно поскорее протестировать. Тимлид уже второй день ревьюит мой тест-комплект для этой фичи, мудро поправляя глупую девочку: надо писать не Check, а Click, ведь чтобы проверить вид дропдауна, нам надо сперва кликнуть на него.

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

Я не стою в белом пальто и прекрасно понимаю цену "чистоты" в любого рода документации. Но когда в продукте банально не работают важные для бизнеса фичи, а ответственный за качество человек выверяет формулировку тест-кейса, я начинаю задумываться о вечном и ценить процессы внутри нашей компании, потому что, как мне кажется, со всеми "бумажными" (в современных реализях гуглотабличными) нюансами работы QA надо не забывать о том, что главной ценностью всегда остается качество.

И, конечно, приоритеты. Идеальная тестовая документация — это прекрасно, но кому она нужна, если твой продукт не выполняет своих основных фунций?..

Итак, мой первый проект с автотестами!

Плюсы:
- изучила основы Java, достаточные для работы с библиотекой Selenium WebDriver
- закрепила знания из области ООП, которые получила около года назад
- чувствую себя как настоящая взрослая девочка 😎
- на практике столкнулась с BDD-фреймворком и теперь ответственно могу аргументировать свою неприязнь к BDD-инструментам практическими сценариями.

Минусы:
- не было выбора, с чем работать, так что пришлось кивнуть головой и начать писать клятые Given / When / Then.

Плюсов явно больше! И опыт, несомненно, интересный. Я лишний раз убедилась, что изучение и ЯП, и стредств для автотестирования происходит как-то активнее и мотивированнее, когда для этого есть четкая цель и потребность. Умение сесть и получить знания ради знаний — это офигенно, но не сравнится с решением "боевых" задач, даже самых простых.

На скрине, разумеется, сэмпл. Я же не хочу попасть под NDA ¯\_(ツ)_/¯

https://cucumber.io/docs/guides/bdd-tutorial/#executable-specifications - а вот в этом абзаце хорошо написано то, почему мне не очень нравится BDD.
Вернее, если сказать более корректно, его нередкое применение в виде инструмента для тестирования после того, как функциональность уже готова.
Против самого BDD-подхода у меня ничего нет, но проблема в том, что инструмент часто используется не по назначению. К сожалению, в моем текущем случае тоже, но я не в силах на это повлиять.

Так что будем мыслить позитивно и учить новый ЯП, а там разберемся :)

Вторая неделя написания автотестов. Полёт нормальный :)

Начиная со вчерашнего обеда и заканчивая сегодняшним вечером, я переписываю прошлонедельные тестики, оптимизируя их по принципу «меньше кода — больше проверок». Разумеется, сразу все не «взлетает»: приходится запускать и перезапускать тесты, искать в них ошибки, исправлять, — и снова здорОво. Мне это в кайф: новое занятие, возможность применить недавно полученные навыки и просто порадоваться удачно переписанным проверкам.
Моему тимлиду, внезапно для меня, мои тесты очень нравятся. А мне нравится моя работа ☀️

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

Дебаггинг — та же добыча радия.
В грамм добыча, в man-days труды.
Изводишь единого бага ради
Тысячи тонн гуглоруды.
Но как воодушевляет найти косяк в коде,
На стэковеофлоу не бросая клич!
Эти хотфиксы держат на проде
Тысячи лет миллионы фич.

Я ждала этого 12 лет в Азкабане!

Чем ближе выступление на конференции, тем труднее становится с этим фактом жить.

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

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

Боюсь не оправдать планку ожиданий, которую автоматически ставлю себе как спикеру (омфг, спикер! Могла ли я 2 года назад подумать, что жизнь будет бежать так стремительно, так быстро?). Боюсь осуждения слушателей, ещё больше боюсь их безразличия, и уж точно боюсь одобрения — это ведь повышение планки! И её надо будет держать!

Боюсь всего, но, как говорит англоязычная википедия, "Courage is the choice and willingness to confront agony, pain, danger, uncertainty, or intimidation". Храбрость — это выбор, и я делаю его. Я выбираю быть храброй каждый раз, зачеркивая дни до конференции, добавляя в доклад новые детали или убирая старые и, что важнее, откровенно рассказывая: да, это было, да этого я не знала, в этом до сих пор не уверена, но делаю всё, чтобы разобраться.

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

Сегодня генеральная репетиция доклада, а волнуюсь, как перед самим основным выступлением! 😬

Geez, провалиться на выступлении про провалы — это сильно. Земля мне пуховик, если я так же выступлю на самой конфе.

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

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

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

Просто жесть какая-то, просто жесть.