Home

Автор: Майкл Болтон (Michael Bolton)
Оригинал статьи
Перевод: Ольга Алифанова

Загляните в свежий Интернет, и вы, скорее всего, найдете Еще Одну Статью про Регрессионное Тестирование, утверждающую, что регрессионное тестирование нужно автоматизировать, потому что это механическая повторяющаяся деятельность.

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

Автор: Ekaterina Noga, оригинальная публикация

Работая QA часто слышала в голове голос «а точно ли все проверила?» и иногда он бывает полезен, но если не научиться голос использовать и затыкать, то он начинает вредить. Ниже я расскажу об этом тревожном таракане и о том, как он проявляется.

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

Автор: Филипе Фрайр (Filipe Freire)
Оригинал статьи
Перевод: Ольга Алифанова

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

Меня зовут Юрий Заковряшин. Я занимаюсь разработкой ПО более 40 лет, преподаю курсы по технологиям разработки программного обеспечения и программированию на платформе Java в СПбПУ Петра Великого.

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

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

Терминатор 2: Судный День, наверное, самый лучший из всех фильмов про Терминатора. Он по большей части сохранил дух оригинального Терминатора, но добавил более качественные спецэффекты и шикарную песню Guns ‘N Roses. ПО, о котором я буду говорить, Mailinator, всегда напоминает мне одну из самых запоминающихся фраз из Т2: «Идем со мной, если хочешь жить». Но для начала немного контекста.

В моей прошлой компании нам нужно было создать «достаточно уникальную» учетную запи сь, чтобы автоматизированное создание учетки не требовало вмешательства человека; на проде «вмешательство человека» требовалось для предотвращения мошенничества и работы со сценарием «тот же человек, другая информация». Для завершения автоматизированного тестирования создания учетной записи процесс требовал получения письма о создании учетки. В то время Google Mail, то есть Gmail, позволял это через синтаксис «емейл-адрес с плюсом».

Привет, меня зовут Нина Полторакова, я ведущий тестировщик в ГК Юзтех. 

На данный момент мы с командой занимаемся разработкой и поддержкой ИТ-решений по направлению Life — страхование жизни.

В этой статье я хочу поделиться несколькими приёмами, как не сойти с ума, тестируя страховые продукты. 

Автор: Эми Стюарт (Amy Stuart)
Оригинал статьи
Перевод: Ольга Алифанова.

Многие компании, занимающиеся разработкой ПО, просто терпят забагованные стейдж-окружения: мало кто считает это большой проблемой. Работая в разработке, вы с шансами сталкивались со стейдж-окружением, которое очень похоже на ваш первый автомобиль. Мы зачастую обещаем все починить, покупая его, но машина остается в том же состоянии годами! Боковое зеркало разбито, моргает задний габарит – но она же ездит! Мы убеждаем себя, что эти мелочи несущественны, а чинить их слишком дорого.

Хочу объяснить, почему эти «мелочи» приведут к большим проблемам в вашей команде разработки. Скорее всего, они уже именно этим и заняты. Я дам вам советы, как убедить компанию выделить ресурсы на исправление корня этих проблем. И, наконец, я расскажу, что можно сделать, чтобы привести ваш стейдж в порядок – и поддерживать этот порядок.

Бывает, что в командах тестирования грезят об автоматизации процессов, но почему-то не внедряют даже такие простые вещи как хуки: «Они очень усложняют процесс, и писать их тысячу часов». С этим я категорически не согласен, ведь реализовать хуки очень просто.

Меня зовут Денис Федоров, я тестировщик в команде 2ГИС ПРО, сервисе геоаналитики для бизнеса. Рассказываю, что такое гит-хуки, чем они могут быть полезны и как их можно реализовать у себя.