Всем привет, очень рада видеть вас здесь 👩🏽‍💻

«Если бы все люди были такого же интеллектуального уровня, как я, то человечество бы застряло в каменном веке»

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

Самое дурацкое, что в такой момент сразу хочется резко поумнеть. Рациональные мысли вроде «всё придёт со временем» больше не кажутся такими правильными, начинается паника: «Я должна как можно скорее улучшить свои навыки». Отсюда два пути: в лучшем случае я резко начинала поглощать знания (пройти туториал по программированию за вечер, записаться на онлайн курсы по линейной алгебре), в худшем просто думать о том, что я уже упустила шанс быть «нормальной», и вряд ли у меня внезапно получится все изменить и стать продвинутым инженером или офигенным сисадмином, и начинала сидеть и уНыВаТь о своей тупости.

Но фишка в том, что потом мало-помалу приходит осознание важной истины: мир не вертится вокруг одной меня. Самолеты строит не один человек. Мосты и города — тоже. Это, кажется, касается любой профессии: врачи не работают по одному ни на скорой, ни в операционной; лингвисты переводят книги со штатом редакторов, корректоров и помощников.
Один разработчик — это труд не только самого разработчика, но и менторов, и тех, кто писал книги и создавал библиотеки и фреймворки, и тех, кто отвечал ему на StackOverFlow, и ещё многих, многих людей. Даже на то, чтобы сделать простой (но качественный) веб-сайт, работают команды от 2-3 до 10-12 человек!

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

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

Про скорость работы

В последнее время как-то слишком часто обсуждали этот момент с друзьями/коллегами, и вот захотелось про него тоже написать.

Нормально ли работать не очень быстро? Ок ли тратить на задачу 3 часа, из которых 30 минут непосредственно тестируешь, а 2.5 часа - вникаешь в структуру, логику и всё такое?
Мне приходилось разбираться со сложными задачками, где без ̶б̶у̶т̶ы̶л̶к̶и̶ разработчика не поймешь буквально ничего, и иногда я успевала сделать за день совсем немного. Более того, мне было стыдно спрашивать что-то типа "как это тестировать?", потому что подобный вопрос казался распиской в собственной некомпетентности и слабости. Однако задачи надо было решать, дела - делать, и, выдохнув, я звонила коллеге и просила объяснить мне детали того или иного вопроса.

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

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

О, и ещё помогает поговорить с кем-то. На начальных этапах я обращалась к менеджерам (тем, кто, собственно, отвечает за распределение времени и сроки), и мне повезло работать с компетентными, спокойными людьми, которые говорили: "всё хорошо, разбирайся столько, сколько надо, главное, чтобы ты поняла и вникла в проект". Такое отношение вселяло уверенность, что всё номрально.
Потом, бывало, обсуждала аналогичные темы с другими QA (в том числе из других компаний, будь то проукт или аутсорс), и, кажется, все рано или поздно задумывались, не слишком ли медленно они работают. Это тоже забавно: знать, что вас, замороченных, много :) Короче, общаться - классно, 10/10.

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

Короче, между скоростью и качеством выбираю качество. И честность о том, сколько времени на это качество требуется.

Иногда баги поджидают даже в книгах. Забавно, что такие мелочи воспринимаются уже на автомате, а в голове первым делом мысль «Надо пойти зарепортить» 😄

Собор парижской автоматизации, или задачка про Квазимодо и Эсмеральду

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

QA - обепечение качества. Но что насчёт качества инструментов обеспечения качества?
Допустим, с вопросом писать или не писать автотесты я давно уже для себя всё решила: ускорить работу и избавиться от рутины вроде проверки наличия всех элементов/текстов на странице или возможности залогиниться/зарегистрироваться оказалось крайне приятно.

Другое дело, что встала новая проблема: оказывается, у тестов есть архитектура и шаблоны проектирования, и мои пошаговые сценарии - это лишь начальная ступень огромного неопознанного мира автоматизации (о чем я, конечно, знала, но от этого не стало менее больно осознавать, что твои нынешние тесты - фигня).

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

