На главную

Логические ошибки для тестировщиков, часть 12: скользкий склон

barancev@gmail.com (Administrator) — Wed, 15 May 2024 20:00:00 +0000

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Этой ошибке часто подвержены родители, запрещающие подросткам что-то делать. Представьте себе отца и дочь. «Если я разрешу тебе пойти на рок-концерт и стоять на ушах до двух ночи посреди школьной недели, то вскоре ты будешь болтаться по ночам каждый день, будешь опаздывать на уроки, пострадают твои оценки, и ты не поступишь в хороший колледж».

Работа с UI-автотестами под Android: от запрета мерджа к особенностям запуска

barancev@gmail.com (Administrator) — Tue, 14 May 2024 20:00:00 +0000

Автор: Эмилия Куцарева

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

Меня зовут Эмилия Куцарева. Я — руководитель команды автоматизации тестирования в Одноклассниках (VK). В этой статье я расскажу о нашем подходе к работе с Android UI-автотестами: как устроен запрет мерджа, как смогли стабилизировать тесты, как настроили параметризацию запуска.

Я знаю не все, и это нормально

barancev@gmail.com (Administrator) — Mon, 13 May 2024 20:00:00 +0000

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

Знаменитая фраза Аристотеля звучит, как «Чем больше вы знаете, тем больше понимаете, что ничего не знаете». Я давно знаю, что так оно и есть, но не применял это знание на практике.

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

Как написать требования к IT-продукту и их протестировать, чтобы результат соответствовал ожиданиям

barancev@gmail.com (Administrator) — Sun, 12 May 2024 20:00:00 +0000

Автор: Зубов Вадим QA специалист IT компании Intelsy

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

Истинные требования

barancev@gmail.com (Administrator) — Wed, 24 Apr 2024 20:00:00 +0000

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

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

Джерри Вайнберг очень любил подчеркивать, что «плавающая точка» - это математика, где точка остается на месте, а «фиксированная точка» - ситуация, когда точка двигается. Люди говорят о «внесерверной обработке данных», на самом деле подразумевая «обработку данных на чьих-то еще серверах». «Бескодовые инструменты тестирования»… ну, код есть всегда; просто это код, который писали не вы.

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

Do it yourself: как тестировать приложение без QA

barancev@gmail.com (Administrator) — Tue, 23 Apr 2024 20:00:00 +0000

Автор: Женя Шаповалов, Senior Android/Flutter Developer в компании Innowise (и хэд mobile department там же). В мобильной разработке я с 2015 года, начинал с Android, а за Flutter мы принялись вместе с коллегами в Innowise - да так мощно, что в итоге в компании появилось отдельное направление разработки.

Сегодня рассказываю, как правильно тестировать код, и делимся личным опытом. Да-да, ты все понял верно: при разработке мобильных приложений тестирование проводит не только QA-инженер, но и сам автор кода. Причем не только в самом конце, когда приложение почти готово, но и в процессе. Мы сегодня рассмотрим оба этапа.

Логические ошибки для тестировщиков, часть 11: апелляция к невежеству

barancev@gmail.com (Administrator) — Mon, 22 Apr 2024 20:00:00 +0000

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Ошибка апелляции к невежеству – интересная штука: она утверждает, что нечто истинно, потому что не доказано, что оно ложно.

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

В тестировании эта ошибка тоже очень распространена. Возьмем, например, такое утверждение: «Мы знаем, что наше ПО безопасно, потому что у нас никогда не было проблем с безопасностью». Отсутствие этих проблем НЕ означает, что в ПО нет уязвимостей. Возможно, там их десятки, но компания недостаточно велика и не представляет для злоумышленников никакого интереса. Некоторые компании могут также заявить, что никогда не находили в своем ПО никаких уязвимостей. Возможно, это действительно так, но, возможно, они и не пробовали их искать. Это плохая логика и очень плохая практика – заявлять, что чего-то не существует, только потому, что вы и не пробовали это найти.

Как эффективно использовать Chrome DevTools для QA: подборка интересных возможностей

barancev@gmail.com (Administrator) — Sun, 21 Apr 2024 20:00:00 +0000

Автор: Андрей Степанов, технический директор fuse8
Оригинальная публикация

Chrome DevTools — это консоль разработчика, набор инструментов в браузере для создания и отладки сайтов и приложений. С их помощью можно в том числе тестировать уже разработанную функциональность.

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

