Home

Автор: Ольга Назина (Киселёва)

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

Однако помимо ТЗ есть еще куча другой документации, которую тоже стоит проверить. Как минимум вычитать, нет ли ошибок. Эта статья — как чек-лист, «что еще нужно найти и проверить».

Итак, давайте посмотрим, какая бывает документация:

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

По моему опыту, от работы с регулярными выражениями у всех болит голова. Никто не хочет разглядывать ^(19|20)\d\d[- /.](0[1-9]|1[012])[- /.](0[1-9]|[12][0-9]|3[01])$ и выяснять, что это значит!

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

Автор: Ольга Назина (Киселёва)

Какие у чек-листов есть плюсы и минусы?

Плюсы:

1. Нет копипасты
2. Мало текста
3. Проще поддерживать (медленнее устаревает)
4. Быстрее писать — меньше текста, больше дела!

Минусы: Не все поймут (кто проект впервые видит)

См также: Что вообще такое чек-листы.

Как их оформлять.

Это выдержка из моей школы для начинающих тестировщиков.

Обсудить в форуме

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

Недавно я прошла этот отличный курс по поиску веб-элементов от Эндрю Найта в Test Automation University. Вдобавок к полезному синтаксису доступа к элементам, я также выучила еще один способ с пользой применить инструменты разработчика!

Один из самых раздражающих моментов UI-автоматизации заключается в попытке выяснить, как найти на странице элемент без идентификатора автоматизации. Возможно, вы знаете, что если открыть инструменты разработчика в Chrome, то можно кликнуть правой клавишей на элемент страницы, выбрать Inspect, и этот элемент подсветится в DOM. Это полезно, но тут скрыто нечто еще более полезное: там есть строка поиска, позволяющая вам увидеть, правильно ли сработает локатор, который вы планируете использовать в тесте. Разберем на конкретном примере, как использовать этот ценный инструмент.

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

Давайте рассмотрим стандартную пирамиду автоматизации

Если говорить о программе:

• UI-тесты — честные тесты, «как это делал бы пользователь» (они же GUI, graphical user interface)
• API-тесты — опускаемся на уровень ниже, выкидывая лишнее.
• Unit-тесты — тесты на отдельную функцию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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