Home

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

Оригинал статьи: https://testzius.wordpress.com/2017/05/21/how-to-sell-qa-to-higher-ups/

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

Полный круг

Мы (снова) описали полный круг, и обеспечение качества вновь рассматривается как нечто, приносящее убытки, а не сокращающее их.

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

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

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

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

Оригинальная публикация: http://quality-lab.ru/positive-and-negative-risks-on-the-project/

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

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

Оригинальная публикация: 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%, и их мы получаем.

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

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

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