Что пишут в блогах

Подписаться

Онлайн-тренинги

Конференции

Что пишут в блогах (EN)

Разделы портала

Про инструменты

Лучшие вакансии

.
Другие виды тестирования
В чём разница Smoke, Sanity, Regression, Re-test и как их различать?
30.07.2018 11:43

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

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

О чём это всё

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

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

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

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

Подробнее...
 
Lean-тестирование: теория и практика
27.02.2018 00:00

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

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

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

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

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

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

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

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

Подробнее...
 
7 правил хорошего тона при написании Unit-тестов
13.02.2018 00:00

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

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

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

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

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

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

Подробнее...
 
Создание плана исследовательского тестирования: картография ПО
06.02.2018 00:00

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

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

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

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

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

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

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

Подробнее...
 
A/B тестирование
05.02.2018 00:00

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

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

Введение

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

Так как же все-таки определить пользу изменений без потери клиентов и времени? Этот вопрос решает A/B тестирование. Его использование ведет к увеличению трафика клиентов и степени конверсии сайта, к росту количества продаж, кликов и лайков.
Подробнее...
 
Исследуя исследовательский подход к тестированию
18.12.2017 10:53

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

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

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

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

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

Подробнее...
 
Особенности тестирования «серого ящика»
17.07.2017 16:22

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

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

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


Подробнее...
 
Как начать кросс-браузерное тестирование
10.07.2017 09:48

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

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

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

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

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

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

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

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

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

Подробнее...
 
Андрей Сатарин, Яндекс: "Самая главная ошибка — непонимание системы"
20.06.2017 09:38

Оригинальная публикация: 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.

Подробнее...
 
Контроль качества в играх с сервисной моделью
02.06.2017 09:08

Оригинальная публикация: 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».

Подробнее...
 



Страница 1 из 2