Home

Вышел выпуск рассылки за вторую половину мая, его содержание доступно по ссылке.

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

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

Оригинал статьи: http://www.ontestautomation.com/monitoring-the-quality-of-your-test-automation-code/

Автор: Баз Дийкстра (Bas Dijkstra)

Перевод: Ольга Алифанова

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

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

Аргумент "за": создание автотестов – это разработка ПО.

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

Оригинальная публикация: https://habrahabr.ru/post/329966/

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

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

Эти определения неверны.

Вот вам дедуктивное умозаключение:

Вписываясь в тестирование, мы желаем добавить продукту значимость (ценность) –
Добавление ценности продукту происходит за счет увеличения качества и надежности продукта – 
Добавление надежности продукта происходит путем поиска и удаления ошибок.

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

Оригинальная публикация: https://vc.ru/p/qa-test-game-services

Советы от QA-менеджера Crytek по тестированию игр, которые требуют регулярного обновления.

Чем дольше живёт проект — тем критичнее случайные баги. Внезапно появившиеся ошибки могут оттолкнуть значительную часть аудитории. QA-менеджер Crytek Евгений Скачков поделился на конференции Games Gathering 2016 опытом контроля качества проекта Warface, разработанного киевским филиалом компании.

Издание DTF опубликовало расшифровку выступления.

Про игру

Warface — онлайн free-to-play-шутер. Практически пять лет игра находится на стадии оперирования и больше восьми лет — в разработке. Это самый большой free-to-play-шутер на территории СНГ. Три года назад мы поставили официально зарегистрированный рекорд Гиннесса — 145 тысяч пользователей в онлайне на одном сервере.

Если посчитать по всем территориям, PCU (peak concurrent users) больше — около 200 тысяч человек. Ежедневно в игру заходят около 700 тысяч уникальных пользователей. Каждый год мы выдаём около 12 крупных обновлений.

Как происходит разработка обычного, «коробочного» продукта? Программисты и дизайнеры что-то создают, придумывают креативы, прототипируют и в какой-то момент решают, что игра готова. Её нужно протестировать. Что-то они проверяют своими силами, но этого недостаточно. Собираются QA-команды, и начинается «zerg rush».

Если вы тест-менеджер, на вас ложится ответственность организовать рабочий процесс в своей команде. И в идеале так, чтобы всем сотрудникам было комфортно. Задача не простая. Но спикеры, приглашенные на конференцию COMAQA Spring 2017, попытались с ней разобраться.

Если у вас уже есть команда, с которой вы сотрудничаете не первый год, возможно, в решении многих вопросов вам поможет правильных подход к мотивации сотрудников.

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

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

Ниже представляем записи докладов, где были озвучены эти и другие интересные тест-менеджеру вопросы:

Автор: Руслан Ахметзянов

Оригинальная публикация: https://habrahabr.ru/company/jugru/blog/327362/

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


— Расскажите, пожалуйста, немного о себе и своей работе. Как вы связаны с тестированием?

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

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

Еще спустя год (с апреля 2016 года) я стал руководить всем тестированием в «Одноклассниках», сохранив за собой и предыдущие позиции. В итоге сфера моих обязанностей довольно широка — чаще всего я могу назвать себя психоаналитиком в IT.

Автор: Юлия Миронова, ведущий специалист по тестированию компании "Лаборатория качества"

Оригинальная публикация: http://quality-lab.ru/do-you-need-specialized-testers-in-your-team/

Предыстория вопроса

 Давным-давно, когда деревья были большими, солнце светило ярче, а телефоны не работали без проводов, программисты делали все сами. Сами выясняли, что хочет заказчик, сами писали программу, сами ее тестировали. Прошли годы, отрасль расширилась, и появились первые специализации. Аналитик стал выяснять и описывать требования, дизайнер – продумывать внешний вид, разработчик – писать код, тестировщик – проверять, правильно ли все работает. В наше время тенденция увеличения численности команд тестирования поставила перед руководителями новый вопрос, который пока еще не имеет однозначного ответа: нужна ли специализация тестировщиков внутри одной команды?

Специализация: когда она работает на нас, а когда – против?

Для начала отметим некие общие принципы, которые нужно учесть.

Итак, специализация явно нужна в следующих случаях:

• тестируется критичное ПО, ошибки в котором могут затрагивать жизнь и здоровье людей, а также крупные финансовые потоки;
• специализированные тестировщики одних направлений на вашем рынке дороже тестировщиков других направлений, а также существенно дороже широкопрофильных специалистов (нет смысла тратить «дорогой» труд на «дешевые» задачи и нет смысла учить тестировщиков на специалистов – выучась, они продолжат работать за прежнюю зарплату лишь до первого интересного предложения в LinkedIn);
• узкопрофильный тестировщик может обслуживать более одного проекта в вашей компании (например, автоматизаторы или юзабилисты часто работают сразу на нескольких проектах);
• вы решили отдать на аутсорс некоторые задачи – простые или сложные разовые (типа полной автоматизации устоявшегося регресса или юзабилити-оценку).

Автор: Джоэл Монтвелиски (Joel Montvelisky)

Оригинал статьи: http://qablog.practitest.com/testing-not-a-career/

Перевод: Ольга Алифанова

Это путешествие.

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

Если это так, то какая дорога лучше всего подходит для того, чтобы стать успешным профессиональным тестировщиком?

Я, честно говоря, не знаю.

Более того, я даже не знаю, есть ли единственно верный путь.

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

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

Успешные тестировщики обладают вот такими качествами – я встречал их практически у любого профессионала: