Home

Автор: Джил Зильберфельд (Gil Zilberfeld)
Оригинал статьи
Перевод: Ольга Алифанова

Хрупкие тесты.

При одной мысли о них нас тошнит, и это неспроста. Им нельзя доверять. И они стоят денег.

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

Ах, это эти тесты, ну значит, все в порядке. Нужно просто прогнать их еще раз. Однако доверие к остальным тестам начинает подрываться. Если эти тесты "обычно" срабатывают, можно ли доверять прочим тестам? Что, если они начнут падать – их надо будет просто прогнать еще раз, и все будет хорошо? Может, сделать это дважды, и все исправится?

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

Этот вопрос возник в ходе недавнего онлайн-тренинга Rapid Sofware Testing Explored. Донатас сказал "Предположим, мы нашли проблему в приложении или самом процессе разработки. Однако она не получает должного, с нашей точки зрения, внимания. Как убедить остальных? Что рекомендуется для взаимодействия с разработчиками, менеджерами и продакт-оунерами в этом случае?"

Это одна из больших проблем  0в тестировании. Как тестировщик, вы находите проблемы. Однако, если ваши клиенты не согласны с вами  в определении проблемы, вас не будут расценивать, как значимого члена команды. Вы станете печальным привидением, слоняющимся по чердаку.

Автор: Ольга Назина (Киселёва)

В конце прошлого года я выпустила свою первую книгу по тестированию — «Курс молодого бойца». Это было нелегко и долго =) 

Книгу я писала… 3 года! Потом ещё год искала художников и доделывала картинки. Потом искала издательства, проходила редактуру и т.д. Итого — 4.5 года:

07.09.2017 — 11.01.2022 (дата выхода книги на площадках типа OZON)

Я хочу поделиться своим опытом, рассказать про весь процесс. Что вообще предстоит автору, какие фазы нужно пройти от идеи до публикации. Может быть, мой опыт поможет вам тоже решиться на такую авантюру =)

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

Автор статьи — Ольга Артемьева, ведущая тестировщица КриптоПро, ментор и создательница блога Тестирование и жизнь.

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

Автор: Александра Пшеборовская

Сейчас компетентность в сфере TestOps является таким же базовым требованием к QA-инженерам, как и написание автоматизированных тестов. Причина — в активном развитии CI/CD в проектах и необходимости QA-инженерам работать с пайплайнами (читать как "последовательность этапов в CI/CD") и даже внедрять свои. Так почему же CI/CD — отличный инструмент контроля качества? Давайте разбираться.

Итак, зачем CI/CD тестировщикам?

Автор: Маша Аккуратнова

Привет. Меня зовут Маша, я — тестировщик в команде мобильной платформы. Когда-то для нас была актуальна проблема взаимодействия QA и Support. Сложностей было предостаточно, как и неприятных последствий. Но со временем мы успешно разобрались во всем. Хочу поделиться нашим опытом и рассказать, какие изменения сработали во благо.

Автор оригинала: Artem Golubev

Автор: Виктор Славчев (Viktor Slavchev)
Оригинал статьи
Перевод: Ольга Алифанова

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

Рискну сказать, что с качеством все в порядке – в конце концов, это то, к чему мы все стремимся, не так ли? Качество жизни, качественная машина, качественные отношения, мы должны что-то в этом понимать, но почему мы так путаемся, говоря о качестве ПО? Я уверен, что у качества есть грязные секретики, которые узнаешь, только имея с ним дело.

Автор: Энди Найт (Andy Knight)
Оригинал статьи
Перевод: Ольга Алифанова

С большим волнением представляю вам довольно новую для вас и нашей отрасли идею: Открытое тестирование: что, если мы откроем наши тесты так же, как наш исходный код? Я говорю не просто о тест-фреймворках с открытым исходным кодом. Я говорю об открытии самих тестов. Что, если делиться тест-кейсами и процедурами автотестов станет нормой? Что, если для компаний будет нормальным открыто публиковать результаты тестов? И каков уровень открытости тестирования, к которому наша отрасль должна стремиться?

Автор: Джеспер Оттосен (Jesper Ottosen)
Оригинал статьи
Перевод: Ольга Алифанова

Если тестирование можно интегрировать в разработку, то кто тестирует, если кода еще нет? Должен ли код существовать для того, чтобы существовало тестирование, и в какой момент тестирование можно начинать?

Нынче появился новый тип бизнес-приложений – продукты "Мало кода / без кода". Например, это платформа WordPress, при помощи которой я это пишу. Еще пример более высокоуровневого решения - AirTable, позволяющий пользователю быстро и без кода организовать и автоматизировать информацию. Схожий тренд наблюдается в пространстве тест-инструментов вроде Cypress и Mabl, тест-кейсы и сценарии напрямую присоединяются к end-to-end бизнес-цели, а не к технологиям. Инструменты "низкого кода" – это новый тип бизнес-решений для "кастомизации" и "конфигурации".