Собор парижской автоматизации, или задачка про Квазимодо и Эсмеральду
А сегодня будет не размышление, а дилемма, и это как раз тот случай, когда я буду очень, очень, очень рада совету/отклику в личные собщения, потому что тема для меня важная.
QA - обепечение качества. Но что насчёт качества инструментов обеспечения качества?
Допустим, с вопросом писать или не писать автотесты я давно уже для себя всё решила: ускорить работу и избавиться от рутины вроде проверки наличия всех элементов/текстов на странице или возможности залогиниться/зарегистрироваться оказалось крайне приятно.
Другое дело, что встала новая проблема: оказывается, у тестов есть архитектура и шаблоны проектирования, и мои пошаговые сценарии - это лишь начальная ступень огромного неопознанного мира автоматизации (о чем я, конечно, знала, но от этого не стало менее больно осознавать, что твои нынешние тесты - фигня).
Собственно, ситуация такова: я умею писать простые пошаговые сценарии без всяких наворотов: просто кликнуть ссылку, ввести данные в инпут, отправить форму, проверить, что на странице есть текст и т.д. Я пишу их быстро, но сама понимаю, что это... чтобы не использовать слово "говнокод", буду называть их тесты-Квазимодо.
Ещё я (не так давно) научилась писать более красивые и универсальные тесты с некоторым подобием структуры (тут очень хочется сказать спасибо моему старшему коллеге Антону за терпеливые объяснения и готовность всегда помочь), но времени на них уходит значительно больше, потому что, откровенно говоря, с архитектурой кода любого рода я пока скорее на "Вы". Это будут тесты-Эсмеральда.
Передо мной большой проект, требующий регулярной регрессии хотя бы каких-то базовых функций - то есть смоук-тестирования - и рядом с ним два стула.
Стул №1: покрывать проект тестами-Квазимодо, но тратить на это немного времени, и таким образом автоматизировать - и сократить время на - регрессию.
Стул №2: пытаться в архитектуру, призывая тесты-Эсмеральду, но делать это медленно.
Отягощающие факторы: проект скоро закончится, то есть мой запас времени на написание тестов ограничен; кроме написания регрессионных тестов надо успевать тестировать новые фичи. Я понимаю, что обеспечить покрытие регрессии тестами-Эсмеральдой у меня не выйдет.
С другой стороны, элементы и локаторы в проекте довольно стабильны, так что для тестов-Квазимодо не возникает проблемы поддерживаемости кода.
Все обстоятельства как будто подталкивают меня к Квазимодо, и я даже не против. Однако пугают два момента:
1. Не стану ли я в целом кодить хуже, если сейчас намеренно сделаю шаг назад и вернусь к простым и некрасивым тестам?
2. Как вообще жить, зная, что ты несешь в этот мир плохой код, когда можешь делать его лучше? То есть ты пишешь плохо не потому, что не умеешь иначе из-за отсутствия опыта, а потому, что сама решила продолжать писать именно так, а не развиваться.
Стоит ли идти на сделку с совестью? Что лучше: покрыть проект такими вот проверками (результат будет хорошим, но я-то знаю, что под капотом всё плохо и уродливо) или уже продолжать тестировать всё руками, но делать это однозначно качественно?
Я вот для себя пока так и не решила. И это тот самый момент, когда очень жалеешь об отсутствии достаточного опыта, потому что автоматизировать очень хочется, но хочется это, как и остальную работу, делать хорошо.
А сегодня будет не размышление, а дилемма, и это как раз тот случай, когда я буду очень, очень, очень рада совету/отклику в личные собщения, потому что тема для меня важная.
QA - обепечение качества. Но что насчёт качества инструментов обеспечения качества?
Допустим, с вопросом писать или не писать автотесты я давно уже для себя всё решила: ускорить работу и избавиться от рутины вроде проверки наличия всех элементов/текстов на странице или возможности залогиниться/зарегистрироваться оказалось крайне приятно.
Другое дело, что встала новая проблема: оказывается, у тестов есть архитектура и шаблоны проектирования, и мои пошаговые сценарии - это лишь начальная ступень огромного неопознанного мира автоматизации (о чем я, конечно, знала, но от этого не стало менее больно осознавать, что твои нынешние тесты - фигня).
Собственно, ситуация такова: я умею писать простые пошаговые сценарии без всяких наворотов: просто кликнуть ссылку, ввести данные в инпут, отправить форму, проверить, что на странице есть текст и т.д. Я пишу их быстро, но сама понимаю, что это... чтобы не использовать слово "говнокод", буду называть их тесты-Квазимодо.
Ещё я (не так давно) научилась писать более красивые и универсальные тесты с некоторым подобием структуры (тут очень хочется сказать спасибо моему старшему коллеге Антону за терпеливые объяснения и готовность всегда помочь), но времени на них уходит значительно больше, потому что, откровенно говоря, с архитектурой кода любого рода я пока скорее на "Вы". Это будут тесты-Эсмеральда.
Передо мной большой проект, требующий регулярной регрессии хотя бы каких-то базовых функций - то есть смоук-тестирования - и рядом с ним два стула.
Стул №1: покрывать проект тестами-Квазимодо, но тратить на это немного времени, и таким образом автоматизировать - и сократить время на - регрессию.
Стул №2: пытаться в архитектуру, призывая тесты-Эсмеральду, но делать это медленно.
Отягощающие факторы: проект скоро закончится, то есть мой запас времени на написание тестов ограничен; кроме написания регрессионных тестов надо успевать тестировать новые фичи. Я понимаю, что обеспечить покрытие регрессии тестами-Эсмеральдой у меня не выйдет.
С другой стороны, элементы и локаторы в проекте довольно стабильны, так что для тестов-Квазимодо не возникает проблемы поддерживаемости кода.
Все обстоятельства как будто подталкивают меня к Квазимодо, и я даже не против. Однако пугают два момента:
1. Не стану ли я в целом кодить хуже, если сейчас намеренно сделаю шаг назад и вернусь к простым и некрасивым тестам?
2. Как вообще жить, зная, что ты несешь в этот мир плохой код, когда можешь делать его лучше? То есть ты пишешь плохо не потому, что не умеешь иначе из-за отсутствия опыта, а потому, что сама решила продолжать писать именно так, а не развиваться.
Стоит ли идти на сделку с совестью? Что лучше: покрыть проект такими вот проверками (результат будет хорошим, но я-то знаю, что под капотом всё плохо и уродливо) или уже продолжать тестировать всё руками, но делать это однозначно качественно?
Я вот для себя пока так и не решила. И это тот самый момент, когда очень жалеешь об отсутствии достаточного опыта, потому что автоматизировать очень хочется, но хочется это, как и остальную работу, делать хорошо.
👍1
Здравый смысл и разговор с парой замечательных людей помогли. Решила в итоге автоматизировать не ради автоматизации. План таков: тестировать руками все необходимое, параллельно писать автотесты с нормальной архитектурой (привет, Эсмеральда). Учиться писать тесты-Эсмеральду быстрее. Становиться хорошим специалистом, учиться не жертвовать ни качеством, ни темпом. Звучит как утопия. А может быть, как цель?
❤1
Например, сегодня отошла на пару минут, заблаговременно поставив подгружаться страничку, которую планировала тестировать, и заблокировав комп. Вернулась, разблокировала - а тут вот это. Я чуть не поседела от неожиданности, а это просто аватарка админа на весь экран растянулась по какому-то мистическому обстоятельству.
Сиди и думай после этого: это я тестирую всё вокруг или просто всё вокруг позволяет мне тестировать себя и подкидывает такие забавности? 🤔
Сиди и думай после этого: это я тестирую всё вокруг или просто всё вокруг позволяет мне тестировать себя и подкидывает такие забавности? 🤔
❤1
Субъективность понятия бага
В честь дня тестировщика немного философская тема о фундаментальном: что такое баг.
Примерно пару недель назад мы с другом арендовали машину в небезызвестной системе каршеринга, и установленное бесплатное 20-минутное бронирование подошло к концу до того, как мы дошли до автомобиля. По-еврейски не желая платить по 2,5 рубля в минуту, мы сбросили бронирование и тут же назначили новое, не зная, чего ожидать. Совершился лучший из возможных сценариев: счетчик снова вернулся на отметку “20”, и мы благополучно дотопали до машины, не переводя транспортное средство в платный режим.
И вот сегодня утром мы вспоминали тот случай, после чего я сказала: “Да, отличная фича”. “Но это не фича же”, - возразил друг. “Для владельцев системы, как для тех, кто получает с неё прибыль, это, конечно, баг. А для меня, как для пользователя - фича”, - я не могла согласиться.
Так где же вообще лежит эта граница между багом и фичей?
Если покопаться в определениях, мы найдем такие варианты:
Баг — запись (или «дефект») в системе отслеживания ошибок. (Википедия)
Баг — это отклонение фактического результата от ожидаемого результата (Р. Савин, Тестирование дот ком)
Дефект — расхождение ожидаемого и фактического результата (С. Куликов, Тестирование программного обеспечения)
Первая формулировка довольно малоинформативна, потому что рассматривает баг не как абстрактную неточность в работе программы, а просто привязывается к его оформлению в документах (грубо говоря, это как если бы чаем называли не сами сухие чайные листья, а пакетики, в которые их фасуют). Если следовать такому определению, то реши тестировщик занести в систему отслеживания ошибок запись с отрывком из пушкинского “Медного всадника”, формально это тоже будет багом.
Вторая и третья формулировки намного лучше, потому что определяют баг именно как факт несоответствия, расхождения, то есть нечто абстрактное и субъективное. И вот тут начинается самое интересное: ожидаемый результат предполагает наличие какой-то спецификации, требований к продукту, некоего унифицированного источника истины для вот этой конкретной программы/приложения.
А что делать, если спек нет? Чьё ожидание принимать за точку опоры, как в случае с тем же каршерингом: пользователя, который хочет подольше удерживать машину на месте бесплатно, или создателя, который хочет получить свои 25 рублей за 10 минут ожидания сверх нормы? Возможность забронировать одну машину два раза подряд - это недосмотр тестировщиков приложения или намеренное допущение со стороны владельцев продукта? От ответа зависит, в какую категорию - багов или фич - попадает наше открытие.
То, что было багом вчера, сегодня может стать фичей (или даже вполне себе задокументированным функционалом). Поэтому всегда стараюсь подумать, что будет удобно пользователю, чего хочет заказчик, что уже реализовано, каким образом это сделано. Это помогает расставить приоритеты: на первый план выходят именно ошибки, которые мешают системе выполнять её основные функции или не соответствуют заявленной документации, а уже после них можно подумать о спорных моментах вроде багофич, в которых многое зависит от глаз смотрящего. Тем не менее, стараюсь занести в систему багтрекинга всё, потому что если сомнительный момент окажется фичей, ничего не стоит закрыть задачку, однако если это будет пропущенный баг - упс.
Противоречива, конечно, работа тестировщика: вроде как имеешь дело с такой субъективной штукой, как баги, но при этом надо мыслить критически, объективно окидывать взглядом то, что имеешь, и выносить на обсуждение непонятки :)
<offtopic> Критическое мышление - ещё один момент, за который я обожаю своё заниятие.</offtopic>
В честь дня тестировщика немного философская тема о фундаментальном: что такое баг.
Примерно пару недель назад мы с другом арендовали машину в небезызвестной системе каршеринга, и установленное бесплатное 20-минутное бронирование подошло к концу до того, как мы дошли до автомобиля. По-еврейски не желая платить по 2,5 рубля в минуту, мы сбросили бронирование и тут же назначили новое, не зная, чего ожидать. Совершился лучший из возможных сценариев: счетчик снова вернулся на отметку “20”, и мы благополучно дотопали до машины, не переводя транспортное средство в платный режим.
И вот сегодня утром мы вспоминали тот случай, после чего я сказала: “Да, отличная фича”. “Но это не фича же”, - возразил друг. “Для владельцев системы, как для тех, кто получает с неё прибыль, это, конечно, баг. А для меня, как для пользователя - фича”, - я не могла согласиться.
Так где же вообще лежит эта граница между багом и фичей?
Если покопаться в определениях, мы найдем такие варианты:
Баг — запись (или «дефект») в системе отслеживания ошибок. (Википедия)
Баг — это отклонение фактического результата от ожидаемого результата (Р. Савин, Тестирование дот ком)
Дефект — расхождение ожидаемого и фактического результата (С. Куликов, Тестирование программного обеспечения)
Первая формулировка довольно малоинформативна, потому что рассматривает баг не как абстрактную неточность в работе программы, а просто привязывается к его оформлению в документах (грубо говоря, это как если бы чаем называли не сами сухие чайные листья, а пакетики, в которые их фасуют). Если следовать такому определению, то реши тестировщик занести в систему отслеживания ошибок запись с отрывком из пушкинского “Медного всадника”, формально это тоже будет багом.
Вторая и третья формулировки намного лучше, потому что определяют баг именно как факт несоответствия, расхождения, то есть нечто абстрактное и субъективное. И вот тут начинается самое интересное: ожидаемый результат предполагает наличие какой-то спецификации, требований к продукту, некоего унифицированного источника истины для вот этой конкретной программы/приложения.
А что делать, если спек нет? Чьё ожидание принимать за точку опоры, как в случае с тем же каршерингом: пользователя, который хочет подольше удерживать машину на месте бесплатно, или создателя, который хочет получить свои 25 рублей за 10 минут ожидания сверх нормы? Возможность забронировать одну машину два раза подряд - это недосмотр тестировщиков приложения или намеренное допущение со стороны владельцев продукта? От ответа зависит, в какую категорию - багов или фич - попадает наше открытие.
То, что было багом вчера, сегодня может стать фичей (или даже вполне себе задокументированным функционалом). Поэтому всегда стараюсь подумать, что будет удобно пользователю, чего хочет заказчик, что уже реализовано, каким образом это сделано. Это помогает расставить приоритеты: на первый план выходят именно ошибки, которые мешают системе выполнять её основные функции или не соответствуют заявленной документации, а уже после них можно подумать о спорных моментах вроде багофич, в которых многое зависит от глаз смотрящего. Тем не менее, стараюсь занести в систему багтрекинга всё, потому что если сомнительный момент окажется фичей, ничего не стоит закрыть задачку, однако если это будет пропущенный баг - упс.
Противоречива, конечно, работа тестировщика: вроде как имеешь дело с такой субъективной штукой, как баги, но при этом надо мыслить критически, объективно окидывать взглядом то, что имеешь, и выносить на обсуждение непонятки :)
<offtopic> Критическое мышление - ещё один момент, за который я обожаю своё заниятие.</offtopic>
❤1
Я всё это веду к тому, что в мире тестирования (и это одна из тех вещей, за которые я так люблю его) нет ничего фундаментального, каменно истинного, такого, что нельзя как-то ситуативно опровергнуть. Тестирование - это гибкость и некоторая субъективность, это огромная привязанность к ситуации и целям продукта, к приоритетам и, в конце концов, тому, как будет лучше для команды и конечного пользователя. А обеспечение качества - это забота, и начинается она изнутри.
❤1
Пространные рассуждения о профессиональной деформации QA
Ну раз уж у нас сегодня свой праздник ;)
Одна из моих любимых книг - знаменитое “Тестирование.com” Романа Савина. Я люблю её по многим причинам, несмотря на то, что многие моменты оттуда уже устарели (или просто не очень актуальны в аутсорсе). Например, это было первое, что я нашла, когда решила попробовать развивать себя в направлении QA, и я до сих пор помню ощущение трепета от новых, интересных знаний, поджидавших меня на страницах. Я честно выполняла все задания и следовала рекомендациям автора, одной из которых (едва ли не в первой же главе) стала следующая:
Находите в реальной жизни несоответствия ожиданий и реальности и мысленно отмечайте их: “баг”.
И вот примерно с весны 2017 - то есть с момента, когда я загорелась идеей стать QA - я стала искать “баги” в реальной жизни, но уже скоро они сами стали меня находить.
Шутки про мигающие лампочки - не шутки. Техника вокруг начинает вести себя непредсказуемо, внезапно вокруг появляются кучи неточностей, да и сам мир, кажется, иногда плывёт текстурами :D Я слышала шутки, что у тестировщиков есть “интуиция на дефекты”. Мне кажется, у этого явления вполне логичная природа.
Когда учишься постоянно наблюдать за происходящим, обращая внимание на максимум мелочей, который сможешь удержать в фокусе, рано или поздно это занятие превращается если не в рутину, то во что-то привычное. Тогда и думаешь: а это “интуиция” говорит мне, что страница ещё не готова, или просто я краем глаза заметила какую-то фигню, и теперь надо внимательно просканировать функционал и вид, чтобы понять, что именно вызвало этот подсознательный дискомфорт? Мне кажется, где-то тут начинается проф. деформация :)
Забавный пример: на днях шла пешком и услышала звук приближающейся из-за спины сирены. “Скорая”, - с уверенностью подумала я и не ошиблась. Потом в голову пришло, что в окружении того места, где я была, много больниц, а ещё, проходя мимо затора на дороге, я краем глаза заметила машину “скорой помощи”. Задумалась: было ли то, что я угадала машину, просто совпадением, или мозг в фоновом режиме соотнес факты выше и подсказал логично вытекающий ответ?
Как сказал мне коллега Влад, “возможно, многие тестировщики хоть раз мечтали стать детективами”. Трудно поспорить с этим: более того, я думаю, из большинства тестеров вышли бы отличные сыщики. Во всяких книжках про Шерлока Холмса зацепки, позволяющие раскрыть преступление, лежат в мелочах, а все - абсолютно все - мои знакомые QA эти мелочи отлично подмечают, будь то очепятка в тексте или маленькая тень эмоции на лице человека, которую тот пытается скрыть.
Интересно, то ли в QA идут те, кому не лень искать эти мелочи, то ли работа приучает их видеть. Но, на мой взгляд, такие загадки только добавляют шарма обеспечению качества 😏☺️
Ну раз уж у нас сегодня свой праздник ;)
Одна из моих любимых книг - знаменитое “Тестирование.com” Романа Савина. Я люблю её по многим причинам, несмотря на то, что многие моменты оттуда уже устарели (или просто не очень актуальны в аутсорсе). Например, это было первое, что я нашла, когда решила попробовать развивать себя в направлении QA, и я до сих пор помню ощущение трепета от новых, интересных знаний, поджидавших меня на страницах. Я честно выполняла все задания и следовала рекомендациям автора, одной из которых (едва ли не в первой же главе) стала следующая:
Находите в реальной жизни несоответствия ожиданий и реальности и мысленно отмечайте их: “баг”.
И вот примерно с весны 2017 - то есть с момента, когда я загорелась идеей стать QA - я стала искать “баги” в реальной жизни, но уже скоро они сами стали меня находить.
Шутки про мигающие лампочки - не шутки. Техника вокруг начинает вести себя непредсказуемо, внезапно вокруг появляются кучи неточностей, да и сам мир, кажется, иногда плывёт текстурами :D Я слышала шутки, что у тестировщиков есть “интуиция на дефекты”. Мне кажется, у этого явления вполне логичная природа.
Когда учишься постоянно наблюдать за происходящим, обращая внимание на максимум мелочей, который сможешь удержать в фокусе, рано или поздно это занятие превращается если не в рутину, то во что-то привычное. Тогда и думаешь: а это “интуиция” говорит мне, что страница ещё не готова, или просто я краем глаза заметила какую-то фигню, и теперь надо внимательно просканировать функционал и вид, чтобы понять, что именно вызвало этот подсознательный дискомфорт? Мне кажется, где-то тут начинается проф. деформация :)
Забавный пример: на днях шла пешком и услышала звук приближающейся из-за спины сирены. “Скорая”, - с уверенностью подумала я и не ошиблась. Потом в голову пришло, что в окружении того места, где я была, много больниц, а ещё, проходя мимо затора на дороге, я краем глаза заметила машину “скорой помощи”. Задумалась: было ли то, что я угадала машину, просто совпадением, или мозг в фоновом режиме соотнес факты выше и подсказал логично вытекающий ответ?
Как сказал мне коллега Влад, “возможно, многие тестировщики хоть раз мечтали стать детективами”. Трудно поспорить с этим: более того, я думаю, из большинства тестеров вышли бы отличные сыщики. Во всяких книжках про Шерлока Холмса зацепки, позволяющие раскрыть преступление, лежат в мелочах, а все - абсолютно все - мои знакомые QA эти мелочи отлично подмечают, будь то очепятка в тексте или маленькая тень эмоции на лице человека, которую тот пытается скрыть.
Интересно, то ли в QA идут те, кому не лень искать эти мелочи, то ли работа приучает их видеть. Но, на мой взгляд, такие загадки только добавляют шарма обеспечению качества 😏☺️
❤1
О саморазвитии
Мой первый наставник однажды отметил, что один из нюансов работы тестировщика - то, что приходится регулярно развиваться самостоятельно. Мне кажется, это вообще для IT вполне характерно, но особенность QA в том, что это относительно молодая область, поэтому материалов не так много, единой теории почти нет, терминология часто варьируется… Приходится копать и непрерывно анализировать, думать: насколько авторитетен источник? Не чушь ли пишет? Короче, примерно как при выборе лит-ры для диплома в универе :)
Поэтому я, почесав репу, выделила чисто для себя несколько хороших практик выбора и освоения материала для изучения. Хочу систематизировать их (ну и заодно вдруг кому-нибудь пригодится?) и попросить фидбека: возможно, есть какие-то советы, которые помогли лично вам? Для меня самообучение - приятный, но утомительный процесс, так что я ищу помощь с любой стороны!
Заранее прошу прощения за возможное кэпство: цель поста в первую очередь разложить всё по полочкам в своей голове, а для привнесения новизны у меня маловато опыта :)
1. Обращать внимание на дату публикации.
Слишком новые материалы могут быть ещё не проверены опытом, слишком старые - заменены чем-то поудобнее.
2. Источник и автор очень важны, но это не панацея от неточностей.
Блог IT-компании или авторитетного человека вроде Джеймса Уиттакера (http://www.docjamesw.com/), Джеймса Баха (http://www.satisfice.com/) или Святослава Куликова (https://svyatoslav.biz/) скорее всего будут надежнее, чем блоги простых тестировщиков, которые только учатся анализу и интроспективе (вроде вот этого телеграм-канала, например :D). С другой стороны, в менее авторитетных блогах можно встретить необычные идеи и интересные взгляды, а ещё они хороши, когда хочется убедиться, что не только у тебя бывают факапы.
3. Мыслить критически.
Тестировать, постоянно тестировать входящий поток информации. Чем абстрактнее тема, тем более критически мыслить.
4. Выбирать максимум источников.
Для кого-то это может быть сомнительный совет, но мне помогает :) Я люблю прочитать по теме всё, что найду, и подвести собственный итог, где выберу самое, на мой взгляд, полезное отовсюду.
5. Приоритизировать и расставлять ресурсы в очередь.
Чтобы не сойти с ума от многообразия статей и книг, воспользовавшись предыдущим советом :D Самое интересное/важное в начало, потом менее релевантные ресурсы.
6. Не дочитывать до конца.
Да, прям так! Сейчас многие специалисты по здоровому питанию твердят, что не стоит заставлять детей есть обед до конца и предлагают позволять им не доедать суп, чтобы сформировать здоровое отношение к пище. Примерно то же я отметила для себя в применении к информации: чтобы не отбить у себя желание изучать насовсем, нужно позволять себе не поглощать книги и статьи целиком, а выбирать только самое “вкусное”. В какой-то момент я даже выписала себе небольшие напоминалки, чтобы знать, в какой книге/статье какую тему можно посмотреть, потому что часто бывает, что, несмотря на общую “хорошесть” источника, есть какая-то основная глава-пуля, которая несет супер полезную информацию и характерна именно для этой книги.
7. Не торопиться и повторять.
Жизнь длинная, экзаменов пока не предвидится, так что можно перевести дыхание и спокойно учить то, что нужно, не умирая от переутомления. Лучше выбрать одну небольшую тему и долбить её, пока не отложится в голове, потом брать следующую, и так далее. Плохо с точки зрения моментального видения результата, но я на личном опыте поняла, что этот результат будет гораздо менее качественным, чем то, что дается многократным повторением и практикой.
8. Сразу применить знания на практике.
По возможности. Так запомнится лучше, плюс будет реальный опыт того, где можно использовать новые навыки :)
Мой первый наставник однажды отметил, что один из нюансов работы тестировщика - то, что приходится регулярно развиваться самостоятельно. Мне кажется, это вообще для IT вполне характерно, но особенность QA в том, что это относительно молодая область, поэтому материалов не так много, единой теории почти нет, терминология часто варьируется… Приходится копать и непрерывно анализировать, думать: насколько авторитетен источник? Не чушь ли пишет? Короче, примерно как при выборе лит-ры для диплома в универе :)
Поэтому я, почесав репу, выделила чисто для себя несколько хороших практик выбора и освоения материала для изучения. Хочу систематизировать их (ну и заодно вдруг кому-нибудь пригодится?) и попросить фидбека: возможно, есть какие-то советы, которые помогли лично вам? Для меня самообучение - приятный, но утомительный процесс, так что я ищу помощь с любой стороны!
Заранее прошу прощения за возможное кэпство: цель поста в первую очередь разложить всё по полочкам в своей голове, а для привнесения новизны у меня маловато опыта :)
1. Обращать внимание на дату публикации.
Слишком новые материалы могут быть ещё не проверены опытом, слишком старые - заменены чем-то поудобнее.
2. Источник и автор очень важны, но это не панацея от неточностей.
Блог IT-компании или авторитетного человека вроде Джеймса Уиттакера (http://www.docjamesw.com/), Джеймса Баха (http://www.satisfice.com/) или Святослава Куликова (https://svyatoslav.biz/) скорее всего будут надежнее, чем блоги простых тестировщиков, которые только учатся анализу и интроспективе (вроде вот этого телеграм-канала, например :D). С другой стороны, в менее авторитетных блогах можно встретить необычные идеи и интересные взгляды, а ещё они хороши, когда хочется убедиться, что не только у тебя бывают факапы.
3. Мыслить критически.
Тестировать, постоянно тестировать входящий поток информации. Чем абстрактнее тема, тем более критически мыслить.
4. Выбирать максимум источников.
Для кого-то это может быть сомнительный совет, но мне помогает :) Я люблю прочитать по теме всё, что найду, и подвести собственный итог, где выберу самое, на мой взгляд, полезное отовсюду.
5. Приоритизировать и расставлять ресурсы в очередь.
Чтобы не сойти с ума от многообразия статей и книг, воспользовавшись предыдущим советом :D Самое интересное/важное в начало, потом менее релевантные ресурсы.
6. Не дочитывать до конца.
Да, прям так! Сейчас многие специалисты по здоровому питанию твердят, что не стоит заставлять детей есть обед до конца и предлагают позволять им не доедать суп, чтобы сформировать здоровое отношение к пище. Примерно то же я отметила для себя в применении к информации: чтобы не отбить у себя желание изучать насовсем, нужно позволять себе не поглощать книги и статьи целиком, а выбирать только самое “вкусное”. В какой-то момент я даже выписала себе небольшие напоминалки, чтобы знать, в какой книге/статье какую тему можно посмотреть, потому что часто бывает, что, несмотря на общую “хорошесть” источника, есть какая-то основная глава-пуля, которая несет супер полезную информацию и характерна именно для этой книги.
7. Не торопиться и повторять.
Жизнь длинная, экзаменов пока не предвидится, так что можно перевести дыхание и спокойно учить то, что нужно, не умирая от переутомления. Лучше выбрать одну небольшую тему и долбить её, пока не отложится в голове, потом брать следующую, и так далее. Плохо с точки зрения моментального видения результата, но я на личном опыте поняла, что этот результат будет гораздо менее качественным, чем то, что дается многократным повторением и практикой.
8. Сразу применить знания на практике.
По возможности. Так запомнится лучше, плюс будет реальный опыт того, где можно использовать новые навыки :)
❤1👍1
На этой неделе загруз неимоверный, так что для мыслей в нерабочее в голове просто не остаётся места, а в рабочее всё занято проектами :)
Поэтому пока никаких размышлений или постов, просто с днём программиста всех 👩🏻💻👨🏻💻 Да будет классный код, поменьше багов и побольше здоровских задачек!
Поэтому пока никаких размышлений или постов, просто с днём программиста всех 👩🏻💻👨🏻💻 Да будет классный код, поменьше багов и побольше здоровских задачек!
❤1
О первых шагах в тестировании
Или просто немного полезностей для тех, кому интересно на себе понять, чем же занимаются QA. Мне повезло войти в профессию после прохождения курсов/стажировок, но что, если такой возможности нет, а познать область хочется?
Допустим, человек решил стать тестировщиком. С чего можно начать?
Наверное, хорошим первым шагом будет как раз понять, зачем изучающему всё это нужно - чтобы самому тестировать свои программы, чтобы стать тестером или просто из любопытства, - главное, чтобы существовала понятная цель. Без неё организовать себя и поддерживать дисциплину работы будет тяжеловато.
Второй шаг - подтянуть теорию и научиться более-менее оперировать терминами, а заодно осознать, что тестирование - молодая отрасль, в которой могут быть спорные моменты. In fact, критически мыслить надо начинать с самого начала.
Теоретических источников много, но вот мои любимые:
1. Видео-туториал на русском языке от СКБ Контур: https://ulearn.me/Course/Testing
2. Туториал на английском языке, совмещающий видео и краткий саммари-текст: https://www.guru99.com/software-testing.html
3. Из книг хороши следующие:
- Роман Савин - Тестирование.ком. Автор пишет живо и с юмором, но часть теории (впрочем, меньшая) устарела или просто мало где актуальна. Неплохой старт, но её нельзя считать настольной книгой современного QA.
- Святослав Куликов - Тестирование программного обеспечения. Очень хорошая книга, регулярно обновляется на официальном сайте, однако есть и "стабильная" неизменяемая версия. Сам блог автора тоже очень интересный, кстати, но об этом несколько позже. Может по праву считаться одной из лучших книг для быстрой консультации по теоретическим вопросам.
- Сэм Канер - Тестирование программного обеспечения. Неплохая, но немного неоднозначная книга. Как мне кажется, из неё хорошо брать технические сведения, а вот философскую часть лучше оставить на потом, чтобы изначально не запутаться в некоторых противоречиях с отечественной школой тестирования.
- И последний в начальном списке, но не по значимости - мой нежно любимый Джеймс Уиттакер - Exploratory Testing. Книга на русский не переведена, но очень уж она хороша, стоит времени прочтения (ради неё я была бы рада выучить английский до приличного уровня 🙂). Там рассказывается не только про уникальную методику исследовательских туров, но и про тестирование как процесс в целом, а ещё представляются некоторые инетерсные задачки "на подумать", без очевидно правильного ответа, - просто чтобы размять мозги и вспомнить, что знать всё на свере нереально :) Они восхитительна, и она, пожалуй, для меня любимейшая книга на профессиональную тему.
Итак, мотивация и цель есть, теория проштудирована, - что теперь?
Третий этап - обозначить себе цели и понять, куда планируешь двигаться и чего хочешь достичь в ближайшее время. Хочется ли изучающему тестировать игры, работать в продуктовой компании или в аутсорсе? Можно ознакомиться с миром разработки, сначала поверхностно, затем глубже. Узнать о методологиях разработки, типах команд и т.д. Попробовать вникнуть, что именно требуется от тетировщика, какова его роль в команде, возможно, обратиться с вопросами к кому-то, кто уже тестирует в компании/направлении, которое потенциально инетерсует. И очень крутая тема - составить хотя бы абстрактный план и следовать ему, чтобы чтение книг и поиск материалов не превратились в бесконечное шатание по горам информации, которая в итоге нигде не сохраняется и не применяется.
Далее надо практиковаться. Можно попробовать участвовать в краудсорсинговом тестировании: есть платформы, где тестировщики могут зарегистрироваться и попробовать себя на благо какой-нибудь компании. Это будет не только отличный опыт перед первой работой, но и возможность просто посмотреть, как всё происходит "в деле", пообщаться с другими людьми и стать чуть ближе к желаемому.
Или просто немного полезностей для тех, кому интересно на себе понять, чем же занимаются QA. Мне повезло войти в профессию после прохождения курсов/стажировок, но что, если такой возможности нет, а познать область хочется?
Допустим, человек решил стать тестировщиком. С чего можно начать?
Наверное, хорошим первым шагом будет как раз понять, зачем изучающему всё это нужно - чтобы самому тестировать свои программы, чтобы стать тестером или просто из любопытства, - главное, чтобы существовала понятная цель. Без неё организовать себя и поддерживать дисциплину работы будет тяжеловато.
Второй шаг - подтянуть теорию и научиться более-менее оперировать терминами, а заодно осознать, что тестирование - молодая отрасль, в которой могут быть спорные моменты. In fact, критически мыслить надо начинать с самого начала.
Теоретических источников много, но вот мои любимые:
1. Видео-туториал на русском языке от СКБ Контур: https://ulearn.me/Course/Testing
2. Туториал на английском языке, совмещающий видео и краткий саммари-текст: https://www.guru99.com/software-testing.html
3. Из книг хороши следующие:
- Роман Савин - Тестирование.ком. Автор пишет живо и с юмором, но часть теории (впрочем, меньшая) устарела или просто мало где актуальна. Неплохой старт, но её нельзя считать настольной книгой современного QA.
- Святослав Куликов - Тестирование программного обеспечения. Очень хорошая книга, регулярно обновляется на официальном сайте, однако есть и "стабильная" неизменяемая версия. Сам блог автора тоже очень интересный, кстати, но об этом несколько позже. Может по праву считаться одной из лучших книг для быстрой консультации по теоретическим вопросам.
- Сэм Канер - Тестирование программного обеспечения. Неплохая, но немного неоднозначная книга. Как мне кажется, из неё хорошо брать технические сведения, а вот философскую часть лучше оставить на потом, чтобы изначально не запутаться в некоторых противоречиях с отечественной школой тестирования.
- И последний в начальном списке, но не по значимости - мой нежно любимый Джеймс Уиттакер - Exploratory Testing. Книга на русский не переведена, но очень уж она хороша, стоит времени прочтения (ради неё я была бы рада выучить английский до приличного уровня 🙂). Там рассказывается не только про уникальную методику исследовательских туров, но и про тестирование как процесс в целом, а ещё представляются некоторые инетерсные задачки "на подумать", без очевидно правильного ответа, - просто чтобы размять мозги и вспомнить, что знать всё на свере нереально :) Они восхитительна, и она, пожалуй, для меня любимейшая книга на профессиональную тему.
Итак, мотивация и цель есть, теория проштудирована, - что теперь?
Третий этап - обозначить себе цели и понять, куда планируешь двигаться и чего хочешь достичь в ближайшее время. Хочется ли изучающему тестировать игры, работать в продуктовой компании или в аутсорсе? Можно ознакомиться с миром разработки, сначала поверхностно, затем глубже. Узнать о методологиях разработки, типах команд и т.д. Попробовать вникнуть, что именно требуется от тетировщика, какова его роль в команде, возможно, обратиться с вопросами к кому-то, кто уже тестирует в компании/направлении, которое потенциально инетерсует. И очень крутая тема - составить хотя бы абстрактный план и следовать ему, чтобы чтение книг и поиск материалов не превратились в бесконечное шатание по горам информации, которая в итоге нигде не сохраняется и не применяется.
Далее надо практиковаться. Можно попробовать участвовать в краудсорсинговом тестировании: есть платформы, где тестировщики могут зарегистрироваться и попробовать себя на благо какой-нибудь компании. Это будет не только отличный опыт перед первой работой, но и возможность просто посмотреть, как всё происходит "в деле", пообщаться с другими людьми и стать чуть ближе к желаемому.
❤1👍1
После всего этого (да и на протяжении изучения тоже) необходимо искать новый материал, развиваться и закреплять всё хотя бы простыми задачками. Так как постоянно появляется что-то новое, быть в курсе и идти в ногу с отраслью - вполне себе бонтон.
В принципе, если с достатоным усердием подойти к самообучению, то, я уверена, стать хорошим начинающим специалистом вполне реально. Главное - любить то, чем занимаешься, и помнить об этом даже в трудные моменты ☀️
В принципе, если с достатоным усердием подойти к самообучению, то, я уверена, стать хорошим начинающим специалистом вполне реально. Главное - любить то, чем занимаешься, и помнить об этом даже в трудные моменты ☀️
❤1👍1
Как ручному тестировщику выжить в мире автоматизации?
Так получилось, что в последнее время я не особо писала сюда, хотя мысли были.
Поэтому пока, чтобы совсем не теряться, поделюсь своим косеньким, но с душой сделанным переводом одной прекрасной статьи (ссылка на оригинал для ценителей английского есть в конце) в блог родной компании: https://blog.noveogroup.ru/2018/10/3-sposoba-vnesti-vklad-v-kachestvo/
Когда я выбираю тему переводимой статьи, стараюсь брать только те, с которыми сама согласна, и этот пост - одна из важнейших проблем, которая, наверное, посещала любого, кто не хочет или не умеет писать код.
Что ж, надеюсь, эта заметка хотя бы немного поможет сомневающимся (или просто немного развеет миф, что у т.н. "ручного" тестирования нет будущего).
Так получилось, что в последнее время я не особо писала сюда, хотя мысли были.
Поэтому пока, чтобы совсем не теряться, поделюсь своим косеньким, но с душой сделанным переводом одной прекрасной статьи (ссылка на оригинал для ценителей английского есть в конце) в блог родной компании: https://blog.noveogroup.ru/2018/10/3-sposoba-vnesti-vklad-v-kachestvo/
Когда я выбираю тему переводимой статьи, стараюсь брать только те, с которыми сама согласна, и этот пост - одна из важнейших проблем, которая, наверное, посещала любого, кто не хочет или не умеет писать код.
Что ж, надеюсь, эта заметка хотя бы немного поможет сомневающимся (или просто немного развеет миф, что у т.н. "ручного" тестирования нет будущего).
❤1👍1
Вообще не люблю разделение понятия тестирования на "ручное" и "автоматизированное", если речь о чем-то большем, чем об инструментах выполнения тестов (и то, как мне кажется, в таком случае лучше так и говорить: ручные/автоматизированные ТЕСТЫ, а не тестировщики).
Мыслями про то, какие классовые неравенства и, хуже всего, непонимания самой сути процесса обеспечения качества это влечёт за собой, я ещё обязательно поделюсь 👩🏻💻
Мыслями про то, какие классовые неравенства и, хуже всего, непонимания самой сути процесса обеспечения качества это влечёт за собой, я ещё обязательно поделюсь 👩🏻💻
❤1
Инструменты, которые могут помочь тестировщику в работе
Вчера посчастливилось выступить на митапе SPb SQA Group - оставлю запись тут.
Эту тему мы с моим ментором Антоном уже освещали внутри компании. Фидбек был позитивным, так что доклад пошёл дальше! :)
Получилось немного по-капитански, но, с другой стороны, собрание полезных утилит никогда не будет лишним, верно?
https://youtu.be/60Wfa5wmePY
Вчера посчастливилось выступить на митапе SPb SQA Group - оставлю запись тут.
Эту тему мы с моим ментором Антоном уже освещали внутри компании. Фидбек был позитивным, так что доклад пошёл дальше! :)
Получилось немного по-капитански, но, с другой стороны, собрание полезных утилит никогда не будет лишним, верно?
https://youtu.be/60Wfa5wmePY
❤1
Почему нельзя стать хорошим автоматизатором, не овладев ручным тетированием на практике?
На эту заметку меня натолкнуло создание тренинга по введению в автоматизацию тестирования - вспомнилось, как я сама в неё входила. Это было весело. И поучительно - для себя на совём же примере :)
Когда я только закрыла испытательный срок и расправила плечи как полноценная джуниор-тестировщица, я была совершенно нетерпеливой, и хотела всего и поскорее - и, разумеется, готова была хоть в лепешку разбиться, лишь бы достичь желаемого. Таинственное слово "автоматизация" манило меня, а коллеги, овладевшие заветной силой, казались сверхлюдьми - и, уж поверьте, я мечтала присоединиться к этому прекрасному идеальному миру.
Я начала срочно искать туториалы в Сети, устанавливать пакеты, драйвера, - всё, что видела и что казалось мне полезным, даже если не было особого понимания собственных действий. Вылилось ли это в какой-то результат? Ну, возможно, мне были знакомы какие-то инструменты, когда я начала посещать курсы автоматизации внутри нашей компании :) На этом всё - а времени было потрачено немало.
Основная задача автоматизации - облегчить рутину и уменьшить так называемый эффект (парадокс) пестицида (см. http://software-testing.ru/library/testing/testing-for-beginners/1202-pesticide-paradox), с которым рано или поздно сталкиваются все тестировщики. Но готов ли тестировщик к тому, чтобы начать автоматизировать - другой вопрос.
Я представляю экзоскелет (питаю слабость к роботоподобным гаджетам 🤷🏻♀️), надев который, человек получает +20 к силе, +50 к скорости и +30 к ловкости. Несомненно, если сравнить физические показатели одного и того же достаточно умелого человека без и с надетым устройством, мы обнаружим, что использование экзоскелета действует на пользователя исключительно благотворно.
Однако если человек, надевший его, не был особо ловким и до использования устройства, то новая амуниция может принести лишь проблемы - невозможно научиться хорошо бегать, если не умеешь уверенно стоять на ногах. И уж тем более не выйдет ничего хорошего, если внутри навороченного девайса не будет мудрого и грамотного пользователя, который сможет не только выжать из устройства максимум, но и увеличить общий КПД за счёт собственных навыков и сил. В моём случае автоматизация была тем самым экзоскелетом, а человек внутри него - тестировщица, которая очень хочет получить обещанные перки.
Чем опытнее тот, кто сидит внутри, тем сильнее и качественнее получается дуэт машины и человека. Наоборот, в неумелых руках автоматизация может стать настоящей проблемой - тестов много, все сценарии покрыты, но стОит внести хотя бы небольшие изменения в код проекта - и система тестов падает, как карточный домик, пропускает баги и требует столько времени на поддержку, что совершенно перестаёт оправдывать своё использование.
Поэтому мой практический вывод - не стоит гнаться за автотестами ради наличия самих автотестов и звания "автоматизатор". В идеале надо уметь грамотно интегрировать автотесты в проект, а если не получается - лучше хорош проверить продукт руками, чем потратить много времени и сил на то, что не результирует в то, за чем мы гонимся и что является основной целью нашей профессии - качество конечного продукта и счастье пользователей.
На эту заметку меня натолкнуло создание тренинга по введению в автоматизацию тестирования - вспомнилось, как я сама в неё входила. Это было весело. И поучительно - для себя на совём же примере :)
Когда я только закрыла испытательный срок и расправила плечи как полноценная джуниор-тестировщица, я была совершенно нетерпеливой, и хотела всего и поскорее - и, разумеется, готова была хоть в лепешку разбиться, лишь бы достичь желаемого. Таинственное слово "автоматизация" манило меня, а коллеги, овладевшие заветной силой, казались сверхлюдьми - и, уж поверьте, я мечтала присоединиться к этому прекрасному идеальному миру.
Я начала срочно искать туториалы в Сети, устанавливать пакеты, драйвера, - всё, что видела и что казалось мне полезным, даже если не было особого понимания собственных действий. Вылилось ли это в какой-то результат? Ну, возможно, мне были знакомы какие-то инструменты, когда я начала посещать курсы автоматизации внутри нашей компании :) На этом всё - а времени было потрачено немало.
Основная задача автоматизации - облегчить рутину и уменьшить так называемый эффект (парадокс) пестицида (см. http://software-testing.ru/library/testing/testing-for-beginners/1202-pesticide-paradox), с которым рано или поздно сталкиваются все тестировщики. Но готов ли тестировщик к тому, чтобы начать автоматизировать - другой вопрос.
Я представляю экзоскелет (питаю слабость к роботоподобным гаджетам 🤷🏻♀️), надев который, человек получает +20 к силе, +50 к скорости и +30 к ловкости. Несомненно, если сравнить физические показатели одного и того же достаточно умелого человека без и с надетым устройством, мы обнаружим, что использование экзоскелета действует на пользователя исключительно благотворно.
Однако если человек, надевший его, не был особо ловким и до использования устройства, то новая амуниция может принести лишь проблемы - невозможно научиться хорошо бегать, если не умеешь уверенно стоять на ногах. И уж тем более не выйдет ничего хорошего, если внутри навороченного девайса не будет мудрого и грамотного пользователя, который сможет не только выжать из устройства максимум, но и увеличить общий КПД за счёт собственных навыков и сил. В моём случае автоматизация была тем самым экзоскелетом, а человек внутри него - тестировщица, которая очень хочет получить обещанные перки.
Чем опытнее тот, кто сидит внутри, тем сильнее и качественнее получается дуэт машины и человека. Наоборот, в неумелых руках автоматизация может стать настоящей проблемой - тестов много, все сценарии покрыты, но стОит внести хотя бы небольшие изменения в код проекта - и система тестов падает, как карточный домик, пропускает баги и требует столько времени на поддержку, что совершенно перестаёт оправдывать своё использование.
Поэтому мой практический вывод - не стоит гнаться за автотестами ради наличия самих автотестов и звания "автоматизатор". В идеале надо уметь грамотно интегрировать автотесты в проект, а если не получается - лучше хорош проверить продукт руками, чем потратить много времени и сил на то, что не результирует в то, за чем мы гонимся и что является основной целью нашей профессии - качество конечного продукта и счастье пользователей.
👍1
Прекрасная статья на Хабре, не поделиться которой было бы грешновато: https://habr.com/company/funcorp/blog/426759/
Хабр
Образ современного тестировщика. Что нужно знать и уметь
Бытует мнение, что простейший путь к IT лежит через тестирование. Мол, знать ничего не нужно, уметь и подавно, достаточно желания и готовности не сильно щурить...
👍1
Про митапы
Так как лето и осень этого года оказались для меня совершенно необычными в плане приобретения нового опыта, - а именно выступлений на публике на профессиональные темы и посещения кучи различного рода митапов, - мне захотелось немного описать свои впечатления от этих событий и некоторыми фактами, которые оказались для меня весьма неожиданными.
Во-первых, очень хочется отметить, что, вопреки всем ожиданиям, принять участие в митапе оказалось не так сложно, как я представляла себе. Главное, чем стоит руководствоваться - желание донести до публики что-то полезное. Как я поняла, исходя из общения с товарищами, очень ценятся истории из личного опыта и рассказы о том, как команда для себя решила ту или иную проблему. Парадоксально, что при этом желательно не углубляться в частности, иначе этот опыт будет пусть и ценен, но трудно применим, а значит, его полезность для других автоматически снижается. Ты можешь быть джуном или сениором - не так важно, потому что сложно скорее не поучаствовать, а сделать так, чтобы участие было действительно стОящим.
Во-вторых, подготовка определяет почти всё. Немного очевидная штука, да, но это я больше к тому, что не стоит волноваться о размере аудитории, сложности темы и прочем, если есть возможность хорошенько прошерстить всё заранее. Чем больше времени от заявки до мероприятия - тем лучше.
В-третьих, как показала практика, уровень риторических навыков докладчика действительно решает. Мне встречались доклады с действительно интересной темой, где спикер не мог донести свою мысль ясно, и очень простые и, возможно, кэпские доклады с отличной подачей и классной визуальной частью, такие, что ни капли не жалеешь о том, что потратил время на прослушивание уже известных вещей. В каком-то смысле доклад - это перформанс: разумеется, не надо перегибать палку и читать материал стоя на голове, но добавить немного интерактива, шуток и яркости - очень хорошая практика.
В-четвертых, для меня было сюрпризом было узнать, что докладчики тоже люди, которые могут быть неуверенными, напуганными, уставшими - жизнь случается в любой момент, и пусть уровень подготовки (смотри п.2) поможет снизить волнение, совсем избежать его, наверное, не получится почти ни у кого. Необычно понимать, что вот этот крутой человек с кучей опыта тоже волнуется :) Можно помочь спикерам, будучи благодарной и дружелюбной публикой. Стараюсь по возможности улыбаться докладчикам, не фыркать скептически, даже если не согласна, и по возможности благодарить за доклад после выступления. В конце концов, всегда приятно, когда твои старания ценят хотя бы чуть-чуть :)
Вместо вывода вкину соображение: как мне кажется, чтобы увереннее выступать, нужно больше выступать. Преодолевать стеснение, придумывать или подбирать интересные темы, взаимодействовать с публикой. И любить своё дело, а как же иначе :) Потому что нет лучшей приправы к хорошему докладу, чем искренний интерес и огонь в глазах спикера!
Так как лето и осень этого года оказались для меня совершенно необычными в плане приобретения нового опыта, - а именно выступлений на публике на профессиональные темы и посещения кучи различного рода митапов, - мне захотелось немного описать свои впечатления от этих событий и некоторыми фактами, которые оказались для меня весьма неожиданными.
Во-первых, очень хочется отметить, что, вопреки всем ожиданиям, принять участие в митапе оказалось не так сложно, как я представляла себе. Главное, чем стоит руководствоваться - желание донести до публики что-то полезное. Как я поняла, исходя из общения с товарищами, очень ценятся истории из личного опыта и рассказы о том, как команда для себя решила ту или иную проблему. Парадоксально, что при этом желательно не углубляться в частности, иначе этот опыт будет пусть и ценен, но трудно применим, а значит, его полезность для других автоматически снижается. Ты можешь быть джуном или сениором - не так важно, потому что сложно скорее не поучаствовать, а сделать так, чтобы участие было действительно стОящим.
Во-вторых, подготовка определяет почти всё. Немного очевидная штука, да, но это я больше к тому, что не стоит волноваться о размере аудитории, сложности темы и прочем, если есть возможность хорошенько прошерстить всё заранее. Чем больше времени от заявки до мероприятия - тем лучше.
В-третьих, как показала практика, уровень риторических навыков докладчика действительно решает. Мне встречались доклады с действительно интересной темой, где спикер не мог донести свою мысль ясно, и очень простые и, возможно, кэпские доклады с отличной подачей и классной визуальной частью, такие, что ни капли не жалеешь о том, что потратил время на прослушивание уже известных вещей. В каком-то смысле доклад - это перформанс: разумеется, не надо перегибать палку и читать материал стоя на голове, но добавить немного интерактива, шуток и яркости - очень хорошая практика.
В-четвертых, для меня было сюрпризом было узнать, что докладчики тоже люди, которые могут быть неуверенными, напуганными, уставшими - жизнь случается в любой момент, и пусть уровень подготовки (смотри п.2) поможет снизить волнение, совсем избежать его, наверное, не получится почти ни у кого. Необычно понимать, что вот этот крутой человек с кучей опыта тоже волнуется :) Можно помочь спикерам, будучи благодарной и дружелюбной публикой. Стараюсь по возможности улыбаться докладчикам, не фыркать скептически, даже если не согласна, и по возможности благодарить за доклад после выступления. В конце концов, всегда приятно, когда твои старания ценят хотя бы чуть-чуть :)
Вместо вывода вкину соображение: как мне кажется, чтобы увереннее выступать, нужно больше выступать. Преодолевать стеснение, придумывать или подбирать интересные темы, взаимодействовать с публикой. И любить своё дело, а как же иначе :) Потому что нет лучшей приправы к хорошему докладу, чем искренний интерес и огонь в глазах спикера!