Как не нужно презентовать свой продукт или повесть о том, зачем необходимо тестирование перед релизом)

Смотреть с 19 минуты

#QA #SQL

Давайте поговорим про нормализацию отношений. И да, сегодня мы поговорим про SQL и связи между таблицами.

Читать

#QA #AQA

В этой статье поговорим про разработку через приемочные тесты (ATDD). Что это такое, и с чем его едят.

Читать

#QA #Pairwise_testing

Данная задачка и разбор наглядно показывают проблемы современных методов поиска информации (гуглить), если при их использовании выключать мозг и всё принимать на веру. Используйте pariwise правильно

Читать

Типичное общение с заказчиком

Всем привет!
В июле стартует онлайн-курс "Автоматизация тестирования на Java".
Ждем всех, кому интересно получить знания
по актуальному и востребованному направлению AQA.
Вся информация в "шапке" регистрационной формы
https://forms.gle/1RrUKxTz6gpCdd97A

Привет, коллеги.

В одном из предыдущих статей мы рассказывали о том, что такое SQL-инъекция. В этой решили рассказать про другой тип уязвимостей, а именно - подделку запросов пользователя.

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

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

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

Так как, собственно, подделать запрос? Как сделать так, чтобы сервер получил запрос от пользователя, который тот не совершал? Самый простой ответ - заполучить cookie этого пользователя. Но это, конечно, не всегда просто и злоумышленники придумали другой способ.

Когда мы с вами открываем какой-то сайт, браузер сначала получает “скелет” это сайта, т.е. HTML-код. В нем может быть множество ссылок - на картинки, на css-файлы со стилями, на JS-файлы и так далее. Все они могут располагаться как по тому же домену, так и на каких-то CDN. Браузер должен последовательно запросить все указанные в HTML ссылки прежде чем страница будет считаться загруженной. Все эти запросы также происходят по http-протоколу.

Теперь давайте представим, что мы как-то попали на сайт злоумышленника. Например, перейдя по ссылке из email-а или просто как-то нагуглив его. Не суть важно. Что, если на этом сайте, в HTML-коде будет ссылка на как бы картинку, но на самом деле нет. Ведь браузер пока не сходит по этой ссылке, он не поймет, что по ней никакой картинке нет. Т.е. мы можем спровоцировать браузер отправить любой запрос на любой домен, просто прописав соответствующую ссылку в HTML-коде своего сайта. Понимаете, к чему я? :)

Давайте оценим еще раз:

- Чтобы совершить какое-то действие, от имени пользователя нужно создать http-запрос.
- Браузер автоматически прикладывает авторизационную cookie ко всем запросам на домен, для которого эта cookie выставлена.
- Браузер делает все http-запросы по адресам, который указаны в HTML-коде открываемого сайта, даже если ссылка ведет на другой домен.

Эти три факта и помогают подделать запрос. На сайте злоумышленника находится ссылка на тот сайт, который является атакуемым. Что-то вроде такого:

 <img src=”www.site.com/action/remove_my_profile” />

Когда пользователь, авторизованный на “хорошем” сайте, попадает на сайт злоумышленника, HTML-код “плохого” сайта провоцирует сделать http-запрос на “хороший” сайт. Причем браузер автоматически прикладывает cookie и сервер хорошего сайта будет думать, что пользователь сделал запрос намеренно. При этом действие может быть любым - от невинного разлогина до перевода денег на счет злоумышленника и так далее.

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

Спасибо за внимание.

#Jira #QA

В сегодняшней нашей статье поговорим про продвинутый поиск в Jira. Иногда базового набора фильтров для поиска недостаточно, и на помощь приходит язык JQL, специально разработанный для Jira.

Читать

#CI_CD #Devops

Continues integration, continues delivery и continues deployment, так расшифровавается это понятие.
На русский язык это можно перевести, как:
- Непрерывная интеграция.
- Непрерывный доставка.
- И непрерывное развёртывание.
Для тех кто не знает, CI/CD - это концепция, которая реализует своего рода автоматизированный конвейер.
Данный конвейер облегчает процесс слияния только что написанного и законченного кода с основной кодовой базой.
А так же запуск различных тестов и проверок, плюс автоматизированные деплои и развёртывания.

Смотреть на Youtube

QA Meetup online. by Andersenlab.com
15 июля 18.00

