Cold Turkey

Возвращаясь к теме о принципах тестирования. Внутренний клиент наткнулся на баг. По описанию инцидента нифига не понятно. Проблема в форме регистрации с 2FA с помощью СМС. Но непонятно, какая это форма из 5 наших форм. Пришлось перебирать все. Баг воспроизвёл. Пока искал - нашел ещё 2 в двух других формах. Принцип тестирования: Defect Clustering Если есть где-то уже один баг, рядышком сто пудов ещё валяются, надо только поискать повнимательнее. 👀🐞

Друзья 🤗 Я долго собирался с мыслями (больше трёх месяцев). И вот, наконец-то собрал мысли в кулак и изложил их в статье. Мысли на тему принципов тестирования. Если вы только-только начали свой путь в тестировании, то с вероятностью 75% не слышали о принципах тестирования. Я не стремился написать ещё одну статью про то, что это за принципы и что они означают. (ответы на эти вопросы вы легко найдёте в поисковике) Я решил взглянуть чуть более прозаично на них. Как именно? Ну, добро пожаловать в статью: https://vc.ru/life/124461-principy-testirovaniya-primenenie-iskazheniya-i-illyuzii П.С. Как всегда - если статья не открывается, потерпите некоторое время, это просто странная модерация VC.RU П.П.С. Чуть попозже, как всегда будет опрос на тему статьи.

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

Привет, коллеги и будущие коллеги. Сегодня будет крайне интересная тема по мотивам вот этой статьи. Тема статьи звучит примерно так: Сертификация (в т.ч. QA направления) - это зло или добро? Автор поднимает вопросы к сертификации (совершенно справедливые), поэтому каждому настоятельно рекомендую со статьей ознакомиться. Я же хочу акцентировать внимание на одном из пунктов этой статьи. Сертификация != Квалификация В QA есть самая популярная, и практически единственно известная международная сертификация: ISTQB И это безумно полезная вещь тестировщику с опытом 3-5 лет, чтобы утрясти терминологию, взглянуть на мир QA другими глазами и возможно подтянуть те места, которые были пропущены за время рабочей практики. Тем не менее, я часто вижу стремление новичков изучить и пройти сертификацию ISTQB. И вот тут, друзья, я бы хотел посоветовать вам (то есть им) воздержаться от этого. Дело в том, что многие начинающие тестировщики путают сертификацию ISTQB с обучающими курсами. Но дело в том, что обучающие материалы по сертификации направленны именно на сдачу экзамена (как TOEFL направлен на сдачу экзамена по английскому, но не научит вас языку). Изучение терминологии ISTQB в каком-то смысле полезно, но оно ни в коем случае не поможет вам освоиться в профессии. Да и в теории не подтянет вас в достаточной мере. Лучше запишитесь на какие-нибудь обучающие курсы, практикумы по тестированию, коих сейчас предостаточно на просторах интернета (тут могла бы быть отличная реклама... эхъ) Всё. Я правда старался изложить мысли кратко. Внизу будет опрос как обычно)

Привет, ребят. Рубрика "лайфхаки" 🎉 Тут недавно прошли две больших IT конференции - techLeadConf и Heisenbug 2020 (можете заютубить видео с предыдущих конференций) Докладов там тьма тьмущая, каждый по 1.5 часа примерно. А все посмотреть хочется. И знаете что? У меня есть лайфхак. Да, это для некоторых будет Капитан Очевидность. Но на деле оказалось, что из моих знакомых никто этим лайфхаком не пользуется. А сам я им стал пользоваться относительно недавно (года 2 назад). В общем суть до безобразного проста: смотрите видео в записи на скорости х1.5 (а иногда и х2, если докладчик нудный). Если смотрите на ютубе - справа внизу есть шестеренка, её нажимаете и выбираете скорость воспроизведения. (Вообще почти во всех плеерах эта настройка именно там). Лайфхак внутри лайфхака - мозгу нужно время, чтобы адаптироваться к скорости восприятия информации, поэтому, сначала установите скорость на 1.25 и посидите так секунд 30-40, потом ставьте на 1.5. Так намного комфортнее. В общем эта тема меня спасает уже везде, начиная от каких-то вебинаров в записи, заканчивая просто видео по работе. Когда ты понимаешь, что вместо двух докладов за 3 часа ты можешь прослушать, например, 4 доклада за эти же 3 часа - это просто бомба! (или как щас говорят? Просто пушка! 🤪) В общем. Всем отличных образовательных выходных. Надеюсь мой лайфхак вам пригодится.

