Автор: Фернандо Тейшера (Fernando Teixeira)
Оригинал статьи
Перевод: Ольга Алифанова

Что такое простота разработки?

Простота разработки, также известная как опыт разработчика или DX (developer experience) – тема, быстро набирающая популярность в области ИТ. Однако появилась она не вчера. Первые упоминания о ней относятся к ранним 2010-м, и в последнее время в сообществах разработчиков ей уделяется все больше внимания.

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

Когда мы говорим о «разработчиках», это включает любого вовлеченного в процесс разработки инженера, включая инженеров по обеспечению качества (QA) и тестировщиков, работающих над качеством ПО, а также любую иную техническую роль в тех же процессах.

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

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

Меня зовут Алексей Борискин, и на два дня я стал курьером.

Я системный аналитик в компании «Автомакон», где занимаюсь разработкой мобильного приложения «ВкусВилл:Курьер». Но почему я решил на время сменить профессию? Мне нужно было понять, как работает наш продукт в реальной жизни — не через отчёты или звонки с курьерами, а своими руками, ногами и велосипедом.

Это история о том, как я погрузился в наш продукт, нашел баги, замерзал, боролся с ветром, но в итоге спас сотни заказов. Я применил философию гемба, чтобы увидеть мир глазами тех, для кого мы создаём свои решения.

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Эта статья написана в ответ на вопрос Джулии Торрехон «Какие тесты должны прогоняться на каждом шаге пайплайна в ходе непрерывного тестирования?». Спасибо, Джулия, за вдохновение для этой статьи и за твою любовь к качеству!

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

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

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Ранее я упоминала, что специально использую UI, дабы обозначить, что он должен находиться на вершине тест-пирамиды, в то время как в других случаях вершина называется E2E. Чувствую, надо подробнее это объяснить.

UI – это пользовательский интерфейс. UI-тестирование относится к тестированию, выполняемому через UI.

E2E – это end-to-end тестирование. Это тесты, которые выполняются от входной точки в приложения до выхода из него.

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

Однако они отличаются важными нюансами.

Автор: Ноэми Феррера (Noemi Ferrera)
Оригинал статьи
Перевод: Ольга Алифанова

Недавно я разговаривала с коллективом и предположила, что тестирование – не всегда решение вопроса. Они были озадачены.

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

У тестирования и автоматизации два основных принципа, и если вы меня знаете, то, возможно, уже про них слышали:

1. Тестирование – это про верный баланс.

2. Автоматизация – это про экономию времени.

Оба связаны с издержками: в первом случае, если тестировать дороже, чем продолжать без тестирования, то лучше пропустить этот тест (или тесты).

Во втором случае, если автоматизация займет больше времени, чем общее время на ручное тестирование, автоматизировать не нужно.

Принципы, возможно, звучат очевидно, но в реальности не так-то просто принять решение не тестировать или не автоматизировать. Это контринтуитивно, и в голове звучат панические «А что, если».

Автор: Кассандра Ланг (Cassandra H. Leung)
Оригинал статьи
Перевод: Ольга Алифанова

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

Оригинальная публикация

Привет! Я Екатерина Васильева, инженер-тестировщик ГК «Солар». В нашей работе есть извечный вопрос, как сделать тестирование быстрым, качественным и эффективным. И знаете, что помогает? Правильная организация процесса. В «Соларе», например, мы активно используем концепции DoR (Definition of Ready) и DoD (Definition of Done) при тестировании продуктов. Эти критерии, хоть и встречаются чаще в разработке, оказались невероятно полезны и для нас, тестировщиков. Они помогают четко понимать, когда задача готова к тестированию, а когда уже можно выдохнуть и сказать: «Готово!». В итоге — никаких срывов сроков и релизы день в день. В этой статье я расскажу на примере Solar webProxy, как DoD и DoR помогают нам повысить качество тестирования и с какими трудностями мы столкнулись, внедряя эти критерии.

Меня зовут Юрий Заковряшин. Я занимаюсь разработкой ПО более 40 лет, преподаю курсы по технологиям разработки программного обеспечения и программированию на платформе Java в СПбПУ Петра Великого.

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

Привет, меня зовут Нина Полторакова, я ведущий тестировщик в ГК Юзтех. 

На данный момент мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни.

В этой статье я хочу поделиться несколькими приёмами, как не сойти с ума, тестируя страховые продукты. 

Автор: Пол Гриззаффи (Paul Grizzaffi)
Оригинал статьи
Перевод: Ольга Алифанова

Ни шагу дальше! Тот, кто хочет пересечь Мост Смерти, должен ответить мне на три вопроса, и если ответит неправильно, Мост оправдает своё название.

Большинство из нас, ботаников (и не ботаников) видели фильм «Монти Пайтон и Священный Грааль». Сцена на Мосту Смерти чаще всего цитируется и парафразируется. Концепция трех вопросов (не путать с тремя раковинами) заставила меня задуматься о тест-автоматизации.

Мой хороший друг и коллега Джо Колантонио, создатель Test Guilds и соответствующих конференций, запустил новую рассылку «Автоматизированы ли вы?» - название вдохновлено альбомом Джимми Хендрикса «Опытны ли вы?» Это напомнило мне, что я размышлял о бинарной природе автоматизации. Я уже писал о том, автоматизировано что-то или нет, но рассылка Джо заставила меня задуматься серьезнее.