Автор: Ричард Брэдшоу (Richard Bradshaw) и Сара Дири (Sarah Deery)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Ольга Назина

Знакомая картинка? А вы ведь постоянно сталкиваетесь с этой архитектурой — когда покупаете билет в кино онлайн, бронируете путевку на море или записываетесь к врачу.

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

Об этом я и расскажу в статье. Объясню на пальцах, с примерами и забавными картинками =) Если вы больше любите видео-формат, можно посмотреть мой ролик на youtube на ту же тему.

Автор: Рози Шерри (Rosie Sherry)
Оригинал статьи
Перевод: Ольга Алифанова

Вам когда-нибудь ставили задачу распланировать ваше тестирование? Чувствовали ли вы, что что-то упустили? И вследствие этого беспокоились ли, что ПО начнет падать, и все начнут обвинять вас?

Использование этого чеклиста по планированию тестирования поможет вам справиться с волнением.

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

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

Автор

Предисловие

Модульное тестирование (unit testing) применяется повсеместно. Кажется, уже никто без него не обходится, все пишут тесты, а их отсутствие в сколь-нибудь серьёзном проекте вызывает, как минимум, непонимание. Однако, многие воспринимают тестирование как некий ритуал, совершаемый для того, чтобы не разгневать "бога программирования". Мол, так надо. Почему? Потому что.

Буду говорить страшные вещи.

Не важно, что брать за единицу тестирования. Не важно, как сгруппированы тесты. Не важно, пишутся ли они до кода или после. TDD или не TDD? Всё равно. Доля покрытия? Наплевать. В конце концов, тестов может совсем не быть. Всё это совершенно не важно. Важно, чтобы выполнялись требования, предъявляемые к ПО.

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

Постойте, причём же тут наука с математикой?

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

Ссылка на pdf-документ

URL запроса

https://www.happypath.com/contact/2?phone

https:// = протокол

www.happypath.com/ = домен

contact/ = путь

2 = параметр пути

?phone = параметр запроса.

Автор: Жданов Илья Владимирович, ЛАНИТ, Тест-менеджер (15 лет в IT, за первые 10 лет прошел путь от эникейщика до руководителя направления системных аналитиков, последние 5 лет занимаюсь созданием команд и практик по тестированию на проектах от 5 до 60 QA)

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

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

В этой статье я постарался:

• осветить «детские болячки» тест-менеджмента, стремящегося автоматизировать все, что не приколочено,
• пояснить, какую пользу может нанести бюджету проекта автоматизация тестирования без детального анализа ее скоупа и должной подготовки,
• составить Roadmap для подготовки к автоматизации проекта.

Источник 

Автор: Рикард Эдгрен (Rikard Edgren)
Оригинал
Перевод: Ольга Алифанова

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

Автор: Алтунин Алексей
Оригинал статьи
Перевод: Алтунин Алексей

Часть 1

5. Облачные платформы

Краткое описание технологии

В этом разделе мы поговорим о популярном тренде, который называется ‘публичные облака’. Несмотря на огромную пользу, которую дают описанные выше технологии виртуализации и контейнеризации, нам все еще необходимы вычислительные ресурсы. Компании приобретают дорогие сервера или арендуют дата-центры, но в таком случае необходимо сделать расчеты (иногда нереалистичные) того, как много ресурсов нам понадобится, будем ли мы их использовать 24/7 и для каких целей. Например, для production требуется работающий круглосуточно сервер, но нужны ли нам аналогичные ресурсы для тестирования в нерабочее время? Это также зависит от типа выполняемого тестирования. Примером могут быть нагрузочные/стрессовые тесты, которые мы планируем прогонять в нерабочие часы, чтобы получить результаты на следующий день. Но, определенно, круглосуточная доступность серверов не требуется для end-to-end авто-тестов и в особенности для сред ручного тестирования. Для таких ситуаций было бы хорошо получать столько ресурсов, сколько необходимо по требованию, использовать их и прекращать платить, когда они больше не нужны. Более того, было бы прекрасно получать их моментально, сделав несколько кликов мышкой или запустив пару скриптов. Для этого и используются публичные облака. Давайте посмотрим на определение: “The public cloud is defined as computing services offered by third-party providers over the public Internet, making them available to anyone who wants to use or purchase them. They may be free or sold on-demand, allowing customers to pay only per usage for the CPU cycles, storage, or bandwidth they consume”.