Home

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

Всем привет! Меня зовут Екатерина и я QA-специалист в компании SimbirSoft. Я уже 7 лет занимаюсь обеспечением качества IT-продуктов, и за это время прочитала множество книг и пособий. Многим книгам по QA уже много лет, а новинки появляются достаточно редко. В январе 2024 года на русском языке вышел «Идеальный тестировщик» Кристин Джеквони — поэтому я сразу обратила внимание на эту книгу. Поделюсь с вами своей оценкой и выводами — что в ней есть полезного и чего не хватило.

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

Конечно, нет! Наша автоматизация должна прогоняться за секунды, или хотя бы менее, чем за десять минут. Ведь верно? Ведь правильно? Вставьте сюда мем с Падме и Анакином. 45 минут – это явно антипаттерн и всегда плохая идея, правда же?

Все вы знаете, не так ли, что бывает, когда я задаю подобные абсолютные вопросы, да?

Я Арман, Senior QA, тестирую android уже 4 года. Если вам интересно узнавать больше полезного и интересного, не только про мобильное тестирование, то держите мой канал t.me/LilBugHunters, здесь я делюсь короткими полезными заметками для QA-специалистов.

Эта статья будет посвящена разбору жизненного цикла activity в android для ручного тестировщика. Начну сразу с самого главного – зачем вам, тестировщику, вообще вникать в то, что такое жизненный цикл activity. После уже рассмотрим как activity работает, какие бывают состояния и вообще какие кейсы можно отловить, зная всё это и какие инструменты для этого нужно использовать.

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

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

Автор: Мария, специалист по тестированию ЛК

Когда на новом проекте менеджер попросила меня провести эстимацию тестирования, я сначала растерялась, ведь это вроде как задача менеджера или старшего тестировщика. А потом вспомнила, что я – единственный тестировщик на проекте. И понеслось…

Автор: Кристин Джеквони (Kristin Jackvony)
Оригинал статьи
Перевод: Ольга Алифанова

Мы уже изучили больше половины принципов SOLID! Сегодня настало время узнать про букву I: принцип разделения интерфейсов.

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

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

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

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

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

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

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

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

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

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

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

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

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

QA, QE и специалисты-тестировщики часто слышат одни и те же вопросы, особенно находясь на руководящей позиции. Например, это «сколько кейсов еще осталось», «сколько времени еще нужно тестированию», и «какой процент тестирования завершен».

Как руководители, мы часто должны отвечать прямо, линейно, исчислимо. Именно это, как правило, и нужно задающим вопросы – простой, удобоваримый кусок информации, на основе которого принимаются сложные бизнес-решения. Бизнес ожидает ответов вроде «Нам осталось выполнить 500 кейсов из 10000», «в среднем мы выполняем 50 кейсов в день, то есть дней 10», и «мы на 95% готовы».

Опытные люди, однако, знают, что эти ответы не всегда дают нужную информацию. Минусы соблазна «просто сказать им число»:

• Числа легко истолковать неверно.
• Числа не показывают всей картины.
• Они одномерны.
• Они отражают устаревшие данные.

Эффективный способ решить эту проблему – воспользоваться метрикой, разработанной одним из нас (это был Мас Коно). Он называет ее тест-пойнтами. По сути это взвешенный замер запуска планируемых кейсов.