Home

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: http://testerkiwi.blogspot.ru/2016/02/lean-testing-in-theory-and-practice.html#more

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

Есть множество определений тестирования ПО, и множество взглядов на то, как должно выглядеть ответственное тестирование в нашей области. Ваш взгляд на роль тестировщика влияет на то, какие практики и артефакты вы считаете ценными.

Мое любимое определение тестирования дал Кем Кейнер: «Тестирование – это эмпирическое исследование, которое проводится с целью предоставить заинтересованным лицам информацию о продукте или сервисе, который тестировался».

В целом я рассматриваю тестирование, как часть бизнеса по сбору информации и ее передаче.

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

«Ценность любой практики зависит от контекста» и «внутри контекста есть хорошие практики, но лучших не существует». Любая проблема тестирования уникальна. Наш подход к этой проблеме, следовательно, тоже уникален. Выяснить как можно больше и передать другим свое понимание проблемы жизненно необходимо для эффективного тестирования. Чем гибче инструмент или процесс, тем выше количество контекстов, в котором я могу его использовать.

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

“Хорошими манерами обладает тот,
кто наименьшее количество людей
ставит в неловкое положение.”
Дж. Свифт

Привет, коллеги! Сегодня я бы хотел поговорить о Unit-тестировании и некоторых “правилах” при их написании. Конечно, они неформальные и не обязательны к выполнению, но при их соблюдении всем будет приятно и легко читать и поддерживать тесты, которые вы написали. Мы в Wrike видели достаточно Unit-тестов, чтобы понять основные проблемы, которые возникают при их написании и поддержке, и сформулировать несколько правил для их предотвращения.

1. Unit-тесты нужно писать. Да, как бы банально это не звучало, но писать их нужно. Каждый кусок логики приложения должен быть протестирован, чтобы в будущем избежать проблем. А они могут возникнуть при изменении логики, рефакторинге, или даже при обновлении версии зависимых библиотек. И чем больше покрытие кода тестами, тем быстрее проблема будет обнаружена и исправлена.

2. Это правило очень актуально для тех, кого заставляют покрывать код тестами, и оно звучит так: Тесты — это тоже код, и относиться к нему нужно как к рабочему коду. Это касается и нейминга переменных, и форматирования кода внутри теста, и, особенно, названий тестовых методов. Конечно, написание адекватного имени переменной занимает немного больше времени и ударов по клавиатуре, чем “int i = 0;”, но это повышает читабельность тестов и легкость их поддержки.

Угадайте, что проверяет упавший тестовый метод?)

Автор: Аарон Ходдер (Aaron Hodder)

Оригинал статьи: https://testerkiwi.blogspot.ru/2011/04/building-exploratory-test-plan-redux.html

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

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

http://en.wikipedia.org/wiki/Map

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

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

Автор: Иван Бондарь, ведущий тестировщик компании "Лаборатория качества"

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

Введение

Эмоции управляют людьми, а управление эмоциями людей – мечта каждого маркетолога. Как правило, все нововведения основаны на субъективном «мне кажется, что так будет красивее/удобнее». Гораздо реже под конкретное изменение проводится анализ мнения клиентов. Надеяться на субъективную оценку маркетолога можно, но рискованно. Собирать фокус-группу – затратно. Просто ввести изменение и посмотреть, что же произойдет по прошествии определенного времени, – не научно.

Автор: Виктория Кузнецова (Viktoria Kuznetcova)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2014-February.pdf#page=25

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

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

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

Автор: Ведущий инженер по тестированию "Лаборатории качества" Ольга Панина

Оригинальная публикация: http://quality-lab.ru/key-principles-of-gray-box-testing/

Каждый начинающий тестировщик слышал о методах тестирования black-box, white-box и gray-box (методы трех «ящиков»). В сети можно найти много информации о «черном» и «белом ящиках», но статьи о методе «серого ящика» встречаются редко. Такая ситуация кажется мне не совсем справедливой, ведь многие из нас используют в работе именно эту стратегию. Я попытаюсь немного исправить сложившееся положение, подробно рассмотрев плюсы и минусы «серого ящика» по сравнению с двумя другими методами и выяснив, в каких случаях его применение будет наиболее эффективным. Тестирование «серого ящика» сочетает в себе элементы black-box и white-box тестирования, а потому я начну свой рассказ с краткой характеристики каждого из методов. 

Оригинал статьи: https://dojo.ministryoftesting.com/lessons/getting-started-with-cross-browser-testing

Автор: Алекс Лэнгшалл (Alex Langshall)

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

Вы, как тестировщик, получили на тестирование юзер-стори, и ответственный за нее разработчик попросил вас провести кросс-браузерное тестирование. Что это значит? Зачем тестировать юзер-стори в разных браузерах? Какие браузеры выбрать для тестирования? На что обращать внимание в процессе?

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

Определение кросс-браузерного тестирования

Кросс-браузерное тестирование – это тестирование фичи в различных релевантных приложению браузерах. Это важная часть тестирования: несмотря на существование веб-стандартов, разные браузеры внедряют их различным образом. На глубоком уровне разные элементы страницы ведут себя по-разному в разных браузерах. Поведение фичи в Safari, к примеру, может сильно отличаться от ее работы в Chrome.

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

