Home

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

Блог компании «Аплана» — http://aplana.ru/infocenter/corpblog

Немного о нас:

«Аплана» — лидирующий поставщик услуг тестирования и обеспечения качества информационных систем, а также управления жизненным циклом приложений. Компания на рынке уже 17 лет, в штате более 700 специалистов, общее количество проектов превысило 1500.

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

Публикуем одну из первых статей блога.

Автор: Марсель Гелен (Marcel Gehlen)

Оригинал статьи

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

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

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

Это настоящая кроличья нора – статьи ведут на другие статьи, а те, в свою очередь, на еще большее количество источников. Приятного чтения!

Оригинальная публикация: http://habr.com/post/358142/

Оригинал. Перевод разбавлен размышлениями и дополнениями автора из своего опыта

О чём это всё

Будучи инженером по тестированию, вы, вероятно, слышали о таких видах тестирования как «дымовое» (smoke), «санитарное тестирование» (sanity), «ре-тест» и регрессионное тестирование. Вполне возможно, многие из этих видов используются вами на ежедневной основе.

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

Для новичков в тестировании (и даже опытных тестировщиков) разделение этих понятий может быть затруднительно. И в самом деле, как отличить где начинается санити-тестирование и заканчивается smoke? Насколько сильно нам надо ограничить проверку части функциональности системы или её компонентов, чтобы назвать это «дымовым» тестированием? Является ли ввод логина/пароля в пользовательскую форму входа на сайт дымовым тестом, или сам факт её появления на странице сайта уже является пройденным тестом?

Строго говоря, вы всё равно сможете проводить тестирование, даже при том что не сможете точно сказать, в чём же разница. Можно даже не задумываться о разграничении, каким именно видом тестирования вы сейчас заняты. Но всё же, чтобы расти над собой в профессиональном смысле, нужно знать что вы делаете, зачем, и насколько правильно вы это делаете.

Автор: Аарон Ходдер (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": многие пользователи вынуждены пользоваться браузером, предоставленным им на работе, в школе, или выбранным из-за определенных характеристик другого ПО. Все они заслуживают того, чтобы их нужды принимались во внимание вне зависимости от того, насколько хорошим или плохим вы считаете выбранный ими браузер.