Home

Оригинальная публикация: http://bytextest.ru/2017/07/20/testing-and-quality-everyone-responsibility/

Мечта любого человека из игровой индустрии — работать в универсальной, многофункциональной команде. Мало кто когда-то встречался с такими, но мы точно знаем, что, как минимум, в теории, они существуют. Универсальная команда. Что же это за зверь? Это коллектив, в котором все участники рабочего процесса независимо от специализации вносят максимальный вклад на всех этапах и во все аспекты разработки продукта. Однако, чтобы достичь такой продуктивности, необходимо выполнить несколько обязательных условий.

Разработчики должны разбираться не только в модульном тестировании (unit testing), а в тестировании как совокупности огромного количества форм деятельности. Обязанности тестировщиков, в свою очередь, не должны ограничиваться исключительно тестированием.

Автор: эксперт по инженерным практикам в Альфа-лаборатории Асеева Анастасия.

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

Привет, Хабр! Меня зовут Настя, и я не люблю очереди. Поэтому я расскажу вам, на примере Альфа-Лаборатории и наших исследований, каким образом можно организовать инфраструктуру и архитектуру для прогона тестов, чтобы получать результат в разы быстрее. Например, нам удалось добиться такой цифры, как 5 минут суммарного времени прохождения тестов на приложение. Для этого нам пришлось поменять подход к запуску Selenium Grid.

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

В прошлом году мы внедряли DevOps как процесс. И в один момент, автоматизируя все и вся, мы поняли, что time to market для каждого артефакта на этапе тестирования не должен превышать 30 минут. Концептуально мы хотели, чтобы некоторые релизы проходили автоверификацию, если приемочное тестирование им не нужно. Для тех артефактов, которые нужно проверять руками, 30 минут — это время, за которое тестировщик получает результаты прогона автотестов, анализирует их, а также делает приемочное тестирование. При этом автотесты должны автоматически запускаться в рамках нашего pipeline. 

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

Автор: Майкл Фритциус (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. Определение
Итак, что подразумевается под «достаточностью времени», и чем «достаточное время» отличается от «номинального»? «Номинальное время» затрачивается на работу в идеальных условиях (без непредвиденных ситуаций). Но бывает ли так на практике?

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

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