Home

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

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

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

И в целом, как командам перестать так сильно полагаться на медленные и дорогие E2E-тесты?

Примечание: я не говорю, что вам нужно избавиться от всех E2E-тестов, разбив их на небольшие кусочки – но для множества тестов это полезное умственное упражнение. Спасибо Юстасу Лаужадису за дискуссию по этому поводу.

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

Автор: Ekaterina Noga, оригинальная публикация

Работая QA часто слышала в голове голос «а точно ли все проверила?» и иногда он бывает полезен, но если не научиться голос использовать и затыкать, то он начинает вредить. Ниже я расскажу об этом тревожном таракане и о том, как он проявляется.

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

Автор: Эми Стюарт (Amy Stuart)
Оригинал статьи
Перевод: Ольга Алифанова.

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

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

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

Уверен, все вы слышали о «глобальном крахе IT» в середине июля. Это затронуло, прямо или косвенно, большинство из нас. Я не мог воспользоваться банкоматом, рейс моей жены задержали на несколько часов; это были мелкие неудобства по сравнению с тем, что ощутили остальные. Проблему CrowdStrike нескоро позабудут.

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

Автор оригинала: Matt Proud

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

В качестве приближения такая модель вполне надёжна, но она начинает сбоить по мере того, как проявляется всё больше нюансов, а именно: что мы тестируем, и как результаты теста выводятся пользователю:

• Бывают медленные модульные тесты.

• Бывают быстрые функциональные тесты

Сколько я работаю в Google, столько там применяется концепция размер теста (развёрнутое объяснение). Размер теста интересен потому, что по типу теста можно лишь отчасти определить, во что этот тест нам обойдётся. Нам же интереснее, чтобы по размеру тестов можно было приобретать качественное представление о различных свойствах, и уже на основе этой информации корректировать размер теста. Иными словами, это как раз тот случай, когда размер имеет значение. Ниже перечислю те компоненты системы, качественные аспекты которых будут интересовать нас в этой статье:

• Доступ к сети;

• База данных;

• Доступ к файловой системе;

• Многопоточность.

Автор: Ekaterina Egorova

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

Прогресс, как всегда, не остановить, но что сейчас представляют собой интеграции с AI и насколько это рабочие решения?

Всем привет! На связи снова Юрий Шабалин, генеральный директор «Стингрей Технолоджиз». В предыдущей статье я рассказывал о влиянии Профиля защиты ЦБ РФ на мобильные приложения. В продолжение темы российского законодательства сегодня разберем, под какие еще требования попадают приложения, насколько законно хранить персональные данные на смартфоне в открытом виде и попадает ли мобильное ПО под действие Федерального закона "О персональных данных" (152-ФЗ) и подзаконных актов по теме защиты ПДн? Постараюсь разъяснить всё максимально понятно.

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

• Что такое персональные данные (ПДн)?

• Что такое обработка ПДн?

• Как и где осуществляется обработка? 

• И, наконец, каково участие мобильных приложений в этом процессе?

Затем приведем пару примеров из практики и подведем итоги. Ну и, раз мы говорим про законодательство, отдельно поговорим об ответственности компаний по защите цифровых продуктов.

Поехали!

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

«Языковые модели» («Language models») обычно интерпретируются как сложное существительное – нечто, что моделирует язык. Что, если определять models как глагол? Тогда это простое изъявительное предложение с предполагаемым объектом: язык моделирует наше мышление, или же язык моделирует мир.

Как и с любой моделью, замена или изменение одного из ее элементов может натолкнуть нас на что-то интересное, что поможет усовершенствовать ответы на два главных вопроса, которые мы задаем, тестируя. Первый – это вопрос, который мы постоянно, экспансивно и неявно задаем сами себе как тестировщикам: «Есть ли тут проблема?» Второй мы задаем клиентам – время от времени, конкретно и явно, и он касается проблем и продукта: «Вам как, нормально?»

Вот вам эвристика: когда вы видите «ИИ» (или «ИИ-модель», или «большую языковую модель», или «генеративный ИИ»), замените это словосочетание на «ПО» и оцените, насколько значимы будут перемены в вашем восприятии ценности и риска.

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

Всем привет! Меня зовут Фефилов Александр, я работаю в QA с 2017 года. По большей части это были компании, которые занимались аутсорсингом, но затем я присоединился к SM Lab.

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

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

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

• что делать, если ваш заказчик живёт в парадигме «Я плачу деньги, а ты просто делаешь всё, что я говорю»

• как решать процессные задачи

• как находить продуктовые проблемы

• кто такой QA-эксперт и как им стать

• полезная методика, которая может пригодиться вам в работе.

Итак, начнём по порядку.