Всем привет! На связи Андрей – QA-лид из Совкомбанк Технологий.

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

В этой статье разберем сколько QA-инженеров нужно проекту, от чего это зависит и есть ли корреляция количества тестировщиков с количеством разработчиков. 

Эта статья будет полезна тестировщикам, разработчикам, проектным менеджерам и руководителям команд, чтобы определить нужны ли команде проекта новые люди.

В статье рассмотрим:

• Оптимальное соотношение QA-инженеров и разработчиков

• Соотношения, которые существуют в реальных проектах и их особенности

• Параметры, которые нужно учитывать, чтобы вывести оптимальное соотношение

• Вывод идеальной формулы

Цель статьи – найти идеальный баланс количества людей в команде, отталкиваясь от сути проекта. 

Автор: Штефан Дирнштофер (Stefan Dirnstorfer)
Оригинал статьи
Перевод: Ольга Алифанова

Зачем тратить время на продумывание сообщений об ошибках?

Перед моей последней поездкой я попытался зарегистрироваться онлайн. Пользовательский путь, который проходил через утомительную серию полей формы, внезапно завершился кратким сообщением об ошибке: HTTP_400_BAD_REQUEST.

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

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

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

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

XXI век — время большого количества быстро меняющейся информации, приводящее к появлению новых (или хорошо забытых старых) явлений человеческой психики, среди которых особенно остро выделяется синдром самозванца. 

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

Автор: Green Report
Оригинал статьи
Перевод: Ольга Алифанова

Флаги-функции (feature flags) – это мощный инструмент контролируемого выпуска новых возможностей, проведения A/B-тестирования и экспериментов. Однако для инженеров по автоматизации тестирования такие фичи, скрытые за флагами, представляют собой отдельную проблему. Как обеспечить полное тестовое покрытие функциональности, которая может быть отключена в одной среде и включена в другой? В этой статье мы рассмотрим стратегии автоматизации тестирования фичей, скрытых за фича-флагами, включая настройку тестов с учётом флагов, проверку как включённого, так и отключённого состояния, и программное управление флагами для упрощения тестирования.

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

Представим ситуацию. 2010 год, вы сидите за компьютером и играете в Counter Strike или Call of Duty. В самый ответственный момент игра начинает подвисать или вы застреваете в текстурах, из‑за чего сливаете миссию. Обидно, но такое бывает по 10 раз в день, поэтому вы смиренно начинаете снова. А теперь представим ту же ситуацию в 2025 году. Очевидно, что сейчас большинство пользователей, столкнувшись с нерешаемой проблемой в игре, в итоге просто забросят ее. Потому что паттерны людей и их требования к продукту меняются. Соответственно, должны меняться и подходы к обеспечению качества ИТ‑продуктов.

Меня зовут Алексей Петров. Я директор по качеству в ОК. В этой статье я в легкой исторической перспективе рассмотрю основные тренды и подходы, которые использовались в недавнем прошлом и актуальны сейчас.

Автор: Лидия Барканова (Lidia Barkanova)
Оригинал статьи
Перевод: Ольга Алифанова

Креативность в изобразительном искусстве и тестировании

Сколько себя помню, меня всегда интересовало изобразительное искусство. Особенно я любила рисовать, используя разные материалы — от угля до масла. Я умоляла маму записать меня в художественную школу, но этого не случилось… по крайней мере, пока я была ребенком. Вместо этого я стала IT-специалистом, и сейчас работаю инженером по качеству. Ни капли не жалею! Однако моя любовь к изящным искусствам не угасала — и в прошлом году я наконец записалась на уроки рисования.

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

Автор: Юлия Ковшова
Оригинальная публикация в блоге YADRO на Хабре

Начать карьеру в тестировании — задача не из простых, особенно когда за плечами только теория и пройденные курсы, а в портфолио нет ни одного реального проекта. Большинство вакансий требуют опыт, которого у новичка еще нет, и именно на этом этапе часто возникает ступор: где взять кейсы, если тебя еще никуда не взяли.

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

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

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

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