Ещё я (не так давно) научилась писать более красивые и универсальные тесты с некоторым подобием структуры (тут очень хочется сказать спасибо моему старшему коллеге Антону за терпеливые объяснения и готовность всегда помочь), но времени на них уходит значительно больше, потому что, откровенно говоря, с архитектурой кода любого рода я пока скорее на "Вы". Это будут тесты-Эсмеральда.

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

Стул №1: покрывать проект тестами-Квазимодо, но тратить на это немного времени, и таким образом автоматизировать - и сократить время на - регрессию.
Стул №2: пытаться в архитектуру, призывая тесты-Эсмеральду, но делать это медленно.

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

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

Стоит ли идти на сделку с совестью? Что лучше: покрыть проект такими вот проверками (результат будет хорошим, но я-то знаю, что под капотом всё плохо и уродливо) или уже продолжать тестировать всё руками, но делать это однозначно качественно?

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

Здравый смысл и разговор с парой замечательных людей помогли. Решила в итоге автоматизировать не ради автоматизации. План таков: тестировать руками все необходимое, параллельно писать автотесты с нормальной архитектурой (привет, Эсмеральда). Учиться писать тесты-Эсмеральду быстрее. Становиться хорошим специалистом, учиться не жертвовать ни качеством, ни темпом. Звучит как утопия. А может быть, как цель?

Вот немного к вопросу о холистике QA: мне кажется, не я нахожу баги, а баги меня :D

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

Сиди и думай после этого: это я тестирую всё вокруг или просто всё вокруг позволяет мне тестировать себя и подкидывает такие забавности? 🤔

Всех коллег-QA с профессиональным праздником! :)

Субъективность понятия бага

В честь дня тестировщика немного философская тема о фундаментальном: что такое баг.

Примерно пару недель назад мы с другом арендовали машину в небезызвестной системе каршеринга, и установленное бесплатное 20-минутное бронирование подошло к концу до того, как мы дошли до автомобиля. По-еврейски не желая платить по 2,5 рубля в минуту, мы сбросили бронирование и тут же назначили новое, не зная, чего ожидать. Совершился лучший из возможных сценариев: счетчик снова вернулся на отметку “20”, и мы благополучно дотопали до машины, не переводя транспортное средство в платный режим.

И вот сегодня утром мы вспоминали тот случай, после чего я сказала: “Да, отличная фича”. “Но это не фича же”, - возразил друг. “Для владельцев системы, как для тех, кто получает с неё прибыль, это, конечно, баг. А для меня, как для пользователя - фича”, - я не могла согласиться.

Так где же вообще лежит эта граница между багом и фичей?

Если покопаться в определениях, мы найдем такие варианты:
Баг — запись (или «дефект») в системе отслеживания ошибок. (Википедия)
Баг — это отклонение фактического результата от ожидаемого результата (Р. Савин, Тестирование дот ком)
Дефект — расхождение ожидаемого и фактического результата (С. Куликов, Тестирование программного обеспечения)

Первая формулировка довольно малоинформативна, потому что рассматривает баг не как абстрактную неточность в работе программы, а просто привязывается к его оформлению в документах (грубо говоря, это как если бы чаем называли не сами сухие чайные листья, а пакетики, в которые их фасуют). Если следовать такому определению, то реши тестировщик занести в систему отслеживания ошибок запись с отрывком из пушкинского “Медного всадника”, формально это тоже будет багом.

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

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

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

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

<offtopic> Критическое мышление - ещё один момент, за который я обожаю своё заниятие.</offtopic>

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

Пространные рассуждения о профессиональной деформации QA

Ну раз уж у нас сегодня свой праздник ;)

Одна из моих любимых книг - знаменитое “Тестирование.com” Романа Савина. Я люблю её по многим причинам, несмотря на то, что многие моменты оттуда уже устарели (или просто не очень актуальны в аутсорсе). Например, это было первое, что я нашла, когда решила попробовать развивать себя в направлении QA, и я до сих пор помню ощущение трепета от новых, интересных знаний, поджидавших меня на страницах. Я честно выполняла все задания и следовала рекомендациям автора, одной из которых (едва ли не в первой же главе) стала следующая:

