Home

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

Что делает тестировщика великим?

Недавно я видела ряд дискуссий, побудивших меня задуматься:

• Что делают тестировщики?
• Чем ISTQB-тестировщик отличается от «гибкого» или «современного»?
• Отвечает ли тестировщик за определение влияния и/или приоритета бага?
• Почему люди используют термин «ручной тестировщик» (а также споры о терминологии, сопутствующие этому вопросу)?
• Насколько широка пропасть между великим и ужасным тестировщиком; кто из них чаще встречается?

Отвечая на один из этих вопросов, я упомянула три вещи, которыми заняты хорошие тестировщики, начиная с буквы “I”. Я вновь и вновь возвращалась к этой мысли, и думаю, что на самом деле великое тестирование состоит из пяти “I”. Если вы тестировщик, не занятый ни одной из “I”, то самое время начать.

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

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

«Зависит от ситуации».

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

Отставим шутки – в этой конкретной есть доля истины. В тестировании и разработке ПО крайне, крайне мало абсолютных истин.

Однако это не так легко понять, просматривая, скажем, мою ленту LinkedIn. Я где-то даже понимаю. Люди любят мыслить абсолютными категориями и говорить о них. Это простейший способ найти ответ на вопрос или сформулировать его.

Автор: Кассандра Ланг (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-ФЗ) и подзаконных актов по теме защиты ПДн? Постараюсь разъяснить всё максимально понятно.

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

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

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

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

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

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

Поехали!