Фрод (от английского — fraud, «обман») в сфере приложений — вид мошенничества, когда ботов и купленных пользователей выдают за реальную аудиторию. Фродом могут заниматься недобросовестные маркетинговые агентства, веб-мастеры, рекламные площадки и агрегаторы, чтобы создать видимость эффективного продвижения и получить деньги от заказчика.
Всем привет, дорогие друзья!
Приходилось ли Вам когда-нибудь тестировать формы авторизации?
Думаю, что каждый тестировщик сталкивался с ситуацией, когда после тестирования одной из таких «форм» с логином и паролем приходилось заводить баг-репорт c использованием слова «Авторизация».
Но ведь задача тестировщика постараться максимально точно и грамотно обозначить проблему!
Возможно ли это? Конечно!
Именно поэтому в данной статье мы разберем такой процесс как «Авторизация», а также поговорим о таких очень близких понятиях как «Идентификация» и «Аутентификация». Разберем, как всё это взаимосвязано и постараемся сделать это максимально просто и доступно для того, чтобы у вас не осталось никаких вопросов после прочтения данной статьи!
Привет! Меня зовут Артем. Уже несколько лет я генерирую полезный контент в области функционального тестирования, а также являюсь создателем нескольких крупных сообществ, которые помогают начинающим тестировщикам.
На данный момент существует большое количество площадок, групп и чатов, которые помогают специалистам разного уровня в аспектах обучения, общения, взаимопомощи. У меня появилась идея собрать их вместе и поделиться с сообществом. Все ресурсы бесплатные.
Всем привет! Я QA Engineer и недавно открыл для себя ChatGPT и хочу открыть этот мир другим тестировщикам. Эта статья не руководство к применению и каких-то суперлайфхаков здесь не будет. Цель этой статьи в том, чтобы показать огромные возможности нейросетей в помощи нам, тестировщикам, в работе. Надеюсь что кто-то, прочитав это, хоть немного сможет облегчить себе составление тест-кейсов, написание документации или написание автотестов. Примеров с написанием кода здесь по минимуму, так как таких материалов уже много.
Всем привет! Меня зовут Наташа, и я уже год являюсь тестировщиком в компании Usetech. Это моя вторая статья из серии статей, посвященных начинающим специалистам, в которой я хочу поделиться своими историями и опытом работы. Предыдущую статью вы можете прочитать по ссылке. Эта статья в первую очередь предназначена для начинающих тестировщиков, а старшим коллегам, возможно, захочется поделиться своими советами в комментариях.
В интернете можно найти много статей по запросу «ЧТО НУЖНО знать начинающему тестировщику»… КАК ПРАВИЛЬНО… ЧТО ВАЖНО… ПРИМЕРЫ… ШАБЛОНЫ…
Но очень мало где разбирают то, что получается на деле и как прийти от «неправильно» к тому самому «вот так надо». Предлагаю рассмотреть 5 не совсем выдуманных, а даже очень реальных ситуаций. Завариваем чашку чая, закутываемся в плед и начинаем!:)
Несколько недель назад я решил написать о тестировании фиксов. Главной моей целью было определить, существует ли системный подход, которому можно было бы следовать в общих случаях. Анализируя это, я быстро понял решающую роль уверенности в проверке и одобрении любого тестируемого нами программного обеспечения.
Уверенность диктует, сколько тестов, по нашему мнению, нам нужно выполнить, прежде чем мы сможем подтвердить успешность тестирования. Уверенность в команде разработчиков напрямую влияет на то, сколько времени мы потратим на тестирование, чтобы почувствовать, что наш продукт готов к релизу. Эта уверенность основывается на нашем опыте общения с командой разработки и качества их кода в прошлом.
Высокая уверенность — выполняется только самое необходимое количество тестов, гарантирующих, что программное обеспечение может быть принято. (Примечание: это не относится к критически важным программным системам.)
Низкая уверенность — на основе предыдущего опыта тестировщики могут проводить дополнительные проверки, даже если нынешнее качество кода хорошее.
Я считаю, что уровень уверенности очень влияет на скорость, с которой программное обеспечение может быть разработано. Часто можно услышать, что «QA — это узкое место процесса разработки», но это потенциально связано с исторически низким качеством кода, заставляющим тестировщиков перетестировать, даже когда проверяется код хорошего качества. Чтобы проиллюстрировать этот момент, я привожу ниже подход, который я придумал для тестирования и проверки исправлений ошибок.
Периодически у меня возникает необходимость анализа мобильных приложений под Android. И каждый раз наибольшей проблемой является настройка перенаправления трафика мобильного приложения на прокси-сервер BurpSuite так, чтобы в нем отображались все запросы приложения.
Данная заметка предназначена для систематизации в едином источнике методов обхода ограничений по перенаправлению трафика. Вопросы обхода детектирования Root, SSL pinning-a и прочих механизмов безопасности не будут рассмотрены в рамках данной заметки.
Для настройки нам понадобятся: BurpSuite, ADB, apktool, jarsigner, Android-девайс (или эмулятор).
В наш век высоких скоростей, время самый ценный ресурс, так как в связи с развитием интернета, информации очень много и проанализировать её всю досконально просто невозможно. В связи с этим, особо остро стоит вопрос быстроты загрузки приложений, веб страниц, видео и прочего контента. Так же не мало важную роль играет работоспособность приложений и сайтов как таковых, так как резкий наплыв большого количества пользователей может привести к временному сбою сервисов, а иногда и к полной их оствановке. Поэтому в IT компаниях пристальное внимание уделяется нагрузочному тестированию.
В начале у меня будет один вопрос к тебе дорогой читатель. Писал ли ты когда-нибудь unit-тесты на Groovy ? Если ты андроид-разработчик, то вероятность этого крайне мала. И я с таким не сталкивался пока не пришел на проект Альфы. Небольшой дисклеймер: если ты до этого никогда не писал unit-тесты, то этот материал может показаться тебе непонятным.
Давай представим, ты приходишь на проект и видишь тест, как на картинке. Что ты будешь делать дальше?
Думаю ни для кого не секрет, что хороший тестер‑автоматизатор постоянно пытается оптимизировать свою работу.
В современном мире разработки качество программного обеспечения играет далеко не второстепенную роль. И, в то время как скорость выхода релизов растет в геометрической прогрессии, тестирование выходит на новый уровень. Один из способов повысить качество выпускаемого продукта, это применение несколько иных подходов в разработке программных продуктов, а именно, различных гибких (Agile) практик и принципов.
В моей предыдущей статье «Лидерство в тестировании: введение» мы исследовали концепцию тестирования с точки зрения его целей. Краткое резюме: независимо от того, о каком типе теста вы говорите, мой совет — всегда задавайте конкретную цель теста. Это верно, даже если кажется, что это общепринятый термин, такой как модульный тест или приемочное тестирование.
Здесь я объясню, как определить стратегию тестирования, которая заложит основу для надежного и гибкого процесса тестирования, подходящего для любой методологии разработки, используемой вашей командой. Я раскрою:
— Что такое стратегия тестирования?
— Структура стратегии тестирования
Привет, Хабр! Меня зовут Герман, я давно работаю в тестировании (ex Тинькофф, Островок, Яндекс).
Про тестировщика создаётся стереотип ворчуна, который постоянно всем не доволен и занимается только тем, что ищет изъяны в чужой работе.
Поделюсь своим опытом — как тестировщику критиковать и сохранить хорошие отношения с командой.
Твою критику не должны воспринимать в штыки. С командой тебе работать несколько лет, ходить с ними в барчик и ещё карьеру как-то строить.
Наверное каждый разработчик и QA-инженер, в рабочем процессе сталкивался с необходимостью подмены отправляемых/принимаемых данных. Когда эта задача касается данных, гуляющих между клиентом и сервером, особых проблем она не приносит. Запрос можно модифицировать и отправить ручками, к примеру через Postman, а для модификации ответа можно использовать инструменты вроде Burp Suite, Charles и т.д., но что делать если целевой запрос отправляется с сервера?
Всем привет, я пробовал в прошлом году сделать дайджест для qa инженеров, но в связи с событиями 24 февраля я не смог найти силы продолжить
В этом году я постараюсь делать дайджест на постоянной основе
Существуют признаки высококачественного программного обеспечения. Оно удобно в использовании, надежно и обеспечивает производительность. Любое программное обеспечение, которое изобилует ошибками, работает нестабильно или работает не так, как задумано, считается неудачным.
Это приведет к появлению недовольных клиентов и разочарованных сотрудников, а также заставит клиентов потерять доверие к продукту.
От RPA (Robotic process automation) до высокотехнологичной разработки программного обеспечения — ежедневно создается огромное количество приложений. От стартапов до крупных предприятий — компании всех типов и размеров занимаются разработкой программного обеспечения.
Если ваша фирма также занимается разработкой программного обеспечения или хочет его разработать в ближайшем будущем, как вы можете обеспечить его высокое качество?
В этом может помочь тестирование. Оно гарантирует, что программное обеспечение соответствует таким основным характеристикам, как удобство использования, надежность и производительность.
Тестирование на совместимость — одна из таких форм тестирования программного обеспечения.
За последние несколько лет разработчики ПО и мобильных приложений очень четко осознали важность тестирования. Его популярность непрерывно растет. Только в США этот рынок услуг должен вырасти на 55,76 миллиарда долларов в течение 2022-2026 годов.
В этом материале мы приведем основные тезисы из обзора рынка тестирования программного обеспечения в крупном российском бизнесе, который подготовлен редакцией портала TAdviser. Исследование подробно описывает подходы российских заказчиков к выбору технологий и инструментов тестирования, а также модели их использования, дает представление о трендах рынка и потребности его игроков в кадрах.
Большинство из нас стремятся быть более эффективными, действенными и содержательными в тестировании. И мы делаем все необходимое для этого. Лучший способ сделать это — проводить автоматизированное тестирование вместо ручного. И, конечно же, мы хотели бы знать все современные тенденции в мире автоматизации. Только так мы можем быть на вершине нашей профессии.
Здравствуйте, меня зовут Артём, и я с ноября месяца изучаю тестирование. Спустя ровно два месяца я получил первое приглашение на техническое собеседование, позиция Junior QA Engineer, мобильная разработка, геймдев. Хотел бы поделиться этой историей с теми кому это может пригодиться, так как не все мои ожидания оправдались, а некоторые вопросы на собеседовании действительно поставили в тупик.
Изображение взято из https://www.niio.com/blog/what-is-ai-art-chatgpt/
TL;DR
1. Заводим аккаунт OpenAI;
2. Качаем Autoresponder for TG, например, для Телеграма;
3. Создаем правило для всех сообщений с маской *, вставляем туда токен для GPT-3;
4. ???????
5. PROFIT!
В предыдущих моих статьях были описаны варианты применения техники тест-дизайна «Таблица решений» для тестирования фильтрации и сложных веб-форм.
В этой статье я хочу показать, как эту технику можно применять для тестирования алгоритмов, в том числе и алгоритмов с приоритетом выбора данных.