Находите в реальной жизни несоответствия ожиданий и реальности и мысленно отмечайте их: “баг”.

И вот примерно с весны 2017 - то есть с момента, когда я загорелась идеей стать QA - я стала искать “баги” в реальной жизни, но уже скоро они сами стали меня находить.

Шутки про мигающие лампочки - не шутки. Техника вокруг начинает вести себя непредсказуемо, внезапно вокруг появляются кучи неточностей, да и сам мир, кажется, иногда плывёт текстурами :D Я слышала шутки, что у тестировщиков есть “интуиция на дефекты”. Мне кажется, у этого явления вполне логичная природа.

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

Забавный пример: на днях шла пешком и услышала звук приближающейся из-за спины сирены. “Скорая”, - с уверенностью подумала я и не ошиблась. Потом в голову пришло, что в окружении того места, где я была, много больниц, а ещё, проходя мимо затора на дороге, я краем глаза заметила машину “скорой помощи”. Задумалась: было ли то, что я угадала машину, просто совпадением, или мозг в фоновом режиме соотнес факты выше и подсказал логично вытекающий ответ?

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

Интересно, то ли в QA идут те, кому не лень искать эти мелочи, то ли работа приучает их видеть. Но, на мой взгляд, такие загадки только добавляют шарма обеспечению качества 😏☺️

О саморазвитии

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

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

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

1. Обращать внимание на дату публикации.
Слишком новые материалы могут быть ещё не проверены опытом, слишком старые - заменены чем-то поудобнее.

2. Источник и автор очень важны, но это не панацея от неточностей.
Блог IT-компании или авторитетного человека вроде Джеймса Уиттакера (http://www.docjamesw.com/), Джеймса Баха (http://www.satisfice.com/) или Святослава Куликова (https://svyatoslav.biz/) скорее всего будут надежнее, чем блоги простых тестировщиков, которые только учатся анализу и интроспективе (вроде вот этого телеграм-канала, например :D). С другой стороны, в менее авторитетных блогах можно встретить необычные идеи и интересные взгляды, а ещё они хороши, когда хочется убедиться, что не только у тебя бывают факапы.

3. Мыслить критически.
Тестировать, постоянно тестировать входящий поток информации. Чем абстрактнее тема, тем более критически мыслить.

4. Выбирать максимум источников.
Для кого-то это может быть сомнительный совет, но мне помогает :) Я люблю прочитать по теме всё, что найду, и подвести собственный итог, где выберу самое, на мой взгляд, полезное отовсюду.

5. Приоритизировать и расставлять ресурсы в очередь.
Чтобы не сойти с ума от многообразия статей и книг, воспользовавшись предыдущим советом :D Самое интересное/важное в начало, потом менее релевантные ресурсы.

6. Не дочитывать до конца.
Да, прям так! Сейчас многие специалисты по здоровому питанию твердят, что не стоит заставлять детей есть обед до конца и предлагают позволять им не доедать суп, чтобы сформировать здоровое отношение к пище. Примерно то же я отметила для себя в применении к информации: чтобы не отбить у себя желание изучать насовсем, нужно позволять себе не поглощать книги и статьи целиком, а выбирать только самое “вкусное”. В какой-то момент я даже выписала себе небольшие напоминалки, чтобы знать, в какой книге/статье какую тему можно посмотреть, потому что часто бывает, что, несмотря на общую “хорошесть” источника, есть какая-то основная глава-пуля, которая несет супер полезную информацию и характерна именно для этой книги.

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

8. Сразу применить знания на практике.
По возможности. Так запомнится лучше, плюс будет реальный опыт того, где можно использовать новые навыки :)

На этой неделе загруз неимоверный, так что для мыслей в нерабочее в голове просто не остаётся места, а в рабочее всё занято проектами :)

Поэтому пока никаких размышлений или постов, просто с днём программиста всех 👩🏻‍💻👨🏻‍💻 Да будет классный код, поменьше багов и побольше здоровских задачек!

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