Кросс-браузерное тестирование удостоверяет, что пользовательский опыт будет единым вне зависимости от браузера. Неважно, новый это код или уже существующая фича: приложение должно единообразно работать в разных браузерах. Оставим за кадром споры об "ужасном Internet Explorer": многие пользователи вынуждены пользоваться браузером, предоставленным им на работе, в школе, или выбранным из-за определенных характеристик другого ПО. Все они заслуживают того, чтобы их нужды принимались во внимание вне зависимости от того, насколько хорошим или плохим вы считаете выбранный ими браузер.

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

Текст предоставлен JUG.RU Group – организаторами конференции по тестированию Гейзенбаг. Ближайшая конференция Гейзенбаг 2017 Moscow состоится в декабре в Москве. Подробности: https://heisenbug-moscow.ru/

При тестировании распределенных систем нефункциональные требования выходят на первое место, а для обнаружения сложных дефектов приходится применять специальные методы. Мы уже говорили о них с Андреем Сатариным в предыдущем интервью и сегодня попытаемся развить эту тему.

Андрей Сатарин занимается тестированием распределенных систем в Яндексе. Принимал участие в совершенно разных проектах: тестировал игру в Mail.ru, систему облачного детектирования в Лаборатории Касперского, а также систему расчета валютных цен в Deutsche Bank.

— Отказоустойчивость — одно из важнейших нефункциональных требований к распределенным системам. Как проводится тестирование отказоустойчивости? 

Андрей Сатарин: Сбои можно эмулировать в тестовой среде, так работает известный инструмент Jepsen, созданный Кайлом Кингсбери (Kyle Kingsbury). Второй подход предполагает внедрение сбоев в продуктивном окружении и обычно ассоциируется с Chaos Monkey компании Netflix, из которого выросло целое движение — хаос-инжиниринг. Он избавляет нас от проблем с повторением продуктовой среды и дает высокую уверенность в работоспособности системы, но более опасен и требует определенной зрелости продукта. 

Есть и третий подход, позволяющий проверить работоспособность алгоритмов еще до написания кода с помощью специальных инструментов, таких, например, как TLA+. Два наиболее известных примера его использования: разработка Amazon Web Services и Azure Cosmos DB.

Оригинальная публикация: https://vc.ru/p/qa-test-game-services

Советы от QA-менеджера Crytek по тестированию игр, которые требуют регулярного обновления.

Чем дольше живёт проект — тем критичнее случайные баги. Внезапно появившиеся ошибки могут оттолкнуть значительную часть аудитории. QA-менеджер Crytek Евгений Скачков поделился на конференции Games Gathering 2016 опытом контроля качества проекта Warface, разработанного киевским филиалом компании.

Издание DTF опубликовало расшифровку выступления.

Про игру

Warface — онлайн free-to-play-шутер. Практически пять лет игра находится на стадии оперирования и больше восьми лет — в разработке. Это самый большой free-to-play-шутер на территории СНГ. Три года назад мы поставили официально зарегистрированный рекорд Гиннесса — 145 тысяч пользователей в онлайне на одном сервере.

Если посчитать по всем территориям, PCU (peak concurrent users) больше — около 200 тысяч человек. Ежедневно в игру заходят около 700 тысяч уникальных пользователей. Каждый год мы выдаём около 12 крупных обновлений.

Как происходит разработка обычного, «коробочного» продукта? Программисты и дизайнеры что-то создают, придумывают креативы, прототипируют и в какой-то момент решают, что игра готова. Её нужно протестировать. Что-то они проверяют своими силами, но этого недостаточно. Собираются QA-команды, и начинается «zerg rush».

Автор: Николай Матюшенков

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

Вы встречались с ошибками, которые возникают время от времени в продакшне, но никак не воспроизводятся локально? Бывает, изучаешь такой баг и вдруг понимаешь, что он проявляется только при одновременном параллельном выполнении скриптов. Изучив код, понимаешь как это исправить, чтобы такого больше не повторялось. Но на такое исправление хорошо бы написать тест…

В статье я расскажу о своем подходе к тестированию таких ситуаций. А также приведу несколько наглядных (и наверное даже классических) примеров багов, которые удобно протестировать с помощью этого подхода. Все примеры багов живые — то, что встречается в работе.

Забегая вперед сразу скажу, что в конце статьи будет ссылка на github, куда я выложил готовое решение, позволяющее тестировать параллельные консольные процессы легко и просто.

Пример номер один. Параллельное добавление одного и того же

Задача. У нас есть приложение с базой данных (PostgreSQL) и нам надо наладить импорт данных из сторонней системы. Допустим, есть таблица account (id, name) и связи идентификаторов с внешней системой в таблице account_import (id, external_id). Давайте набросаем простой механизм приема сообщений.

При приеме сообщения будем сперва проверять — есть ли такие записи у нас в базе. Если есть, то будем обновлять имеющиеся. Если нет, то будем добавлять в базу.