Home

Автор: Ярослав Хорошкин

Оригинальная публикация: http://quality-lab.ru/experience-with-using-scrumban-in-testing/

За последние 20 лет Agile, Lean, Scrum и Kanban неуклонно завоевывают популярность в различных сферах и отраслях экономики. И это правильно, так как именно благодаря гибким технологиям многие компании смогли закончить свои проекты быстрее и\или увеличить прибыль. 

Но что же такое Agile и Lean? Что такое Scrum и Kanban? Чем они хороши, и какая между ними разница? И самое главное: как все это работает в сфере тестирования? В данной статье я постараюсь ответить на эти вопросы.

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

Оригинал статьи: http://quality-lab.ru/transforming-chaos-into-order/

Проекты с идеальным порядком, к сожалению, встречаются крайне редко. Чаще всего мы сталкиваемся с хаосом разной степени беспорядочности: от «черт ногу сломит» до мелких проблем, лишь изредка дающих знать о себе (например, при появлении новых сотрудников). Но, закрывая глаза даже на совсем небольшие дефекты, мы все больше приближаемся к настоящему «апокалипсису», способному «убить» самые интересные и стабильные проекты. Все как в «теории разбитых окон»: чем чаще мы не замечаем проблемы – тем больше их становится, и тем прочнее они внедряются в нашу жизнь. Увы, по-другому не бывает.

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

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

Оригинальная публикация: http://quality-lab.ru/unbelievable-fuckup-stories/

Мальчишки и девчонки!
А также их родители!
Рассказы про «факапы»
Послушать не хотите ли? 

Идеальных людей не существует – следовательно, все мы рано или поздно допускаем ошибки. От ошибок не застрахован никто, но это еще не значит, что нужно опустить руки и отдаться на волю случая. Наша задача – научиться сводить к минимуму число решений, приводящих к печальным последствиям (о способах борьбы с «факапами» можно прочитать здесь). Самый же распространенный метод обучения основан на исследовании своих и чужих ошибок, поэтому сейчас я расскажу вам несколько историй «о том, как делать не надо».

История первая: «Тараканище»

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

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

Автор: Артур Пачин

Да, у нас есть опыт применения ИИ

Инженеры Перфоманс Лаб постоянно исследуют возможности применения наиболее эффективных передовых технологий, позволяющих получать более качественные результаты в работе, в том числе искусственный интеллект. У нас имеется опыт использования технологий машинного обучения для системы HelpDesk. Технология применяется для автоматического заполнения различных полей входящих инцидентов. Для успешного предсказания значений в данных полях, искусственный интеллект предварительно обучался на заданной выборке заполненных инцидентов и с помощью алгоритмов машинного обучения строил модель. На основе построенной модели в дальнейшем делались предсказания значений полей.

Что грядет

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

Тестирование нуждается в постоянном улучшении, как и любой другой процесс. Возникал ли у вас вопрос “как улучшать”? Можно прибегнуть к конкретной методике, можно использовать отдельные принципы популярных практик... Но, прежде чем приступить к действию, можно прислушаться к специалистам, которые уже внедряют некоторые из них.

Ниже представлены записи докладов с конференции COMAQA Spring на тему улучшения процессов тестирования:

Автор: Илья Ивасюв

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

В данной статье я рассмотрю вопрос выделения достаточного количества времени на проведения тестов. Практика показывает, что именно на этом шаге создания продукта время зачастую экономится («там всего-то протестировать на полчасика – и все»). Для того, чтобы понять, почему нам важно выделить достаточно времени для проведения тестов, подробно рассмотрим, какие именно факторы могут привести к срыву сроков. 

Что такое «достаточность времени» и как ее рассчитать?

1. Определение
Итак, что подразумевается под «достаточностью времени», и чем «достаточное время» отличается от «номинального»? «Номинальное время» затрачивается на работу в идеальных условиях (без непредвиденных ситуаций). Но бывает ли так на практике?

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

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

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

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

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

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

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

Типы взаимоотношений

Для понимания сути проблемы приведем классификацию взаимоотношений в рабочей группе, предложенную американскими исследователями Блейком и Myтoном и учитывающую комбинацию двух основных параметров – взаимоотношения сотрудников и их отношения к рабочему процессу.

