Home

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

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

На связи Кирилл Шувалов, Senior QA Test Engineer аутстаффинговой компании Smart IT. В этой статье я расскажу вам о пути в тестирование и как добиться успеха в этой области. Будет круто, если в этих строчках начинающие IT-специалисты почерпнут для себя полезную информацию, а опытные спецы поделятся своими наставлениями в комментариях. Ну, что ж, погнали!:)

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

Как и в любой области человеческой деятельности, для вхождения в сферу требуется определённый набор знаний. Одни работодатели считают, что техническое образование обязательно для IT, другие сначала смотрят на практические навыки специалиста, а потом на его диплом. На самом деле все сильно зависит от компании/ проекта/ руководителя направления. К примеру, на большинство крупных проектов в Smart IT профильное образование является преимуществом, но сильнее ценится опыт.

На практике, примерно у каждого третьего IT-шника в крупной компании нет профильного IT-образования, но есть техническое.

Опубликован выпуск рассылки за начало июkя.

В выпуске собраны ссылки на новые статьи, слайдкасты, отобраны самые интересные публикации в ленте блогов и темы на форуме.

Содержание рассылки доступно по ссылке.

Подписаться на рассылку

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

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

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

Автор: Филип Рик (Filip Hric)
Оригинал статьи
Перевод: Ольга Алифанова

Если вы используете Cypress, то, возможно, знакомы с цепочками команд. Так ли это? Я вижу, что многие пользователи Cypress знают об этом, но иногда не улавливают их внутреннюю логику.

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

Автор: Денис Бесков

Введение

Требования к качеству, несмотря на свой небольшой размер, очень сильно влияют на реализуемость всей совокупности требований, на трудоёмкость, длительность и стоимость реализации, а следовательно окупаемость инвестиций в разработку и в целом возможную успешность проекта.

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

Но в мире честных, открытых отношений выгоднее заранее обсудить эти аспекты, чем потом с удивлением спорить при сдаче, что система тормозит, в ТЗ про это ничего не сказано, «вы же профессионалы» и всё такое.

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

При этом остаётся прагматический вопрос — а что именно писать в требования, чтобы они были полезными, измеримыми, реализуемыми?

С точки зрения системной инженерии, требования к качеству программной системы являются разновидностью системных ограничений (constraints) и в этом они отличаются от требований к способностям (capabilities) системы, в мире ИТ обычно называемых «функциональными».

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

Давайте попробуем сделать это хотя бы ремеслом.

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

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

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