Тестирование GUI

GUI  — graphical user interface, графический пользовательский интерфейс. Это то, с чем работает обычный пользователь, открыл сайт и тык-тык по кнопочкам.

Тестирование GUI — это проверка того, что интерфейс выглядит как задумано. Иногда это означает выверку по макетам из ТЗ. И даже если видишь сдвиг на 1 пиксель — заводишь баг. Но чаще всего это означает просто проверить, что все кнопочки нажимаются, текст за границы нигде не вылезает, и других косяков нет. Баги вёрстки в вебе, баги наложения текста в мобилках.

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

Этим человек выгодно отличается от робота. Робот проверит ровно то, что ему сказали. Сказали «тыкнуть «войти» и ввести такие-то данные», он и тыкнет. И пофигу будет роботу, что формочку всю перекосило, свою задачу то он выполнил! А человек заметит косяк и поставит баг.

Что такое База Данных (БД)

 База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов... Вы делаете заказ, а система сохраняет ваши данные в базе.

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

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

Приоритет в магазине и в баге

Понятное дело, что для своей задачи хочется всегда поставить высокий приоритет. Ведь это же такой страшный баг, надо срочно исправить! Особенно когда речь идет о новичках ツ

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

И вот тут начинается приоритезация. Что действительно важно купить? Кошке корм хотели, но он ещё есть, зато молока совсем нету, лучше взять его. Высокий приоритет получают те продукты, без которые важно купить именно сейчас. А всё, что можно отложить на потом (завтра / в среду / через неделю) — это уже не высокий приоритет.

Тестирование совместимости

Что может повлиять на работу приложения?

— Разные ОС (Windows, Linux, MAC)

— Разное железо (видеокарта, процессор, и т.д.)

— Разные браузеры (сhrome, firefox, mobile opera, safari, IE)

— Разный сторонний софт (в браузере могут мешать плагины, на самом компе — Касперский или другое ПО, которое, например, выжирает память)

Совместимо ли ваше приложение с разными браузерами? А разными операционными системами? Именно в этом заключается тестирование совместимости — проверить и предоставить информацию.

Панбагон. Отвлекся на звонок? Корзина больше недоступна

Делала заказ на OZON. Посылка получилась весом около 20 кг, поэтому я стала размышлять, как сделать лучше:

1. Отправить брату на квартиру и попросить его потом припереть ко мне.
2. Заказать на квартиру (там ремонт и никто не живет, то есть ради курьера придется ехать) и попросить брата встретить.

Так как в любом случае мне нагружать брата, решила проконсультироваться с ним =) 

В итоге в озоне:

• стоял предварительно адрес брата (прошлый заказ был туда)
• я поменяла на другой адрес, но "оформить" не нажала
• свернула приложение для звонка.

Созвонились с братом и решили пойти по первому варианту, то есть прислать посылку ему. Возвращаюсь в приложение (прошло ну минут 5 от силы), снова меняю адрес доставки на тот, что стоял исходно, нажимаю «далее». Но ой... Что-то пошло не так:

Ошибка в checkout

Ой, ну ладно ладно, подумаешь, на 5 минут в подвешенном состоянии оставила. Такое бывает с интернет-магазинами, что корзине надо обновиться.

Тур чашки кофе

Входит в «Туры по развлекательным районам», Tours Through the Entertainment District

Вольный перевод статьи Уиттакера из книги “Exploratory Software testing”. Туры помогают искать баги, взглянув на систему по-новому. Тестировщик выбирает тур и следует его цели, не отвлекаясь ни на что другое. Словно турист в незнакомом городе, составил план и пошел!

Тур чашки кофе — это когда ты работал-работал с приложением, а потом решил немного отдохнуть. Пошел и выпил кофе, например. А потом вернулся и решил продолжить работу.

Пора отдохнуть!

Обычно попить чай / кофе — это недолго, минут на 5. Именно это мы и делаем, уходим на 5 минут, оставив приложение на каком-то этапе. Желательно, чтобы это был один из N этапов, то есть не заключительный — например, начали оформлять заказ в интернет-магазине и не закончили, отвлеклись. А потом вернулись и пытаетесь продолжить.

