На главную

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

2024-04-24T20:00:00Z

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

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

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

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

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

2024-04-23T20:00:00Z

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

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

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

2024-04-22T20:00:00Z

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

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

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

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

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

2024-04-21T20:00:00Z

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

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

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

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

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

2024-04-16T20:00:00Z

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

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

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

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

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

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

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

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

2024-04-15T20:00:00Z

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

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

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

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

Итак, к делу.

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

2024-04-14T20:00:00Z

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

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

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

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

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

2024-04-10T20:00:00Z

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

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

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

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

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

Приступим!

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

2024-04-09T20:00:00Z

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

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

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

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

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

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

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

2024-04-08T20:00:00Z

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

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

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

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

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

2024-04-07T20:00:00Z

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

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

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

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

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

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

2024-04-04T09:45:23Z

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

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

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

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

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

2024-04-02T20:00:00Z

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

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

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

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

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

2024-04-01T20:00:00Z

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

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

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

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

2024-03-27T20:00:00Z

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

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

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

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

2024-03-26T20:00:00Z

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

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

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

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

2024-03-25T20:00:00Z

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

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

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

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

2024-03-24T20:00:00Z

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

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

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

2024-03-20T20:00:00Z

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

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

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

2024-03-19T20:00:00Z

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

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

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

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

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

2024-03-17T20:00:00Z

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

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

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

Преодолеваем синдром самозванца в тестировании

2024-03-13T20:00:00Z

Автор: Наталья Ханчич (Nataliya Hanchych)
Оригинал статьи
Перевод: Ольга Алифанова

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

Из тестирования в техподдержку и обратно

2024-03-12T20:00:00Z

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

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

Пока искала работу знакомая QA Lead порекомендовала попробовать себя в сопровождении, сказала, что это будет полезно для развитии в тестировании. Стоит признаться, что изначально приняла это предложение скептически, но за неимением вариантов получше решила попробовать. Ниже, чтобы вы поняли, чем я занималась и поняли, насколько это будет вам полезно, распишу чем занималась и что мне это дало, а также какие препятствия мне встретились на этом пути.

Cypress.io и GitHub Actions: пошаговое руководство

2024-03-11T20:00:00Z

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

Возможно, вы уже интересовались GitHub Actions. Они кажутся продвинутой концепцией, но на самом деле это мощный и простой в освоении инструмент, который может вам пригодиться. Разберемся, как пользоваться им при прогоне тестов Cypress.

Приключение на 20 минут: как войти (и не выйти) в готовую автоматизацию на проекте

2024-03-10T20:00:00Z

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

Введение

Всем привет, меня зовут Никита, и я QA-инженер в компании Bimeister.

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

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

Для начала расскажу, как у нас устроен процесс автоматизации и наш фреймворк.

В автоматизации тестирования у нас участвуют SDET-ы и непосредственно QA-инженеры. У нас нет отдельных автоматизаторов, все QA — full stack. SDET-ы занимаются непосредственно фреймворком (развитием, поддержкой, интеграцией) и архитектурной частью автоматизации. QA-инженеры — самим покрытием продукта автоматизированными тестовыми сценариями (тут необходимо уточнить, что QA-инженеры автоматизируют UI-тесты, а Unit- и Integration-тесты пишут разработчики).

Паттерны и инструменты используются классические: PageObject, Fluent of invocations, C# + Selenium, MSTest.