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

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

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

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

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

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

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

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

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

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

Автор: Никонов Владислав

Почитываю книжку Искусство Agile-тестирования и наткнулся в ней на такую штуку как "компонентное тестирование" (КТ). Я уже не первый раз натыкаюсь на этот термин, в первый раз я поискал инфу об этом, как то не очень понял и забил. Но с каждой последующей встречей у меня все больше подгорало.

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

Начнем с определений. Самое крутое (тут сарказм), которое я нашел это - "Компонентное тестирование программного обеспечения - это тестирование отдельных компонентов программного обеспечения". Да и вообще, во многих статьях определение пропускается и пишется, что-то вроде "компонентное тестирование это вид тестирования который следует сразу после модульного и до интеграционного". Еще варианты:

Автор: Джитеш Госай (Jitesh Gosai)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Никита Филонов
Оригинальная публикация

Вступление

В этой статье я хочу поделиться взглядом на то, каким может быть оптимальный процесс автоматизации тестирования. Мы разберём, зачем он нужен, почему именно такой подход может считаться эффективным, а также какие плюсы и минусы он несёт. Важной частью статьи станет анализ рисков, к которым может привести нарушение или игнорирование этих процессов. Кроме того, мы ответим на частый вопрос: когда и какие тесты стоит запускать на CI/CD, чтобы это было максимально эффективно и стабильно.

Сразу хочу подчеркнуть: в этой статье мы будем говорить исключительно о концепции процесса, а не о технической реализации. Здесь не будет примеров кода, конфигураций CI/CD, или привязки к конкретным инструментам и фреймворкам. Цель статьи — описать качественную архитектуру процесса автоматизации, которая может быть адаптирована под любой технологический стек.

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

• API автотесты на Python с запуском на CI/CD и Allure отчетом

• UI автотесты на Python с запуском на CI/CD и Allure отчетом. PageObject, PageComponent, PageFactory

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

Автор: Питер Томас (Peter Thomas)
Оригинал статьи
Перевод: Ольга Алифанова

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

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

Автор: Николай Алешин (Nikolay Aleshin)

2007-й год не вернуть: профессия QA-инженера, которая ещё недавно была престижной и высоко ценилась, сегодня стремительно теряет влияние, превращая опытного эксперта в «универсального бойца», которому можно спихнуть любую работу. Эта статья — моя личная история, в которой я разбираю, почему профессия больше не ценится и что сделать, чтобы она не попала в красную книгу как исчезнувший вид.

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

Даже при наличии опыта, глубокого понимания процессов и бизнес-контекста, квалифицированные QA-инженеры уже не так востребованы, как раньше. Компании по-прежнему нанимают людей на эту должность, но не понимают, зачем она им нужна. Роль QA размыта до предела — теперь это что-то между тестировщиком, аналитиком, DevOps-инженером и ещё бог знает кем.

Последний год поиска работы стал для меня настоящим шоком. Я увидел, как QA-индустрия мутировала в нечто неопределённое: требования нереалистичны, зарплаты мизерные, а доверие к профессии почти исчезло. Это заставило меня переосмыслить свой путь и сделать трудное, но необходимое решение — уйти из QA.