Жизнь QA сложна, но интересна. Как сделать меньше первого и больше второго? Узнаете на нашем бесплатном онлайн-митапе! Матерые баголовцы из Andersen и СберМаркета поделятся своими кейсами и (возможно) сделают вашу жизнь лучше. Регистрируйтесь, не пропускайте!

https://forms.gle/QvCqkptP98Dev8H28

Спикеры:
1) Владимир Худойкин - Head of Test Automation at SberMarket
Доклад: “Как мы вырастили своего Кракена в СберМаркете”
Кракен - это название фреймворка автоматизации в СберМаркете. Доклад будет о том, как мы этот фреймворк развивали и из чего он состоит, с какими трудностями столкнулись и как принимали то или иное решение.

2) Эльдар Нуртдинов - AQA Engineer в компании Andersen
Доклад: “Жизнь замечательных Pipelines”
Расскажем на примерах из опыта как можно строить запуск тестов, как выстроить оптимальный pipeline (опять же из опыта), соберём анонимную статистику от коллег по их сборкам на проекте. Сделаем выводы о плюсах и минусах.

Здравствуйте, коллеги. Мобильные девайсы набирают обороты, на рынке все больше продуктов имеют мобильную версию. Соответственно, растет спрос и на мобильное тестирование.

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

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

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

Что касается iOS, то компания Apple разрабатывает это ОСь только для своих девайсов, которых не так много - iPhone, iPad, iPod.

С Android дела обстоят совершенно иначе, OC от компании Google устанавливается на довольно широкий спектр девайсов. Помимо оригинальных девайсов Google Pixel есть еще девайсы от Samsung, Xiaomi и многие другие. Все они отличаются мощностью, экранами, ценой и так далее.

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

Опираясь на свой бюджет, из списка девайсов, представленных в статистике, стоит выбирать как можно более разнообразные девайсы - отличающиеся по настройкам экрана (такие показатели, как размер, разрешение и dpi), мощности процессоров, версии ОС и прочим вещам. Ваше тестирование должно быть как можно разнообразнее.

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

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

Списки неплохих подборок статистики использования девайсов:

Apple: https://developer.apple.com/support/app-store/
Android: https://developer.android.com/about/dashboards
Mixplane: https://mixpanel.com/trends/#report/ios_12
Appbrain: https://www.appbrain.com/stats/top-android-phones-tablets-by-country?country=ru

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

Спасибо за внимание :)

Когда разработчик пытается взять отпуск перед релизом

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

Логическая задача №1

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

Ниже приведем возможные варианты решения задачи №1.

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

С таким же успехом можно, например, ходить по сторонам от начального вагона на равные расстояния, постепенно их увеличивая, и инвертировать в них свет. То есть если считать, что сначала вы в вагоне с номером 0, то ходить надо в -1, 1, -2, 2, -3, 3 и так далее. Если при этом запоминать состояние самого дальнего вагона, то при повторном прохождении мимо него вы заметите изменившийся свет, если круг замкнётся. А зная длину пути в обе стороны, вы легко вычислите общее количество вагонов.

В комментариях к задаче было много оригинальных идей.
Good job! 💪

Meetup сегодня: 07.07 в 18:00 (Kiev)

Офис: Cherkasy
Докладчик: Denys Teremetskyi
Тема: API testing with Postman / Let's talk about its main and additional features.
Целевая аудитория: Junior QA
Трансляция: Zoom
https://us06web.zoom.us/j/85762700244?pwd=bkpmQ3gzeGtMTWlnUzR4dUg4eE43dz09

КАЗАНЬ - НЕ СПИ! Компания Andersen приглашает на бесплатные образовательные онлайн-курсы "Тестирование ПО".

QA - это актуально и очень востребовано!
Лучшие пройдут на стажировку с последующим трудоустройством в международной IT-компании Andersen https://andersenlab.com/

Старт курсов - вторая половина августа 2021
2 месяца, теория + практика + домашние задания

За более подробной информацией и для заполнения заявки переходите по ссылке Google Form:
https://forms.gle/aKAdBQgmQCDuaeXKA

Здравствуйте, коллеги.

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

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

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

Получается следующая последовательность действий:

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

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

Итого, что же проверять тестировщику в данном контексте? Конечно же наличие токена в запросах, особенно важных - на оплату, изменение пароля и так далее. Чаще всего токены находятся либо в заголовках запросов, либо в параметрах.

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

#AQA #Java

Видео о целесообразности написания автотестов на Java в 2021 году. Какие плюсы, минусы и альтернативы.

Смотреть на Youtube