Автор: Эди Стоукс (Ady Stokes)
Оригинал статьи
Перевод: Ольга Алифанова

Введение

Тестировщики, слыша фразу «пайплайн CI/CD», обычно реагируют двумя способами. Те, кто тесно работал с пайплайнами или занимался автоматизацией, видят в этом возможность. Однако те, кто от автоматизации далек, часто пугается. Я видел, как люди говорили или писали что-то вроде:

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

Пайплайны CI/CD – это, безусловно, часть автоматизации, но это не только и не столько это. В этой статье я расскажу, что это такое, почему тестировщикам надо понимать, как это работает, и почему это важно для них. Начнем с начала – разберемся, что это.

Автор: Филип Рик
Оригинальная публикация

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

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

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

Конечно, нет.

Автор: Томаш Балог (Tamás Balog)
Оригинал статьи
Перевод: Ольга Алифанова

Тестировщики, скорее всего, знакомы с понятием тест-пирамиды: юнит- и компонентные тесты, различные уровни интеграционных тестов, и все остальное.

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

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

Автор: Константинос Константакопулос (Konstantinos Konstantakopoulos)
Оригинал статьи
Перевод: Ольга Алифанова

Хорошие новости: вы уже системно мыслите!

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

Приходилось ли вам в повседневной жизни:

• Планировать меню, закупать продукты, составлять бюджет и придерживаться его, и подавать на стол хорошо приготовленную еду ровно в срок к ужину?
• Отвозить детей в школу, а затем вовремя успевать на работу?
• Чинить что-либо по дому, или разбираться, как помочь кому-то с явной проблемой?

Знаете, что? Вы уже мыслите системно! И эта способность очень пригодится вам как тестировщику. Но, возможно, вам нужно развить навыки и глубже практиковать это мышление.

Автор: Джулиан Харти (Julian Harty)
Оригинал статьи
Перевод: Ольга Алифанова

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

Эта статья описывает эти темы. Я не буду детально вдаваться в них (возможно, напишу про них позже) – вместо этого сконцентрируюсь на том, как я учился в ходе этого проекта.

Автор: Кассандра Ланг (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 часто слышала в голове голос «а точно ли все проверила?» и иногда он бывает полезен, но если не научиться голос использовать и затыкать, то он начинает вредить. Ниже я расскажу об этом тревожном таракане и о том, как он проявляется.

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