Home

Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/why-it-is-important-to-start-testing-as-early-as-possible/

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

Эксперты выделяют несколько этапов развития продукта:

• идея;
• стратегия;
• требования;
• дизайн;
• прототип и верстка;
• разработка и тестирование;
• поддержка.

Как правило, процесс тестирования начинается на предпоследнем этапе. Но правильно ли это? И в какой момент тестирование становится актуальной проблемой?

Автор: Усманова Илюся, QA в группе компаний FIX

Оригинальная публикация: https://habrahabr.ru/post/330776/

Сегодня проблема ручного выполнения процессов тестирования является одной из актуальных из-за обнаружения многих ошибок на этапе внедрения.

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

В начале описывается сам процесс автоматизации со схемами и диаграммами. После описания процесса рассмотрены инструменты, которые предназначены для автоматизации тестирования OpenStack.

Построение процесса автоматизации тестирования OpenStack

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

Автор: Катрина Клоки (Katrina Clokie)

Оригинал статьи: http://katrinatester.blogspot.ru/2017/08/encouraging-testers-to-share-testing.html

Перевод: Ольга Алифанова

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

Если тестировщики – единственные, кто тестирует, то это душит команду. Это происходит потому, что разработчики и люди бизнеса, участвующие в процессе разработки, не хотят заниматься тестированием. Это может также происходить потому, что тестировщик не хочет, чтобы кто-то еще тестировал. Я сталкивалась с обоими вариантами.

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

Мы выбрали доклады с конференции, посвященные автоматизации тестирования мобильных приложений.

Супер быстрая автоматизация тестирования на iOS, Виктор Короневич, Badoo, London

Напоминаем, что уже открыта регистрация на следующую конференцию для специалистов в области качества программного обеспечения- SQA Days-22, Санкт-Петербург, ноябрь.

Автор: Баз Дийкстра (Bas Dijkstra)

Оригинал статьи: https://techbeacon.com/how-tech-giants-test-software-theres-no-one-way-qa

Перевод: Ольга Алифанова

Команды и организации, стремящиеся наладить (или улучшить) усилия по тестированию своих продуктов, могут извлечь полезные уроки, наблюдая, как тестируют "взрослые" компании. Логично предположить, что такие корпорации, как Google, Microsoft, Amazon не смогли бы добиться успеха, не обращая пристального внимания на качество своих продуктов.

Однако если посмотреть на то, как эти компании подходят к обеспечению качества, можно отметить, что "серебряной пули" не существует. Вот как тестируют пять наиболее известных компаний:

Google: в поисках лучших практик

Как организует свое тестирование компания, создавшая самый популярный в мире поисковик? Это сильно зависит от команды и продукта. К примеру, команда, работающая над поисковиком, поддерживает крупный и сложный фреймворк тестирования. Так как поиск – основной бизнес Google, команда стремится убедиться, что продукт настолько качественный, насколько это вообще возможно, и что никто ничего не испортил.

Чтобы этого добиться, Google использует четырехступенчатый процесс внедрения изменений в поисковик:

1. Тестирование внутренними силами (сотрудники Google).
2. Тестирование на crowdtesting-платформе.
3. Использование продукта сотрудниками Google в повседневной жизни.
4. Бета-тестирование: выпуск продукта для использования небольшой группой конечных пользователей.

Автор: Юлия Багрий, ведущий специалист по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/api-usability-testing/

Юзабилити-тестирование… API?! Да, именно так. В своей предыдущей статье я говорила, что юзабилити является одной из ключевых характеристик хорошего API. Пришло время рассмотреть ряд важных вопросов: зачем, как и, главное, с помощью каких методов можно оценить эту характеристику для API.

Когда говорят о графических пользовательских интерфейсах (GUI), уже ни у кого не вызывает сомнения то, что юзабилити тестировать необходимо. Но давайте вспомним, что согласно международному стандарту ISO 9241-11 юзабилити – это степень, с которой продукт может быть использован определенными пользователями при определённом контексте использования для достижения определённых целей с должной эффективностью, продуктивностью и удовлетворенностью. Проще говоря, это та степень удобства использования продукта, с которой пользователь может без затруднений применить продукт и достичь своей цели. Как видим, в определении нет ни слова о менюшках, цвете кнопочек и размере шрифта. Мы можем оценить юзабилити для любого продукта, будь то мобильное приложение, утюг, или, в нашем случае, API.

В тестировании юзабилити API используются методы, относящиеся к техникам, разработанным в рамках направления под названием HCI (Human-Computer Interaction, человеко-компьютерное взаимодействие); они же применяются и для оценки GUI. В данной статье я расскажу об основных и самых распространенных техниках. В целом, их можно разделить на два типа: аналитические и эмпирические (экспериментальные).

Оригинальная публикация: https://habrahabr.ru/company/ascon/blog/327582/

Недавно вышла новая версия САПР КОМПАС-3D v17, но вплоть до самого финального релиза в систему еще вносились изменения, тестирование продолжалось. О том, какие испытания проходил новый КОМПАС-3D, прежде чем попасть к пользователям, рассказывает команда КОМПАС-3D из Центра разработки АСКОН в Коломне.

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

«Долина Дали» автор Дмитрий Верба

При проверке такой сложной системы, как КОМПАС-3D, без ручного тестирования обойтись нельзя. Все тестировщики, выполняющие ручное тестирование, имеют опыт конструкторской работы на производстве и не понаслышке знают, как и зачем пользователи применяют ту или иную функциональность КОМПАС-3D.

Автор: Дейв Вестервельд (Dave Westerveld)

Оригинал статьи: https://offbeattesting.com/2017/08/17/getting-fast-and-consistent-automation/

Перевод: Ольга Алифанова

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

Начнем со скорости. Что мы можем сделать, чтобы автоматизация ускоряла вам работу?

Принцип скорости 1 – избегайте падений

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

Что же делать, если у вас на руках чересчур часто падающий набор тестов?

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