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

В этой инструкции хочу рассказать о командах adb, которые использовать легче, чем делать то же самое через UI.

Основная задача — показать возможности adb, которые избавят от рутинных шагов при разработке/отладке. Например, позволят быстро переключать светлую тему на темную.

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

Привет, Хабр! Меня зовут Александр Карпенко, я QA Engineer в inDrive. Я подготовил эту статью для начинающих QA-специалистов. Ниже расскажу, как использовать Android Debug Bridge (ADB) в тестировании мобильных приложений и нужен ли вообще этот инструмент. 

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

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

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

Привет, Хабр! Меня зовут Анфиса Одинцова, я — наставница в Яндекс Практикуме на курсе «Инженер по тестированию». Сейчас работаю в JoomPay, а раньше — в Яндекс Дзен и ВК. В этой статье расскажу о важном аспекте тестирования — работе с логами. Ведь в мире разработки программного обеспечения логирование играет ключевую роль в обеспечении качества и отладке приложений. Для тестировщиков логи — ценный инструмент, который помогает нам понять работу приложения, обнаружить потенциальные проблемы и сделать наше тестирование более эффективным.

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

Привет! Меня зовут Татьяна Дерягина, я QA-инженер из команды мобильного тестирования в СберМаркете. Моя команда работает дистанционно, находясь в разных городах России. Хочу рассказать, как как мы адаптировались к процессу тестирования, без большого количества реальных девайсов и не потеряли качество продукта.

Часто случается так что на необходимом сайте установлена защита от ботов. Например: QRATOR, Cloudflare, Akamai Bot Manager и пр. Можно потратить множество ресурсов на обход этих систем, но если у вашего ресурса есть мобильное приложение, то можно пойти другим путём. В подавляющем большинстве случаев мобильное приложение остается без защиты т.к. методы актуальные в браузерной разработке в мобильной не актуальны. В этой статье мы совершим атаку MITM на приложение [скрыто], узнаем эндпоинты по которым приложение получает данные и получим данные сами.

Автор: Надежда Дудник

Памятка для начинающих инженеров по тестированию ПО.

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

Все глаголы я как раз использовала на своих англоязычных проектах и указанные примеры я взяла из своих написанных тестовых сценариев и оформленных баг-репортов.

Данная информация собрана из нескольких постов в рамках моего блога, и я решила добавить всю эту информацию в пространстве habr.com.

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

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

Всем привет! В этот раз собрали подборку вспомогательных материалов для изучения Git. Удобство и гибкость сделали Git стандартом для большинства современных IT-компаний. Поэтому умение работать с ним критично для любого программиста.

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

Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование -  я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков). 

В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией, решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.

Что такое попарное тестирование и почему оно является эффективной техникой тест-дизайна? Поговорим об этом ниже. Статья предназначена для начинающих специалистов по тестированию.

Это история про Алису. Алиса не только умный, скромный и добрый персонаж, но и отличный тестировщик. Последнее описать нелегко. Понять, что такое качественное тестирование можно, увидев его. Вот что увидел я.

Мировоззрение

• Нет сложных проблем. Просто отсутствует информация о том, как работает система
• Помните, что ошибка возникает по логической причине
• Будьте необоснованно уверены в своей способности исправить ошибку
• Чем сложнее будет баг, который вы исправите, тем лучше вы будете
• Каждая ошибка — это возможность узнать что-то новое

Поиск первопричины

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

Привет! Меня зовут Лёша и я тестирую веб в 2ГИС. Расскажу, зачем мы выделили багам бюджет и наделили их весом, и как мы придумали систему исправления ошибок, из-за которой больше не приходится спорить.

Привет, хабр. Меня зовут Кияшева Екатерина и я руковожу тестированием. Сегодня хочу поделиться своим чит‑листом обо всем.

Чит‑лист — набор стандартных проверок для многократного использования в различных приложениях, одинаковых по какой‑либо характеристике.

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

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

Неважно кто я, как меня зовут, где работаю и сколько опыта. Цель статьи больше похожа на крик души, а не на желание похвастаться и показать очередное "а вот у нас так работает", вывалив список, который до завтра не прочитать, назвав его кратеньким и пририсовав майнд-карту, больше самого списка. Будет здорово, если описанное ниже кому-то да поможет. Делалось все для веб-приложения. Насколько оно универсально - решать каждому, но подойдет и на десктоп, и на мобилки. Просто нужно подогнать под себя, поняв суть описанного.

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