Автор: Джерри Вайнберг (Jerry Weinberg)
Оригинал статьи: Tea-Time With Testers, #03/2021
Перевод: Ольга Алифанова

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

Филипп Б. Кросби.

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

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

Из каждого утюга сегодня звучит призыв двигаться в сторону IT. Информационные технологии — это уже не только про математику, но и про дизайн, менеджмент, аналитику и тестирование. Причём о тестировании говорят как о чём-то очень лёгком для начала карьеры. Мол, стать тестировщиком может каждый. Но стать — это одно, а стать профессионалом — совсем другое.

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

Автор: Т. Ашок (T. Ashok)
Оригинал статьи: Tea-Time With Testers, #01/2021
Перевод: Ольга Алифанова

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

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

Автор: Ольга Назина (Киселёва)

Хорошее название бага понятно любому:

• менеджеру, плохо знающему техническую часть проекта;

• джуниору, который только пришел в проект;

• разработчику (зачем мне это чинить?)

Для этого оно должно отвечать на 3 главные вопроса: Что? Где? Когда?

И в этой статье я хочу разобрать каждый из них подробнее.

Автор: Роб Мини (Rob Meaney)
Оригинал статьи: Tea-Time With Testers, #01/2021
Перевод: Ольга Алифанова

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

Автор: Субботин Юрий

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

Автор: Филип Фрейр (Filipe Freire)
Оригинал статьи: Tea-Time With Testers, #03/2021
Перевод: Ольга Алифанова

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

Среднестатистический инженер-тестировщик

Проблема

Сравнение инструментов (или фреймворков) тестирования и реальный выбор инструмента могут быть болезненным и чересчур сложным делом для современной технической организации:

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

Это зачастую верно вне зависимости от области применения инструмента – UI, API, нагрузка и производительность…

Автор оригинала: Paul Gerrard
Перевод: ProQuality Community, телеграмм

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

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

В этой статье я расскажу о: 

• Ценности документации 

• Опасности шаблонов и вырезания/вставки готовых шаблонов 

• Типы тестовой документации 

• Консультации по проектной документации