Требования ACID на простом языке

Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.

Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.

Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?

См также:

Что такое транзакция

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

Ссылка на ХАБР

Atomicity — Атомарность

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

Друг познается в беде, а база данных — в работе с ошибками. О, если бы всё всегда было хорошо и без ошибок! Тогда бы никакие ACID были бы не нужны. Но как только возникает ошибка, атомарность становится очень важна.

Допустим, вы решили отправить маме деньги. Когда вы делаете перевод внутри банка, что происходит:

1. У вас деньги списались

2. Маме поступили

И допустим, что у нас 2 отдельных запроса. А теперь посмотрим, что будет при возникновении ошибок:

Ресурсы и инструменты для практики с базами данных | SQL (видео)

 

У Дениса Безтужева на канале «All about QA» вышло классное для новичков видео — «Ресурсы и инструменты для обучения и практической работы с базами данных | SQL».

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

И мне видео в тему, у меня есть статья «Как изучить основы SQL за 2 дня», но там примеры на тяжеловесной БД, не все могут её установить, а мне и помочь то нечем, я сама эту базу лет 10 не поднимала уже... Всё хочу переписать примеры под XAMPP сервер, но это слишком низкий приоритет, уж извините)) А теперь есть куда послать потыкать!

См также:

Изучаем SQL. Линн Бейли — книга, очень её рекомендую

SQL. Полезные запросы — моя шпаргалка

Курсы по SQL, моя подборка

Что такое JSON

 Если вы тестируете API, то должны знать про два основных формата передачи данных:

• XML — используется в SOAP (всегда) и REST-запросах (реже);

• JSON — используется в REST-запросах.

Сегодня я расскажу вам про JSON. И расскажу в основном с точки зрения «послать запрос в Postman или прочитать ответ», потому что статья рассчитана на студентов, впервые работающих с Postman.

Ссылка на Хабр (там содержание кликабельное)

JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.

См также:

Что такое API — общее знакомство с API

Что такое XML — второй популярный формат

Введение в SOAP и REST: что это и с чем едят — видео про разницу между SOAP и REST

В SOAP API возможен только формат XML, а вот REST API поддерживает как XML, так и JSON. Разработчики предпочитают JSON — он легче читается человеком и меньше весит. Так что давайте разберемся, как он выглядит, как его читать, и как ломать!

Как устроен JSON

В качестве значений в JSON могут быть использованы:

• JSON-объект

• Массив

• Число (целое или вещественное)

• Литералы true (логическое значение «истина»), false (логическое значение «ложь») и null

• Строка

Я думаю, с простыми значениями вопросов не возникнет, поэтому разберем массивы и объекты. Ведь если говорить про REST API, то обычно вы будете отправлять / получать именно json-объекты.

 

JSON-массив — что это и как он устроен

Давайте начнем с примера. Это массив:

[ "MALE", "FEMALE" ]

Массив заключен в квадратные скобки []

JSON-объект — что это и как он устроен

Возьмем пример из документации подсказок Дадаты по ФИО:

{
  "query": "Виктор Иван",
  "count": 7
}

И разберемся, что означает эта запись.

Объект заключен в фигурные скобки {}

JSON-объект — это неупорядоченное множество пар «ключ:значение».

Ключ — это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы: «смотри, здесь у меня значение такого-то параметра!». А иначе как система поймет, где что? Ей нужна подсказка!

Правила Well Formed JSON

Это выдержка из моей статьи «Что такое JSON»

Разработчик сам решает, какой JSON будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. Наш JSON должен быть well formed, то есть синтаксически корректный.

Чтобы проверить JSON на синтаксис, можно использовать любой JSON Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

Но учтите, что парсеры внутри кода работают не по википедии или w3schools, а по RFC, стандарту. Так что если хотите изучить «каким должен быть JSON», то правильнее открывать RFC и искать там JSON Grammar. Однако простому тестировщику хватит набора типовых правил с w3schools, их и разберем.

Правила well formed JSON:

1. Данные написаны в виде пар «ключ:значение»

2. Данные разделены запятыми

3. Объект находится внутри фигурных скобок {}

4. Массив — внутри квадратных []