Home

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

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

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

В назначенное время я открыл свой Outlook-календарь, встречу в нем, и кликнул по ссылке, которая гласила «Кликните тут для присоединения к встрече».

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

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

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

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

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

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

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

Автор: Настя Мордвинцева, руководитель отдела тестирования в Red Collar

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

Привет! Меня зовут Настя Мордвинцева, я руковожу отделом тестирования в Red Collar. Мы разрабатываем решения для компаний из самых разных областей и работаем с разнообразными продуктами, поэтому в моём отделе порой не хватает рук. И когда мы набираем новых людей, их приходится очень быстро вводить в курс дела. 

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

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

Автор: OSS contributor

Тестирование — один из самых больных, если не самый больной вопрос в современной разработке программного обеспечения. Поговаривают, что разработчики не любят писать тесты, что написать правильные тесты зачастую сложнее, чем сам код, что «зеленое — не значит работает», а типовые экстремисты даже утверждают, что АДТ с лихвой эти самые тесты заменяют.

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

Автор: Рауль Парваль (Rahul Parwal)
Оригинал статьи
Перевод: Ольга Алифанова

В прошлом году я и Сандип Гарг работали над электронной книгой TestFlix, зачастую откровенно обсуждая качество, тестирование и жизнь в целом. В ходе такого разговора Сандип рассказал мне про Джерри Вайнберга. Я впервые услышал про него и начал изучать его высказывания, а затем – популярные книги вроде «Секретов консалтинга» и «General system design thinking».

Автор: Чистяков Вадим
Оригинальная публикация

Фича = задача и далее по тексту :-)

Что есть задача для разработчика?  

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

После разработки

Исходя из своего опыта, могу заметить, что следующим после тестировщиков в процесс релиза вступает Release Manager или даже целая Release-Team. Он берет на себя ответственность довести задачу до клиента. Продакт/проджект-менеджеры и другие участники от бизнеса, скорее всего, имеют представление о том, что происходит с нашей новенькой и очень полезной (нет) фичой. Они также ведут таблицы, получают информацию от аналитиков и на основе этих данных могут принимать решение: "А что дальше?" 

Перевод: Горохова Юлия

Автор оригинала: 1aqa

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

Каждый год, как правило, в начале года, наблюдаю один и тот же феномен: все говорят о трендах и предположительных направлениях, в которых движется мир тестирование и автоматизации; а также о том, на чем в ближайший год должны концентрироваться люди и организации.

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

Оригинальная публикация
Статья компании SimbirSoft

Всем привет! Сегодня мы рассмотрим основные аспекты UEM (Unified Endpoint Management) — технологии, применяемой в сервисах по управлению клиентскими устройствами. Речь пойдет о виртуализации и виртуальных машинах для тестирования и обеспечения качества. Статья будет полезна для QA и DevOps уровней джуниор-мидл.

Это обзорный материал, в котором мы постарались максимально подробно описать действие виртуализации. Разберем понятие управления клиентскими устройствами, задачи и преимущества виртуальных машин в работе QA, поделимся методикой настройки и использования ВМ.

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

Стремясь сократить финансовые затраты, бизнес интересуется сервисами по управлению клиентскими устройствами, так как в большинстве стран документооборот и обмен информацией перешел в онлайн.  Для контроля информации, работы с техническими средствами коммуникации и коммутации необходим единый сервис управления, такой как виртуальные машины.