Home

Опубликован очередной выпуск рассылки за первую половину ноября.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

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

Привет, я Андрей Шальнев, QA Automation Lead в проекте Skyeng Vimbox. В течение года мы с командой занимались оптимизацией процессов автоматического тестирования и сейчас вплотную подошли к ее финальной стадии. А это хороший повод выдохнуть, пересмотреть бэклог и подвести какие-то промежуточные итоги. Для Хабры я решил сделать подборку из десяти наиболее полезных и при этом простых вещей, которые помогли нам справиться с задачей оптимизации автотестов. Надеюсь, статья пригодится QA-командам в растущих компаниях, где старые процессы тестирования уже не справляются с нагрузкой, и вопрос реорганизации встает ребром.

Автор: Джеймс Бах (James Bach)
Оригинал статьи
Перевод: Ольга Алифанова

Алекс Бунарджич задал мне вопрос, который вдохновил меня на целую статью:

"Я считаю (и я убежден, что вы найдете способ убедить меня, что я в корне неправ), что если человек намерен улучшить качество, поддерживая высокие этические стандарты, то имеет смысл прищучить проблему в зародыше – или, как минимум, как можно ближе к источнику. Тестирование, как я понимаю, не связано с производством качества, и, следовательно, находится ниже по течению. Оно, конечно, тоже очень важно, но определенным образом смахивает на борьбу с ветряными мельницами. Неужели вам не хочется направить свои выдающиеся интеллектуальные качества на деятельность, связанную с производством качества? Я убежден, что если бы вы стали разработчиком или архитектором ПО, вы были бы не менее успешны и влиятельны, и, возможно, имели бы больший охват аудитории".

Спасибо за вопрос, Алекс, и вот мой ответ.

Автор: Хотенов Артём, hotenov.com

Несмотря на колоссальные возможности современных табличных редакторов, для многих команд разработки рано или поздно встает вопрос о внедрении специализированных инструментов (систем) для управления процессом тестирования в своих проектах. Какой же из них выбрать?



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

В своих поисках я натыкался на множество аналогичных статей (в одной из которых я позаимствовал структуру сравнительной таблицы), но все они скупо перечисляют функции с сайтов этих систем и 1-2 скриншота интерфейса и зачастую содержат скрытую или открытую рекламу одного из таких инструментов. Мне же захотелось испытать каждую систему “на себе” и непредвзято поделиться увиденным, рассказать о своих ощущениях.

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

В прошлый раз мы начали разбираться с тестированием CRUD. Как вы помните, CRUD означает "Create, Read, Update, Delete" (создание, чтение, обновление и удаление). В прошлый раз мы обсуждали тестирование создания и чтения, а теперь рассмотрим обновление и удаление.

Обсуждая операцию чтения, я упоминала, как важно тестировать сценарии, при которых данные в базе неверны. Это верно и для операции обновления. Только то, что текстовое поле предполагается обязательным и должно разрешать определенное количество символов, не означает, что именно так работает ваша база данных!

Задумались о получении сертификата ISTQB, но пока не знаете с какой стороны подойти к этому вопросу?

Для чего вообще нужна сертификация ISTQB FL?

Как готовиться? Проштудировать свежую версию силлабуса, словарь с терминами и безупречно проходить все доступные в сети тренажеры с тестами или записаться на курс подготовки, где все систематизировано?

Специально для вас мы подготовили бесплатный вебинар, на котором сертифицированные специалисты Наталья Руколь и Анна Палей ответят на все эти вопросы.

НА ВЕБИНАРЕ ВЫ УЗНАЕТЕ:

• Зачем нужна и какие возможности открывает сертификация ISTQB FL
• Что изменилось в программе сертификации 2018 года (Syllabus 2018)
• Как подготовиться к сдаче сертификационного экзамена ISTQB FL
• Что выбрать: самостоятельную подготовку или с помощью специальных курсов?
• Об особенностях курса «Комплексная система подготовки (КСП) ISTQB FL» обновленного в соответствии с новой версий программы сертификации
• Получите ответы на вопросы, связанные со сдачей экзамена ISTQB FL

Вебинар пройдет 19 ноября в 16-00 по Московскому времени.

Зарегистрироваться на вебинар можно по ссылке - http://edu.pointschool.ru/

Автор: Виталий Котов

Решил написать свое мнение касательно того, заменит ли автоматизация тестирования, собственно, тестировщиков. Прежде всего потому, что довольно часто слышу подобное мнение среди Junior QA, кто только делает свои первые шаги в тестировании и уже боится, что чего-то не успел.

Справедливости ради, подобное мнение бытует и среди ребят постарше. Довольно часто считается, что автоматизация — чуть ли не единственный путь развития ручного тестировщика. Обо всем этом и многом другом под катом.




Небольшое уточнение, прежде чем мы начнем. Вся речь далее будет идти о функциональных автотестах. Это именно UI-тесты, которые не стоит в данном контексте путать с unit-тестами. Последние всегда писались и должны писаться разработчиками, а где это не так — это предмет уже совсем другого обсуждения.

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

Несмотря на непривлекательное название, тестирование CRUD очень важно! CRUD – это аббревиатура для Create, Read, Update, Delete (создание, чтение, обновление, удаление). Как знает любой тестировщик, большая часть нашего тестирования включает эти операции. Сегодня мы обсудим наилучшие способы тестирования создания и чтения.

Самое важное, что нужно знать, тестируя CRUD: недостаточно полагаться на то, что вы видите в интерфейсе, чтобы убедиться, что значение поля было создано или изменено. Это связано с тем, что интерфейс может кэшировать значения для более эффективной загрузки в браузере. Для того, чтобы абсолютно точно удостовериться, что значение изменилось, нужно проверить базу данных, где оно хранится. В результате вы убеждаетесь, что значение задано в двух местах – в интерфейсе и в базе данных. Если вы занимаетесь тестированием API, то можете подтвердить это в трех местах, но тестирование API мы сейчас затрагивать не будем.