Home

Автор: Джил Зильберфельд (Gil Zilberfeld)
Оригинал статьи
Перевод: Ольга Алифанова

Хрупкие тесты.

При одной мысли о них нас тошнит, и это неспроста. Им нельзя доверять. И они стоят денег.

Начнем с доверия. У нас есть тесты, которые проверяют один и тот же код, срабатывают в большинстве случаев, но затем один билд из сотни падает. Затем мы прогоняем тесты еще раз, и они проходят успешно.

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

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

«Вначале было слово и это слово было два байта»
Старая шутка программистов

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

Автор: Баз Дейкстра (Bas Dijkstra)
Оригинал статьи
Перевод: Ольга Алифанова

В предыдущих статьях серии о тестировании ориентированных на потребителя контрактов и Pact мы обсуждали CDCT, разобрались, как использовать Pact для поддержки CDCT, как автоматизировать процесс и сделать его частью процессов CI/CD, и посмотрели, что будет, когда на стороне потребителя меняются ожидания.

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

Предупреждение: двусторонне направленное тестирование контрактов существует только в Pactflow и недоступно в OSS Pact Broker.

Я Алексей Булахов, инженер по обеспечению качества в Tele2. Одним из самых нетривиальных вопросов, которым может задаться QA-инженер, который планирует тестировать функционал мобильного приложения, является выбор среды для тестирования. Это могут быть реальные или виртуальные девайсы (эмуляторы/симуляторы) или же готовые решения (различные облачные платформы). Для нас этот вопрос тоже был весьма важен, и на разных этапах становления проекта нам довелось поработать со всеми вышеизложенными вариантами, так как среди них нет идеальных решений и каждый вариант хорош в рамках определенного контекста. Об этом я и расскажу далее.

Условно историю нашего проекта можно разделить на три этапа становления, когда преследовались разные цели.

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

Когда мы говорим о глубоком и поверхностном тестировании в терминологии Rapid Software Testing, многие полагают, что "глубокое" тестирование – это хорошо, почетно и правильно, а "поверхностное" – оскорбление. Но это не так. "Поверхностное" – это не оскорбление.

Глубина и поверхностность – это способы обсудить тщательность тестирования, но они не оценивают его ценность. Ценность, качество, уместность тщательности можно оценивать только в контексте. Поверхностное тестирование может быть идеальным вариантом для определенных задач, а глубокое – патологическим. Как так? Начнем с объяснений, что же мы на самом деле имеем в виду.

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

Автор: Николай Шабалин

Давайте поговорим о том, как написать хорошее описание фотографий в атрибуте alt.

В первой части мы обсудили основные правила написания alt-текста для фотографий и изображений. В этот раз поговорим о том, каким именно должно быть описание, чтобы в нём был смысл.

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

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

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

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

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

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

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