Home

Автор: Нина Агеева, тест-менеджер компании "Лаборатория качества"

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

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

Итак, для начала обратимся к самому понятию KPI. KPI (Key Performance Indicator) – это показатель достижения успеха в определенной деятельности или в достижении определенных целей. Можно сказать, что KPI – это количественно измеримый индикатор фактически достигнутых результатов.

Автор: Евгений Демидов

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

Просим поделиться своим опытом работы со статистикой тестирования в этом опросе (прохождение опроса займет не более 2 минут), из результатов которого мы сможем понять:

Более подробную информацию об опросе Вы можете найти в этом топике на форуме.

Ссылка на опрос: https://goo.gl/forms/a8QGMF0tO0PGfoyW2 (прохождение опроса займет не более 2 минут)

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

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

Оригинальная публикация: http://quality-lab.ru/what-to-do-when-there-is-no-time-for-testing/

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

Оригинальная публикация: https://tproger.ru/articles/avoid-data-leaks-when-testing/

При внедрении и сопровождении бизнес-приложений всегда нужна «обкатка» на тестовых данных. Беда в том, что для тестов иногда используют конфиденциальные данные из баз корпоративных заказчиков, в том числе персональные. Как не допустить их утечки и в то же время протестировать систему в условиях, приближенных к «боевым»?

Откуда берутся тестовые данные

Тестовые данные получают по-разному, у каждого из подходов свои плюсы и минусы:

• можно генерировать их в автоматизированном режиме. Для этого нужны специальные инструменты, довольно сложные;
• можно вводить тестовые данные вручную, но это требует серьезных трудозатрат;
• иногда разработчики берут рабочую базу, которая полностью копируется в тестовую среду. Но рабочая база обычно велика, и адекватно уменьшить её сложно.

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

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

Автор: Панна Черукури (Panna Cherukuri)

Оригинал статьи: https://www.testingcircus.com/documents/TestingTrapeze-2015-June.pdf#page=27

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

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

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

Оригинальная публикация: http://quality-lab.ru/audit-on-a-small-project/

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

Так начиналась история нашего аудита на одном из проектов. Команда, как вы поняли, была немногочисленной и состояла всего из трех QA специалистов. Тестирование на проекте начиналось с одного тестировщика, но после увеличения штата команда ощутила острое непонимание вопросов «что происходит» и «куда двигаться дальше». Помог ли аудит? Расскажу в конце.

Оригинальная публикация: 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/

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