Тестировать можно по-разному, и у каждого инженера со временем вырабатываются свои предпочтения и стиль работы. Однако в рабочее время иногда требуется применять определенный вид тестирования, поэтому всегда полезно разобраться, к чему именно у вас лежит душа. А если и не лежит, то познакомиться с чем-то новым. Поэтому сегодня мы поговорим об исследовательском тестировании, а также его отличии от скриптового.
Что же такое исследовательское тестирование? Это вид тестирования, при котором мы одновременно и тестируем, и придумываем тест, опираясь на поведение продукта.
Всем привет! Я Оля, тестировщик мобильных приложений в hh.ru. Сегодня мы завершаем серию ответов на самые популярные вопросы про автоматизацию тестирования. Ранее мы уже ответили на вопросы ручного тестировщика, менеджера и технического директора. Пришло время ответить на пять самых интересных вопросов начинающих автоматизаторов — про флакования и баги с прода, нашу борьбу за стабильность и как не терять всеобщее доверие к автотестам.
Видеоверсию моих ответов можно посмотреть и послушать тут.
Я посмотрела, как тестируют поиск начинающие тестировщики, и решила написать этот чит-лист проверок. Это такая серебряная пуля, которую можно применить на любом проекте, лишь немного варьируя под себя, под свой проект.
Поиск — он же есть практически в каждой системе. Поэтому здорово, когда есть шпаргалка «какие вопросы задать аналитику» и «какие проверки провести». Именно это мы в статье и обсудим. Сначала я дам чек-лист, а потом разберу каждый пункт отдельно.
Автор: Филип Рик (Filip Hric) Оригинал статьи Перевод: Ольга Алифанова
Краткое содержание: код Cypress выполняется блоками. Чтобы использовать данные оттуда, можно использовать команду then(), mocha-алиасы, объекты окна или переменные окружения. Я создал паттерн с использованием переменных окружения, и покажу его во второй части этой статьи. Мое приложение и этот паттерн можно найти на GitHub. Для обсуждения присоединяйтесь к серверу Discord.
Дело обстоит так: в начале вашего теста вы вызываете конечную точку API. Она даст вам ответ, который нужно использовать в ходе теста. Что вам делать?
Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Это восьмая часть серии статей, в которой я отвечаю на самые распространенные вопросы о тестировании, согласно результатам автодополнения поисковых систем.
В этой статье я отвечаю на вопрос, можно ли научиться тестировать самостоятельно (и связанные с ним вопросы, можно ли выучить тестирование онлайн, и каждый ли может научиться тестировать).
Автор: Пол Гриззафи (Paul Grizzaffi) Оригинал статьи Перевод: Ольга Алифанова
В рекламе 70-х мальчик спросил мудрую сову, сколько раз надо лизнуть леденец с начинкой, чтобы добраться до сердцевины. Сова – очевидно, тестировщик, размышляла, сколько раз для этого понадобится; в юмористическом повороте сюжета она решила, что три. Но на третьем "лизе" она хрустнула конфеткой и съела начинку.
Как и этот леденец, тест-автоматизация имеет сердцевину, только состоящую из трех частей – стимул, ответ и некоторое количество проверок. Вот что вам нужно понимать о каждой из них, чтобы создавать стеки и смежные стеки, добавляющие гибкости вашей автоматизации.
Docker — это контейнер для приложения. В котором уже всё настроено — и операционная система, и сервер приложения, и вся инфраструктура. Бери да используй!
Докер активно используют разработчики и тестировщики для проверки приложений. Его используют и для поставок клиентам готового продукта. В нем поднимают приложения, гоняют автотесты... А также упоминают в вакансиях и спрашивают на собеседованиях =))
Поэтому в этой статье я расскажу на простом языке и с картиночками, что это вообще такое. А за кровавыми техническими подробностями идите в раздел «статьи и видео по теме».
База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов... Вы делаете заказ, а система сохраняет ваши данные в базе.
В этот статье я на простых примерах расскажу, что такое база данных и как она выглядит. А потом поясню некоторые термины из конкретной (реляционной) базы. Те, с которыми вы почти наверняка столкнетесь на работу.
Статья рассчитана на начинающих тестировщиков или аналитиков, то есть тех, кто будет работать с базой, но не на супер-глубоком уровне. Она для тех, кто только входит в мир ИТ, и многого не знает. Она объясняет, что это за звено в клиент-серверной архитектуре такое, и зачем оно нужно.
Если вы тестируете API, то должны знать про два основных формата передачи данных:
XML — используется в SOAP (всегда) и REST-запросах (реже);
JSON — используется в REST-запросах.
Сегодня я расскажу вам про JSON. И расскажу в основном с точки зрения «послать запрос в Postman или прочитать ответ», потому что статья рассчитана на студентов, впервые работающих с Postman.
JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.
Чем проще и понятнее описаны требования — тем меньше багов будет в функционале. Потому что не будет разных прочтений, додумок и прочего. А еще в простыне текста легко потеряться и что-то просто забыть реализовать.
Как же сделать ТЗ понятнее? Можно улучшить текст — вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...
Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое.
