Евгений Гусинец, Middle+ QA Engineer, автор телеграмм канала о тестировании QA❤️Life https://t.me/QA4Life

На связи Евгений Гусинец — Middle+ QA Engineer из Минска, ментор и автор ТГ‑канала QA❤️4Life. Добро пожаловать в мою небольшую подборку «тестировочной рутины» и советов, как с ней справляться! Наверняка, многие из вас узнают себя в этих ситуациях. А может быть, вы даже сможете поделиться своими «любимыми» повторяющимися задачами в комментариях? В любом случае, надеюсь, этот пост поднимет вам настроение и, возможно, даст пару полезных идей.

Ох, рутина… Это такое знакомое слово каждому, кто хоть раз окунался в мир IT, и тестировщики тут, поверьте, не исключение. Казалось бы, каждый день что‑то новенькое, баги выискиваем, приложения ломаем по‑хорошему... Но если копнуть глубже, у каждого тестировщика найдется свой «день сурка» из повторяющихся задач. Давайте вместе посмеемся (или погрустим?) над этими моментами, разбавив это дело мудростью из книжек, которые не раз помогали мне и моей команде.

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

Автор: компания Simbirsoft

Вот уже пару лет чат-боты, основанные на больших языковых моделях, «гремят» на весь интернет. Поражают своими возможностями и делают то, о чем около 15 лет назад можно было услышать только в фантастических сюжетах. При этом важно что, сейчас Large Language Model (LLM) дошли до широкого круга потребителей и все могут их увидеть и протестировать. В связи с этим возникают дискуссии, размышления, статьи-прогнозы на тему того, как искусственный интеллект (ИИ) изменит рынок труда, кого заменят, сократят, а кто останется и т.д. Профессия QA и процессы тестирования тоже не остались без подобных рассуждений. 

Меня зовут Андрей, я QA-специалист в компании SimbirSoft. В этой статье хочу поделиться опытом и впечатлениями моих коллег в использовании ИИ для рабочих задач.

Автор: Гуськова Мария (работает в стриминговом сервисе, ведет свой телеграмм канал @mashaqasha и на досуге пишет статьи на Хабре), https://t.me/mashaqasha

Привет! Я — Маша, которая заваривает qaшу (и иногда крепкий кофе, когда глаза уже отказываются фокусироваться на экране).

Сегодня хочу поговорить о проблеме, с которой сталкивался, наверное, каждый тестировщик (и не только). В один «прекрасный» день ты садишься проверять фичу или делать регресс, а баги просто перестают быть видны. Ты кликаешь, прогоняешь сценарии, но будто слепнешь — всё кажется рабочим. А потом оказывается, что пропустил очевидный косяк, и по цепочке начинается: чувство вины → стресс → ещё большая усталость → ещё больше ошибок.

Знакомо? Тогда давайте разберёмся, как выбраться из этой ямы, пока она не превратилась в профессиональное выгорание.

Автор: Джеймс Уэдли (James Wadley)
Оригинал статьи
Перевод: Ольга Алифанова

Ловкость рук и никакого обмана: что такое Гейзенбаг?

Сталкивались ли вы с дефектом, который, казалось бы, отрицает логику и увиливает от всех попыток его воспроизвести?

Если ваш ответ «Да», то уверяю, вы не одиноки.

Такие дефекты часто всплывают при вроде бы случайном наборе условий – то есть у нас нет надежного способа выявить необходимые для воспроизведения шаги. Зачастую единственная информация, которой мы располагаем – это невнятное описание вроде «Я столкнулся с этим, следуя определенному процессу, но с тех пор проблем не было».

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

Автор: Фернандо Тейшера (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)
Оригинал статьи
Перевод: Ольга Алифанова

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