Привет, коллеги! 🙌🏻 Давно мы не обращались к теме первых шагов при поиске работы и собеседований в частности. Мне в одном из профильных каналов попалась вот эта статья (http://klever.blog/types-of-interviews-in-it-companies/). Статья мне кажется интересной и довольно тематичной. И как это со мной обычно бывает, я прочел её, и у меня появилось непреодолимое желание чиркнуть в канал рецензию на неё. Кто не читал - обязательно почитайте. Особенно, если вы только начинаете поиски будущего работодателя. В статье передана сама суть. Красной нитью проходит тема "не надо врать на собеседовании❗️" и "не только вас выбирают, но и вы выбираете❗️" (и нет, это не капитан очевидность!!). С другой стороны. Статья очень про-эпамоская. Вы должны понимать, что такое EPAM и как эта компания устроена. (В двух словах - это огромный аутсорс-айти-интегратор). Больше половины форматов, которые были описаны - они скорее исключение, чем правило. Обычно собеседования проходят с тремя представителями: HR, с непосредственным руководителем (или старшим коллегой) и менеджером повыше. И в 90% случаев беседа с HR это одновременно и оценка ценностей и скрининг кандидата и простенькие технические вопросы чисто на отсев. Всё как в статье. Беседа с непосредственным руководителем или будущим старшим коллегой - это техническое интервью. Но на нём вполне могут задавать те же вопросы по второму кругу, что на беседе с HR. Общение с менеджером - это "смотрины". Там могут быть всё те же вопросы или вопросы более общего плана. Главное - посмотреть кандидату в глаза, так сказать. Советы и ошибки, которые описаны в этой статье (особенно ошибки на техническом интервью!) - они применимы и актуальны вне зависимости от того, сколько этапов собеседования вы проходите и как они называются. Именно поэтому эта статья полезна. Да, в статье первым же абзацем идёт дисклеймер, что, мол у всех компаний всё своё, а тут просто предупреждают о всех возможных ситуациях. Так что я Америку не открываю. Просто ещё раз акцентирую на этом внимание. Умение проходить собеседование нельзя заключить ни в какую статью. Просто ходите по ним. Чем больше - тем лучше. И спустя некоторое время вы сами сможете учить других что отвечать, как держаться и к чему готовиться. Удачи!

Всем привет! Друзья, хочу поделиться с вами замечательной новостью. Наше уютное сообщество начинающих тестировщиков становится всё больше (того и гляди за 300 участников перевалим в скором времени) и я решил навести немного лоска на него. Хочу представить вам новое лого нашего уютного канала) Но этим я не стал ограничиваться и заказал нам несколько веселых, но очень жизненных для тестировщика стикеров. Прошу любить и жаловать. Забирайте себе, уверен, вам пригодится в общении с коллегами. Набор стикеров будет пополняться потихонечку и там будут всё новые и более животрепещущие для QA стикеры.

Тема 'QA VS тестировщик' - обсуждена и пережевана 1000 раз. Я предлагаю вам почитать 1001 статью, если раньше вы с этим холиваром не сталкивались. Но если сталкивались - возможно вам будет интересно, так же как и мне. https://m.habr.com/ru/company/dodopizzadev/blog/497014/ Чем грешат холивары QA VS QC? Тем, что каждый первый знает, что QA и тестирование - это не одно и то же. Это здорово, но к сожалению вот на этом общедоступные знания и заканчиваются. Дальше некоторые уже знают, что это не просто "не одно и то же", но одно является подмножеством другого. Но даже так. Много кто может ответить на вопрос "что же делает тестировщик?", но мало кто может ответить на вопрос "А что же делает QA специалист?". Думаю поэтому мне понравилась эта статья. Автор пытается в конце дать хоть и краткий, но всё же ответ на этот вопрос 🤓 Но я вообще хотел также высказать и своё мнение на эту тему. Я считаю, что всё это - война терминов на уровне лингвистики: свеклА или свЁкла (на деле - один овощ). Да, по правилам/стандартам может быть какое угодно разделение на QA и QC, но на самом деле рынок диктует название профессий и их должностные обязанности. И если я, допустим, крайне умный и искушенный тестировщик, не приемлю смешивание терминов и точно знаю, что я - крутой QC специалист - я лоб расшибу, а ни одной вакансии QC не найду. С другой стороны, если я познал дзен, я именно QA - настраивал процессы, был в каждой точке жизненного цикла ПО, специалист во многих сферах, то поиск по QA вакансии мне не выдаст ни одного настоящего QA инженера - только пресловутого тестировщика. Чтобы в России (и СНГ) появилось разделение понятий QA и QC для этого надо, чтобы на рынке были на самом деле представлены эти два профиля специалистов. А на деле, на рынке только тестировщики = QC, другого нет. Поэтому все всех называют QA инженерами. Я уже 10 лет в IT и более 7 в тестировании. И я каждый раз стараюсь расширить рамки своих полномочий и обязанностей с простого тестинга до хоть какого-то примитивного QA процесса. Но наш рынок, наши компании пока не готовы к этому. (Ключевое слово - "пока"). Это моё личное мнение и я уверен, найдутся те, кто считает, что я не прав (для них ниже будет интерактивчик). Но повторюсь, моё мнение в том, что рынок СНГ не готов встретить настоящего истинного QA с раскрытыми объятиями. Пока только так.