Отмечу, что говорить мы будем именно о Chrome DevTools, хотя и в других браузерах есть аналогичные консоли разработчиков. Сам их частенько использую — это удобно. Поскольку инструменты неочевидные, рекомендую заглянуть под кат и начинающим, и опытным тестировщикам — точно почерпнёте для себя что-то новое.

Шокирующая новость: вы разработчики

barancev@gmail.com (Administrator) — Tue, 16 Apr 2024 20:00:00 +0000

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

Я уже говорил об этом, многие высказались еще до меня, и я надеюсь, что множество людей будет вновь и вновь говорить об этом в будущем:

«Тест-автоматизация – это разработка ПО».

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

Я хочу поговорить о том, что мало кто действительно глубоко разбирается в последствиях того, что тест-автоматизация – «это разработка ПО». Я немного затрагивал эту тему ранее – в основном рассуждая о том, почему было бы неплохо изучить базовые принципы программирования.

Сегодня я хочу развить ёмкую фразу «тест-автоматизация – это разработка ПО» далее; если конкретно, поговорить об одном следствии из нее. Если тест-автоматизация – это разработка ПО, то вы, работая над созданием автоматизированных тестов, становитесь разработчиком.

Да-да, вы всё верно прочитали. Вы. Разработчик. ПО.

Спринт с багами, или как (не) создать себе проблем

barancev@gmail.com (Administrator) — Mon, 15 Apr 2024 20:00:00 +0000

Автор: Султанов Илья, тимлид разработки, @sultanovis

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

Они чувствительны и сентиментальны. Даже исправлять жалко.

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

Итак, к делу.

Новая крупная тенденция тестирования - дебаг

barancev@gmail.com (Administrator) — Sun, 14 Apr 2024 20:00:00 +0000

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Test Replay приходит в Cypress

Возможно, вы слышали новости о Cypress. Версия 13, их крупнейший релиз, демонстрирует функцию Test Replay, позволяющую пройтись по прогону своих тестов. В ходе прогона все снимки DOM, сетевые вызовы и логи консоли будут записаны, позволяя глубоко анализировать прогон.

Cypress – решение с открытым исходным кодом, но за ним стоит компания. Премиум-сервис, который эта компания предлагает – это сервис Cypress Cloud, облегчающий параллелизацию тестов, тест-аналитика, а теперь еще и Test Replay.

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

barancev@gmail.com (Administrator) — Wed, 10 Apr 2024 20:00:00 +0000

Автор: Герасимов Сергей Сергеевич, Петрович-Тех, блог компании

Меня зовут Сергей, я тестировщик в “Петрович-Тех”. В этой статье хочу поговорить о комбинировании различных техник тестирования и поделиться опытом тест-дизайна для проверки системы оплаты.

На всем своем профессиональном пути тестировщика я так или иначе всегда работал с оплатами (люблю деньги, что поделать). Вместе с командой Петрович-Тех успел поучаствовать во внедрении оплаты частями, добавлении СБП, полном редизайне корзины в интернет-магазине, сейчас тестирую оформление заказа.

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

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

Приступим!

Про (более) значимую автоматизацию

barancev@gmail.com (Administrator) — Tue, 09 Apr 2024 20:00:00 +0000

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

Чтобы грамотно обсудить, что значит «значимая», нам нужно рабочее определение. Не претендую на то, что мое определение «значимой автоматизации» исчерпывающе, но базировать свои мысли буду на нем. С этого и начнем:

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

Повторюсь, это, вероятно, не идеальное определение (но много ли вы видели идеальных?), но для начала сойдет. Разберемся с ним и детальнее взглянем на значимость автоматизации.

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

Ферма тестирования SberDevices

barancev@gmail.com (Administrator) — Mon, 08 Apr 2024 20:00:00 +0000

Оригинальная публикация

В интернете уже довольно много материалов о том, как другие команды строили свои решения для тестирования мобильных приложений (и не только), например: Яндекс Колхоз, Ферма мобильных устройств Selectel, Ферма девайсов VK, Ферма мобильных устройств в Сбере, Мобильная ферма 101 (доклад Антона Малинского).

Я же хочу рассказать про Ферму, которую мы строим в SberDevices.

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