О первых шагах в тестировании

Или просто немного полезностей для тех, кому интересно на себе понять, чем же занимаются QA. Мне повезло войти в профессию после прохождения курсов/стажировок, но что, если такой возможности нет, а познать область хочется?

Допустим, человек решил стать тестировщиком. С чего можно начать?

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

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

Теоретических источников много, но вот мои любимые:
1. Видео-туториал на русском языке от СКБ Контур: https://ulearn.me/Course/Testing
2. Туториал на английском языке, совмещающий видео и краткий саммари-текст: https://www.guru99.com/software-testing.html
3. Из книг хороши следующие:
- Роман Савин - Тестирование.ком. Автор пишет живо и с юмором, но часть теории (впрочем, меньшая) устарела или просто мало где актуальна. Неплохой старт, но её нельзя считать настольной книгой современного QA.
- Святослав Куликов - Тестирование программного обеспечения. Очень хорошая книга, регулярно обновляется на официальном сайте, однако есть и "стабильная" неизменяемая версия. Сам блог автора тоже очень интересный, кстати, но об этом несколько позже. Может по праву считаться одной из лучших книг для быстрой консультации по теоретическим вопросам.
- Сэм Канер - Тестирование программного обеспечения. Неплохая, но немного неоднозначная книга. Как мне кажется, из неё хорошо брать технические сведения, а вот философскую часть лучше оставить на потом, чтобы изначально не запутаться в некоторых противоречиях с отечественной школой тестирования.
- И последний в начальном списке, но не по значимости - мой нежно любимый Джеймс Уиттакер - Exploratory Testing. Книга на русский не переведена, но очень уж она хороша, стоит времени прочтения (ради неё я была бы рада выучить английский до приличного уровня 🙂). Там рассказывается не только про уникальную методику исследовательских туров, но и про тестирование как процесс в целом, а ещё представляются некоторые инетерсные задачки "на подумать", без очевидно правильного ответа, - просто чтобы размять мозги и вспомнить, что знать всё на свере нереально :) Они восхитительна, и она, пожалуй, для меня любимейшая книга на профессиональную тему.

Итак, мотивация и цель есть, теория проштудирована, - что теперь?

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

Далее надо практиковаться. Можно попробовать участвовать в краудсорсинговом тестировании: есть платформы, где тестировщики могут зарегистрироваться и попробовать себя на благо какой-нибудь компании. Это будет не только отличный опыт перед первой работой, но и возможность просто посмотреть, как всё происходит "в деле", пообщаться с другими людьми и стать чуть ближе к желаемому.

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

В принципе, если с достатоным усердием подойти к самообучению, то, я уверена, стать хорошим начинающим специалистом вполне реально. Главное - любить то, чем занимаешься, и помнить об этом даже в трудные моменты ☀️

Как ручному тестировщику выжить в мире автоматизации?

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

Поэтому пока, чтобы совсем не теряться, поделюсь своим косеньким, но с душой сделанным переводом одной прекрасной статьи (ссылка на оригинал для ценителей английского есть в конце) в блог родной компании: https://blog.noveogroup.ru/2018/10/3-sposoba-vnesti-vklad-v-kachestvo/

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

Вообще не люблю разделение понятия тестирования на "ручное" и "автоматизированное", если речь о чем-то большем, чем об инструментах выполнения тестов (и то, как мне кажется, в таком случае лучше так и говорить: ручные/автоматизированные ТЕСТЫ, а не тестировщики).
Мыслями про то, какие классовые неравенства и, хуже всего, непонимания самой сути процесса обеспечения качества это влечёт за собой, я ещё обязательно поделюсь 👩🏻‍💻

Инструменты, которые могут помочь тестировщику в работе

Вчера посчастливилось выступить на митапе SPb SQA Group - оставлю запись тут.
Эту тему мы с моим ментором Антоном уже освещали внутри компании. Фидбек был позитивным, так что доклад пошёл дальше! :)

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

https://youtu.be/60Wfa5wmePY