Home

Автор: Дейв Вестервельд (DaveWesterveld)
Оригинал статьи
Перевод: Ольга Алифанова

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

На первом курсе университета у нас был профессор математики по кличке "Эйнштейн" – частично из-за его прически, а частично потому, что он делал математику такой же сложной, как теорию относительности. Он начинал решать задачу на доске, а затем говорил "следовательно, очевидно, что" и выводил решение. Мы сидели с озадаченными лицами. Очевидное для него было неочевидно нам, студентам. Нам нужно было знать промежуточные шаги, которые он проскочил, чтобы разобраться, что произошло.

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

Итак, после этого долгого вступления, вот моя попытка упрощенного руководства для начала API-тестирования.

Автор: Назина Ольга

Транзакция — это набор операций по работе с базой данных (БД), объединенных в одну атомарную пачку.

_{(Предполагается, что вы знаете, что такое БД. Но чуть позже тут будет ссылка на статью «что это такое»)}

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

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

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

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

Автор: Кристин Джеквони (KristinJackvony)
Оригинал статьи
Перевод: ОльгаАлифанова

Если вы работаете на компанию, разрабатывающую ПО для конечных пользователей, то, возможно, вы слышали о пользовательских персонах. Персона – это репрезентация сегмента конечных пользователей вашего приложения. К примеру, если вы делаете сайт для продажи товаров для дома, одной из ваших персон может быть Свежий Домовладелец Ник, который только что купил свой первый дом и не особенно разбирается в починке всяких мелочей. Другой персоной будет Все-Сама-Дора, которая много лет чинит все в доме самостоятельно.

Недавно мне пришло в голову, что в тестировании тоже есть персоны. Однако, в отличие от пользовательских, этих нужно избегать? Читайте дальше, чтобы узнать, применимы ли эти персоны к вам.

Автор: Николай Топычканов

Пожалуй сложно объяснить любую абстракцию без материального примера, который легко можно пощупать и убедится в его реальности. Я долго думал что бы могло послужить для меня таким вот материальным воплощением понятий тестирования, контроля качества (quality control) и обеспечения качества (quality assurance) готовясь к собеседованию.

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

Ниже приведено краткое, достаточно упрощенное и возможно излишне дилетантское понимание разницы между этими тремя направлениями.

Автор: Кристин Джеквони (KristinJackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Несколько месяцев назад один из коллег-разработчиков попросил проверить фикс бага. Для проверки мне нужно было сделать HTTP-запрос с методом OPTIONS. Я никогда не слышала о таком методе и задумалась, о каких еще HTTP-методах я ничего не знаю. В этой статье я расскажу о редко используемых методах и том, как их можно применить в тестировании.

Автор: Ольга Назина

Если повторять одни и те же тесты снова и снова, в какой-то момент они перестанут выявлять новые ошибки.

Эту аналогию ввел Борис Бейзер в 1983 г в своей книге "Software Testing Techniques". Он привел пример обработки полей пестицидами. Поле обрабатывается неким пестицидом в первый раз, и значительная часть вредителей погибает.

Автор: Майкл Болтон (MichaelBolton)
Оригинал статьи
Перевод: Ольга Алифанова

Мой хороший друг Кит Клайн недавно написал на LinkedIn:

"Почему это не отловили в QA" – это, возможно, наиболее психологически жуткая и дисфункциональная культура тестирования, которой только может обладать компания. Я видел, как она буквально разрушала хороших людей и карьеры. Она плюет в лицо системному мышлению, сложности отказа, менеджменту рисков, и просто всему, что мы знаем о психологии тестирования. Однако культура буллинга и перевода стрелок в IT не дает ей умереть…"

Здесь есть о чем подумать. Начнем с того, что такое QA.

Если QA – это обеспечение качества, то важно выяснить, кто или что обеспечивает качество – ценность для значимых лиц.

Оригинальная публикация

Тестировщик — профессия, которая с каждым годом набирает все больше популярности. Но чем же она так привлекает потенциальных соискателей?

Возможность попасть в IT-сферу, высокая зарплата, перспектива работать за рубежом  — заманчивые реалии специалистов по тестированию. Именно они так привлекают как желающих сменить профессию, так и вчерашних школьников.

Практически нулевой вход в профессию — не исключение при выборе новой стези. Несмотря на несколько повысившиеся требования работодателей к начинающему специалисту, стать тестировщиком с нуля в 2020 году вполне реально даже без технического образования и после 30 лет.

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

Оригинальная публикация

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

Но с чего же начинать писать тесты для новых проектов? Лично для меня, как для программиста, самый интуитивный ответ — это Unit-тесты. Однако опрометчиво накидываться на сочинение Unit-тестов может не только оказаться бесполезым занятием, но даже нанести вред в будущей разработке проекта.

Поэтому в этой статье я хочу предложить вам альтернативу и расскажу о том, почему лучше всего в самую первую очередь писать самые сложные тесты (системные), а затем уже — все остальные.