Home

Оригинальная публикация
Автор: Денис Лаптов

Доброго времени суток всем! Меня зовут Денис, я руководитель службы тестирования в «БАРС Груп».

Прочитав очень много интересных статей и почерпнув оттуда много полезной информации, захотелось что-то дать взамен. Тогда я начал анализировать темы: одни были уже озвучены, другие слишком просты («как войти в IT?»). P.S. ничьи чувства задеть не хотелось :)

Автор: Дмитрий Абузяров
Оригинальная публикация

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

Автор: Азиз Намазов

Всем привет. Представляю выжимку-перевод из нескольких статей о системе управления тесткейсами QuAck. В кратком обзоре расскажу о новых возможностях, которые появились в последних релизах.

Пожалуй, из наиболее значимых изменений — возможность импортировать автотесты и результаты их выполнения, плагины, позволяющие запускать тесты где угодно, подсистема A-B тестирования интерфейсов, окружения и фильтр нестабильных тестов.

Но обо всём — по-порядку.

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

Автор: Азиз Намазов

Представляю вашему вниманию перевод статьи «QuAck — the joy of testing» автора Aziz Namazov.


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

Автор: Хотенов Артём, hotenov.com

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



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

В своих поисках я натыкался на множество аналогичных статей (в одной из которых я позаимствовал структуру сравнительной таблицы), но все они скупо перечисляют функции с сайтов этих систем и 1-2 скриншота интерфейса и зачастую содержат скрытую или открытую рекламу одного из таких инструментов. Мне же захотелось испытать каждую систему “на себе” и непредвзято поделиться увиденным, рассказать о своих ощущениях.

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

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

Наша миссия не в том, чтобы выполнять определенный набор действий. Для большинства из нас миссия в том, чтобы узнать о продукте достаточно важной информации, чтобы наши клиенты (в основном разработчики и менеджеры) могли принимать информированные решения.

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

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

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

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

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

Автор: Катрина Клоки (Katrina Clokie).
Оригинал статьи
Перевод: Ольга Алифанова.

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

Если вы подумаете о последнем случае, когда вы неуютно себя ощущали на работе, то с высокой долей вероятности это чувство связано с какими-то переменами. Гибкий подход означает, что вы готовы принимать перемены и адаптироваться к ним на регулярной основе, а это значит, что вы постоянно испытываете дискомфорт.

Мы отобрали доклады с конференции SQA Days 24, посвященные вопросам управления людьми в тестировании. 

1. "Экспертный" тест-менеджер - почему им нельзя стать и что из этого следует, Андрей Ладутько, PandaDoc, Минск

2. Статика vs Динамика. REVолюционные изменения в команде тестирования, Елена Светлова, Олеся Серегина, T-Systems, Санкт-Петербург

3. Экономика тестирования. версия 1.0, Александр Александров, Luxoft, Москва