База данных — это место для хранения данных. Используется в том числе в клиент-серверной архитектуре. Это все интернет-магазины, сайты кинотеатров или авиабилетов... Вы делаете заказ, а система сохраняет ваши данные в базе.
В этот статье я на простых примерах расскажу, что такое база данных и как она выглядит. А потом поясню некоторые термины из конкретной (реляционной) базы. Те, с которыми вы почти наверняка столкнетесь на работу.
Статья рассчитана на начинающих тестировщиков или аналитиков, то есть тех, кто будет работать с базой, но не на супер-глубоком уровне. Она для тех, кто только входит в мир ИТ, и многого не знает. Она объясняет, что это за звено в клиент-серверной архитектуре такое, и зачем оно нужно.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
На прошлой неделе я проводил двухдневную версию своего мастер-класса по тестированию API на Python. Пока мы выполняли упражнения по созданию автотестов для REST API с использованием requests, один из участников спросил, применимо ли это к GraphQL API. Никогда раньше этого не делал, но после совместного гугления и обсуждения мы постановили, что это небольшая проблема.
Так как мы обсуждали это в первый день курса, я обещал подготовить ряд быстрых упражнений, над которыми можно будет поработать на второй день. В этой статье вы увидите ряд примеров, которые входили в эти упражнения.
Один из участников предложил отличное приложение в качестве тестируемого API: SpaceX GraphQL API. Этот публичный API содержит информацию о компании SpaceX, а также ее истории, космическом флоте, миссиях, запусках, и т. д. Множество данных, есть с чем поработать.
Всем привет! Недавно я наткнулся на World Quality Report (ссылку поставил в конце, чтобы не пугать вас сразу отчетом на 50 страниц) — большой обзор трендов в тестировании 2020-2021 годов. А поскольку мы в Qameta Software сами постоянно сталкиваемся с командами тестирования, которые стараются как-то поправить свои процессы и наладить работу тестирования, я решил оценить, насколько они актуальны в России.
Обзор базируется на результатах 1750 получасовых телефонных интервью с CIO или руководителями технологических подразделений, которые посчитали качество ПО и тестирование критично важным для развития бизнеса.
В этой статье я взял основные тренды из отчета и постарался оценить их с точки зрения того, что происходит в компаниях, с которыми мы сталкиваемся.
Автор: Баз Дейкстра (Bas Dijkstra) Оригинал статьи Перевод: Ольга Алифанова
Если вы когда-либо работали в команде, практикующей BDD и использующей Cucumber или SpecFlow для создания исполняемых спецификаций, то вы знаете, как тяжело писать читабельные сценарии. Очень, очень тяжело!
В этой статье я хочу подробно разобрать фичу связок Java Cucumber, которые помогут вам писать читабельные спецификации: это использование таблиц данных.
Таблицы данных – это таблицы, которые можно передавать в отдельный шаг в качестве аргумента. Данные в этой таблице затем будут обработаны согласно определению шага. Таблицы данных не надо путать с таблицами примеров – таблицы примеров содержат примеры для сценариев целиком и используются в описаниях сценариев. Таблицы данных позволяют использовать более сложные структуры данных в качестве аргумента для шага.
Давайте рассмотрим ряд примеров с применением различных форм таблиц данных, а также сравним, как это будет выглядеть, если те же самые данные определять в текстовом формате.
Мне нравятся книги из серии Head First O`Reilly — они рассказывают просто о сложном. И я стараюсь делать также.
Когда речь идёт о базах данных, могут всплыть магические слова «Требования ACID». На собеседовании или в разговоре разработчиков — не суть. В этой статье я расскажу о том, что это такое, как расшифровывается ACID и что означает каждая буква.
Требования ACID — набор требований, которые обеспечивают сохранность ваших данных. Что особенно важно для финансовых операций. Мы же не хотим остаться без денег из-за разрыва соединения или ошибки в ПО, не так ли?
Автор: Адам Найт (Adam Knight) Оригинал статьи Перевод: Ольга Алифанова
Большинство занятых в разработке ПО рано или поздно сталкиваются с гнетущим страхом, что все вокруг работают гораздо лучше. Очень легко попасть в ловушку убеждения, что все остальные тщательно внедряют последние методы и техники, а вы топчетесь на месте, сражаясь с рутинными задачами, отнимающими все ваше время. Spotify – отличный пример компании, чьи статьи и контент рассказывают о райски отлаженных гибких процессах, в то время как донесения из окопов гласят о куда более практичных методах, а также всем знакомых проблемах, с которыми внедрение этих методов сталкивается.
Наиболее эффективная, по моему мнению, тактика работы с риском подобной паранойи – это общение с коллегами. Если вы соберетесь вместе в одной комнате с теми, кто занимает равную вам позицию, то быстро узнаете, что ваши сложности не хуже, чем у других, и мало кто может позволить себе роскошь применения идеалистических книжных и маркетинговых техник. Давным-давно я ощутил это на себе во время конференции по продуктовому маркетингу в ходе обсуждения тестирования гипотез.
Всем привет! Меня зовут Миша, я работаю на позиции ручного тестировщика, или Manual QA - кому как удобно. В связи с тем, что в моей работе преобладает ручное тестирование - я часто сталкиваюсь с консолью разработчика в браузере (думаю как и 99.9% web-тестировщиков).
В интернете огромное количество источников, в которых можно найти информацию про DevTools, как для разработчиков, так и для тестировщиков. Конечно, наполнение таких статей очень сильно разнится в зависимости от ее направленности. Изучив большое количество подобного материала и поняв, что нас (тестировщиков) обделяют информацией :), решил залезть в первоисточник для изучения инструментов разработчика в полном объеме. Пройдясь по всем пунктам огромного меню, выписал для себя порядка 20 пунктов, которые были бы интересны (читай полезны) для тестировщиков. Сразу скажу, что в статье я не буду рассказывать, как пользоваться тем или иным инструментом, так как это подробно описано в статьях, которые будут прикреплены к каждому из пунктов. Цель моего повествования - скорее вычленить из огромного списка возможностей DevTools, именно те, которые были бы полезны для QA-специалистов. Не претендую на объективность и полную раскрытость темы, но постараюсь это сделать.
Автор: Ли Хокинс (Lee Hawkins) Оригинал статьи Перевод: Ольга Алифанова
Это четвертая часть серии статей, в которой я отвечаю на самые популярные вопросы о тестировании согласно результатам автодополнения поисковой системы.
В этой статье я разбираюсь с вопросом "Как осуществляется тестирование?" (и связанными с ним вопросами – "каковы методологии тестирования", "каков у тестирования жизненный цикл" и "как выглядит процесс тестирования").
Существует множество способов проведения тестирования – разные люди в разных организациях имеют разные представления о том, что такое "хорошее тестирование". Не поддавайтесь соблазну подумать, что существует "один верный способ" проводить тестирования? Это не так – не существует единственного, общепринятого, достоверного официального способа выполнить тестирования – и я считаю, что это хорошо.
Поэтому вопрос, возможно, должен звучать как "Как может проводиться тестирование?" – и для ответа на этот вопрос очень важно понимать контекст. Джеймс Бах определяет "контекст" следующим образом:
"Говоря о контексте, я имею в виду общность ситуации, влияющей на успех или провал предприятия".
(Dictionary.com схожим образом определяет контекст как "набор обстоятельств или фактов, окружающих определенное событие или ситуацию").
Если вы тестируете API, то должны знать про два основных формата передачи данных:
XML — используется в SOAP (всегда) и REST-запросах (реже);
JSON — используется в REST-запросах.
Сегодня я расскажу вам про JSON. И расскажу в основном с точки зрения «послать запрос в Postman или прочитать ответ», потому что статья рассчитана на студентов, впервые работающих с Postman.
JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.