Привет, друзья! Сегодня будет пост не про тестирование. Так получилось, что сегодня у автора канала (то есть у меня, да) день рождения 🤪 И лучшим подарком может быть исполнение моей скромной просьбы: найти заинтересованного в тестировании друга или коллегу-джуна и поделиться с ним ссылкой на канал (просить подписываться не обязательно. Достаточно поделиться по-дружески). Потому что новые подписчики для меня - это отличный подарок и мотиватор делиться с вами своим опытом, мнением или просто полезной информацией. Всем объятий!

Привет, друзья! Тут у меня новая статья для новичков вышла. По стопам о наболевшем, так сказать. Проблема: начинающие тестировщики стремятся сделать как можно больше тестов как можно более атомарно На самом деле: атомарность это про условия, а не про "проверки" возможных результатов Подробности в статье: https://vc.ru/dev/115923-atomarnost-v-testirovanii-dlya-novichkov Затронул немножко вопрос тест-дизайна в целом, а так же немного частных практик атомарности для автоматизации. П.С. Напомню, что модераторы VC крайне забавные ребята, так что не исключено что даже спустя день они могут закрыть статью, потому что я опубликовал её "не в ту категорию". Если не работает - ничего страшного, я слежу на статусом статьи и исправлю ситуацию в короткие сроки.

"QA - это гораздо больше, чем просто покрыть тестами API и научиться готовить селениум. Тестирование является довольно легкой точкой для входа в айти. Помимо миллиона курсов, обещающих сверхзарплаты через 2 недели, а также большого количества соискателей, прочитавших одного только Савина, это рождает ещё и устойчивое мнение что QA - это просто. Действительно, сформировать какой-то необходимый минимум для тестирования проекта - довольно объемная, но не такая уж и сложная, задача. Только QA - это немножечко больше, чем тесты на API, девять с половиной ручек селениума и тестраннер прикрученный к CI. Качество стоит дорого, а его обеспечение требует мозгов, скиллов и способности решать задачи, а не просто пилить покрытие тестами ради покрытия тестами. Сделать тесты эффективными, быстрыми, масштабируемыми и прозрачными для всех, чью работу они затрагивают - сложно. Сформировать такой набор тестов и тестовых данных, чтобы тестирование действительно говорило об уровне качества системы, а не просто показывало красивый список зеленых тестов, пока пользователи и бизнес продолжают страдать - сложнее, чем научиться применять граничные значения и классы эквивалентности. Добиться того, чтобы на каждое падение не приходилось проводить длительный root cause analysis - тонна работы, как со стороны самих тестов, так и со стороны тестируемой системы. Если QA-инженер не обладает достаточной экспертизой, чтобы решить как это должно быть сделано, то все эти задачи так и останутся нерешенными. Всё перечисленное выше - то, что на поверхности. Помимо этого есть куча направлений работы и множество задач, ограниченных только вашими скиллами, желанием и способностью объяснить окружающим, и себе, зачем это нужно. Ещё один момент, который необходимо понимать: Задачи, которые приходится решать QA инженерам сильно отличаются в разных компаниях и командах, несмотря на то, что общие подходы и практики почти не меняются. Меняются приоритеты, требования к качеству, цена ошибки и, конечно же, меняются инструменты. Есть проекты, где можно взять более-менее стандартный стэк инструментов - царство победившего селениума всех сортов, плюс пара аналогов - и их будет достаточно. Но даже эти инструменты нужно использовать правильно. Если же специфика проекта не позволяет использовать типовые решения - начинается ад, содомия и полноценные инженерные челленджи." ☺️ Друзья! 😊 Это пост не моего авторства. Я его позаимствовал у @shooandendlessagony Он тоже пишет про тестирование, про то, каково в нём новичкам и размещает много полезных и интересных мыслей на эту тему. Посмотрите, там есть и другие интересные посты. От себя к этой статье добавлю лишь еще один пункт, о котором многие не говорят. В 80% компаний, если фича решила боль пользователя, если принесла миллионы "денег", если выкатили быстро и без проблем - молодцы разработчики. Если на прод просочился нетривиальный баг, если релиза нет уже 2 недели т.к. постоянно повторяется цикл регресс-тестирования и накладывается вето на релиз - виноваты QA. Будьте готовы к этому; это неприятная сторона профессии. Но не забывайте, что мы делаем мир ПО лучше, а пользователей счастливее.