Место Playwright в мире записи и воспроизведения

barancev@gmail.com (Administrator) — Sun, 07 Apr 2024 20:00:00 +0000

Автор: Иоан Солдереа (Ioan Solderea)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

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

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

Как улучшить автоматизацию, исследовательское тестирование и API-тесты: самые интересные новости тестирования за март-2024

barancev@gmail.com (Administrator) — Thu, 04 Apr 2024 09:45:23 +0000

Опубликован выпуск рассылки за март.

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

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

JIRA + AI = LOVE или Как Product manager-у найти друзей и перестать страдать

barancev@gmail.com (Administrator) — Tue, 02 Apr 2024 20:00:00 +0000

Автор: Алексей Бобок (компания Рафт)

Развитие AI-инструментов на базе современных LLM запустило тренд на автоматизацию всего, что прибито меньше, чем на 2 гвоздя, и первыми адоптерами здесь традиционно выступает IT сообщество. Как Луи Пастер некогда ставил себе и друзьям намешанные на голой коленке вакцины, так сейчас разработчики активно ставят себе Code Copilot-ы, дизайнеры экспериментируют с Midjourney, скромно к этой очереди пристраиваемся и мы, Product Manager-ы.

Меня зовут Алексей, и я более 15 лет занимаюсь управлением b2b-b2c продуктами и руководством командами в энтерпрайзе и стартапах.

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

Приступаем к автоматизации тестов API: какой инструмент создания тестов проще изучить?

barancev@gmail.com (Administrator) — Mon, 01 Apr 2024 20:00:00 +0000

Автор: Эйоб Гайус (Ejob Gaius)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Что можно и стоит писать в поле Pre-conditions в тест-кейсах

barancev@gmail.com (Administrator) — Wed, 27 Mar 2024 20:00:00 +0000

Автор: Евгений Гусинец, Middle QA Engineer, автор телеграмм канала QA❤️Life

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

Каждый тест-кейс разрабатывается с целью проверить определенный аспект продукта, будь то функция, интерфейс или производительность. Ключевым элементом каждого тест-кейса являются предварительные условия, или Pre-conditions, которые определяют состояние системы перед началом тестирования.

Систематическое исследовательское тестирование с YATTIE

barancev@gmail.com (Administrator) — Tue, 26 Mar 2024 20:00:00 +0000

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Не читал? Я осуждаю! 5 имен, которые должен знать каждый тестировщик

barancev@gmail.com (Administrator) — Mon, 25 Mar 2024 20:00:00 +0000

Оригинальная публикация

«Дедушка российского тестирования», тестировщик с 50-летним стажем Александр Александров объясняет, почему классическая научная литература по тестированию по-прежнему актуальна и с каких основополагающих текстов стоит начинать свой путь в этой профессии.

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

Улучшаем тест-автоматизацию при помощи значимой документации кода

barancev@gmail.com (Administrator) — Sun, 24 Mar 2024 20:00:00 +0000

Автор: Яник Диксон (Yanique Dickson)
Оригинал статьи
Перевод: Ольга Алифанова

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

Паттерны автоматизации и архитектура автотестов

barancev@gmail.com (Administrator) — Wed, 20 Mar 2024 20:00:00 +0000

Автор: Элизарян Виктория, должность: SDET/Senior QA Automation, https://www.linkedin.com/in/victoriya-elizaryan-a860a4149/

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

Улучшаем тест-покрытие при помощи тестирования через модели и TestCompass

barancev@gmail.com (Administrator) — Tue, 19 Mar 2024 20:00:00 +0000

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

Сколько мы уже покрыли, сколько еще находится в очереди?

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

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

Зачем тестировщику CJM

barancev@gmail.com (Administrator) — Sun, 17 Mar 2024 20:00:00 +0000

Всем привет! Меня зовут Александр Наумов, я работаю в SM Lab на позиции куратора тестирования. Сегодня я хотел бы поговорить о такой интересной вещи как CJM на продукте и о том, чем она может быть полезна тестировщику.

Начнем с определения — что такое CJM.

CJM (от англ. customer journey map) воспроизводит путь, который проходит клиент от осознания потребности в продукте до его покупки, а иногда и после неё. Всё это время он взаимодействует с продуктом и компанией и принимает решение на основе полученного опыта. Другими словами, это визуализация путешествия клиента по продукту