Выделим 5 основных типов:
1) невмешательство – низкий уровень заботы как о проекте, так и о коллегах (каждый сам за себя, сотрудники не заинтересованы в совместном конечном результате и не чувствуют себя членами рабочего коллектива);
2) теплая компания – комфортные отношения в коллективе, не направленные на достижение конкретных и устойчивых результатов работы;
3) задача – внимание каждого полностью сосредоточено на решении производственных задач, человеческий фактор недооценивается или просто игнорируется;
4) золотая середина – сотрудники в своей деятельности стремятся оптимально сочетать интересы дела и коллег;
5) команда – наиболее предпочтительный тип взаимоотношений в рабочей группе. Максимально учитывает интересы производства и коллектива, объединяет деловитость и человечность на всех уровнях отношений.

Автор: Майкл Фритциус (Michael Fritzius)

Оригинал статьи: https://testzius.wordpress.com/2017/01/16/catching-changes-before-they-become-problems/

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

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

Чувствуете ли вы, что это неплохой фильтр, который изловит практически любой внедренный баг?

Как вы будете себя чувствовать, когда узнаете, что был найден баг, а ваш зелененький прогон будет улыбаться вам с экрана? Не очень?

"Почему тесты этого не уловили?" Хм.

Причина

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

Я мог уже об этом писать где-то: код – это органическая структура.

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

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

О многом просто забывают. Или в продукт вносятся изменения, а люди еще не в курсе, что автоматизация эти изменения не учитывает.

После того, как ваши автотесты написаны и дают вам достойную доверия обратную связь, как вы узнаете, что настала пора менять и пополнять их?

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

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

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

Если мы думаем, что у нас вполне приличный набор тестов, мы можем начать думать, что он не нуждается в добавлениях. Он полон, и мы, возможно, не стремимся к 100% покрытию, нам вполне достаточно 70-80%, и их мы получаем.

И даже в этом случае что-нибудь да просочится через нашу защиту.

Это происходит, как правило, редко, но если какой-нибудь "не тот" баг прокрадется в релиз, это станет проблемой для компании.

Пытаться решить вопрос "как протестировать добавленное" довольно сложно. Зато вполне легко решить вопрос "как определить, когда что-то добавлено".

Автор: Виктория Юркевич

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

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

Прежде всего разберемся, что же такое целевая аудитория (в дальнейшем – ЦА). В соответствии с определением из Британского бизнес-словаря, целевая аудитория (англ. target audience) – это группа людей или сегмент рынка, для которого предназначен продукт, услуга, веб-сайт, реклама, телевизионная или радио программа и т. д.

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

Для чего нам нужно знать целевую аудиторию проекта?

Знать и понимать ЦА важно на каждом этапе разработки программы. Может ли разработчик приложения-мессенджера, к примеру, не учесть, что продуктом могут воспользоваться слабовидящие пользователи, для которых нужны специальные возможности? Запросто!

При проектировании сайта важно не только добиться привлекательного оформления страниц, но и обеспечить пользователю простое и понятное выполнение пользовательских действий (например, сделать процесс поиска товара легким и очевидным). На этом этапе тщательное изучение ЦА является обязательным. Оно необходимо для того, чтобы понять, почему пользователь не выполняет ожидаемых от него действий и не реализует цель нахождения на сайте (или использования продукта).

Автор: Мелвин Салазар (Melvin Salazar)

Оригинал статьи: https://huddle.eurostarsoftwaretesting.com/benefits-pair-testing-oil-industry-software/

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

1. Введение.

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

2. Преимущества, связанные с дележкой знаниями.

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

• В одну команду были объединены тестировщики с разным техническим опытом (технические эксперты по нефти, математики, компьютерные инженеры, и т. д.), которые, следовательно, смогли предоставить спектр перспектив и подходов к тестированию.
• В одну команду были объединены тестировщики с разным уровнем опыта. Сочетание новых инновационных взглядов со зрелыми опытными умами может дать отличные результаты в плане качества поддержки новой функциональности.
• Более тесное взаимодействие с разработчиками и командами портфолио и менеджмента. Два тестировщика создают больше каналов коммуникации, чем один, позволяя знаниям эффективнее распространяться между командами и повышая эффективность разработки.
• Сочетание различных практик тестирования. Процесс тестирования может быть разделен между двумя тестировщиками различными способами: одновременное тестирование одной и той же фичи, одновременное тестирование разных фич, тестирование частей одной и той же фичи и ее зависимостей, и т. д. Парное тестирование – это отличная возможность комбинировать различные практики и подходы к тестированию.