Так уж случилось, что у нас накопилась масса материала, посвященного теме создания идеального отчета об ошибках (bug report). Обобщив эту информацию и вооружившись практическим опытом, мы решили написать статью. Перед вами подробный текст о стандарте написания баг репортов.
Каналы поступления багов
Начнем с каналов поступления багов. Мы можем столкнуться с проблемами и получить информацию об их появлении следующим образом:
В процессе тестирования — функционального и нефункционального.
Обращение клиента (заказчика) с информацией о возникшей проблеме.
Баги, выявленные пользователями. Соответствующая информация может быть передана как разработчикам, так и заказчику.
Ошибки полученные при помощи систем мониторинга, например Sentry, Errbit, Crashlytics.
Единственным правильным (минимизирующим негативные последствия) каналом поступления информации о багах можно считать первый. Увы, практика иногда расходится с теорией. Случаются проколы, и баги поступают по каналам №2 и №3. Эту практику можно назвать безапелляционно порочной, но ее не избежать. Поэтому мы стараемся сводить подобные инциденты к минимуму. Если второй и третий каналы не подают признаков жизни — вы гуру QA, и у вас определенно есть чему поучиться.
Однажды меня попросили рассказать о юнит тестировании в javascript, но прежде чем рассказывать о тестировании в мире front-end, надо было сделать небольшой обзор юнит тестирования как такового. В результате чего на свет и появилась эта статья, в которой я попытался рассказать о самых важных моментах в юнит тестировании.
Несмотря на различные трактовки юнит тестирования, есть несколько вещей которые объединяют этот термин.
Но есть моменты, в определении юнит тестирования, которые до сих являются спорными. В частности, что рассматривается под юнитом (единицей тестирования)? Подход ООП рассматривает класс как юнит, процедурный (или функциональный) подход, рассматривает одну функцию как юнит. Некоторые разработчики берут несколько классов и считают это юнитом, или берут набор методов в качестве юнита. Но на самом деле это ситуационная вещь, команда сама решает, что должно быть единицей тестирования в их системе.
Я постоянно помогаю людям. Звучит, будто я хвастаюсь, потому что помощь другим – это хорошее дело, не правда ли? По моему опыту, позитивная помощь при работе с ПО приносит неплохие дивиденды, однако недавно я узнала, что чересчур ответственный тест-менеджер фактически подрывает качество релиза.
Присоединившись к проекту, я беру на себя личную высокую ответственность за выпуск пользователям качественного продукта. Когда я исследую различные риски качества, мне нужно больше знать о процессах разработки и релиза ПО в компании. Когда я разговариваю с другими менеджерами об их роли в релизе продукта, мы часто находим множество важных продуктовых проблем. Две из них я встречала в нескольких компаниях:
Автоматизированные юнит-тесты не проверяются неделями или месяцами.
Релизы для тестирования и для прода выполняются разными командами.
Это серьезные риски для качества продукта, которые тест-менеджер не может игнорировать. Я работала с выдающимися людьми в индустрии разработки ПО. Их тоже волновали эти риски, но ограничения по времени, ресурсам и бюджетам не позволяли им внедрять решения этих проблем. Каждый раз я соглашалась (и зачастую вызывалась сама) брать эти задачи на себя вместо того, чтобы принять их как данность.
Конференция проводится в течение двух дней. Первый день начинается в 10.00, второй — в 10.30. Каждый день оканчивается завершающим кейноутом (в 17.35 и 18.15 соответственно).
Читатели задали мне вопрос: «С каким самым сложным случаем вы столкнулись, работая программистом?»
Мы разрабатывали систему слежения для проекта Меркурий, которая должна была отправлять человека в космос и возвращать его живым обратно. Задача «вернуть живым» была сложной, но не единственной. Были и другие трудности:
- Система базировалась на всемирной сети довольно ненадежных телетайпных подключений. - Мы должны были определить место приземления в Тихом океане в пределах небольшого радиуса, а для этого нам нужны были часы, идеально точно синхронизированные на компьютере и в космической капсуле. - Нам также нужно было точно знать, где находятся наши станции слежения, но оказалось, что с достаточной точностью никто не знает, где находятся две австралийские станции. Нам пришлось создать целый подпроект для их обнаружения в Австралии. - Нам нужна была информация о запуске ракеты, но поскольку это была также военная ракета, эта информация была засекречена. В конце концов мы нашли способ обойти эту проблему.
В предыдущей статье я рассказывала, как в нашей компании проходит первая стадия тестирования проекта — анализ. Сегодня расскажу о следующем этапе — проектирования и документирования тестов.
Этот этап опционален. На некоторых проектах нет задокументированных требований, и тогда зачастую поддержка тестовой документации является единственным разумным способом хранения и передачи знаний о продукте. Иногда тестовую документацию требует заказчик, иногда мы пишем ее для себя. Иногда, если у нас есть хорошо написанные требования, мы отказываемся от документирования тестов в пользу экономии ресурсов.
Вид тестовой документации также зависит от ситуации на проекте и ожиданий заказчика.
Самый первый метод тест-анализа, который каждый начинающий тестировщик постигает инстинктивно, – это метод граничных значений. Но так ли он прост, как это кажется на первый взгляд? Давайте разберемся!
Для сравнения разных подходов возьмем конкретный пример. Пусть у нас на сайте есть форма предварительного расчета стоимости страховки жизни, базирующаяся на очень простой формуле. Клиент вводит возраст и сумму в рублях, на которую он хочет застраховать свою жизнь. Если клиент моложе 18 лет или старше 60, выводится сообщение: «К сожалению, на данный момент у нас нет для вас подходящих предложений». Во всех остальных случаях мы просто считаем процент от введенной суммы; этот процент равен возрасту клиента. Да, я знаю, что в реальности расчет будет гораздо сложнее, но для наших целей такая модель подойдет.
По моему опыту, тестирование юзабилити незаслуженно остается за бортом. Это особенно заметно по распределению усилий на тестирование. Я часто сталкивался с продуктами, которые сильно выиграли бы от тестирования удобства использования, но на него не хватило времени, которое образовалось бы, распланируй и формализуй его команда проекта.
Держа это в уме, я разработал небольшой список подсказок для тестирования юзабилити, который, возможно, поможет вам, если вы оказались в подобной неприятной ситуации.
Постоянство
Его легко и просто оценить, и оно крайне важно для юзабилити. Сталкивались ли вы с сайтами, на которых текст был представлен в различных шрифтах и размерах, списки были то с буллетами, то с иконками, а цветовая схема менялась от страницы к странице? Долго ли вы оставались на этом сайте? Недолго? Вот и я не стал себя мучить – я стараюсь покидать такие сайты как можно быстрее. Пользователь рассматривает подобное непостоянство как непрофессионализм. Насколько хорош сервис/продукт, если даже сайт сам себе не соответствует? Даже быстрый просмотр страниц сайта может выявить несоответствия. Удивительно, насколько они бросаются в глаза, если вы просто сфокусируетесь на них на некоторое время.
7 декабря компания Петер-Сервис проведет бесплатную встречу PS QA MEETUP.
На встрече будет идти разговор о возможностях Travis CI, а также о том, как использовать TORS + Report Portal, если не хватает ресурсов на анализ результатов автотестов. Формат встречи подразумевает живое общение со спикерами.
19.30 – 20.10 Введение в TravisCI
Артем Соковец расскажет о возможностях Travis CI и поделится опытом использования. Если вы автоматизатор, который хочет прогнать свои автотесты, или разработчик, которому необходимо прогнать модульные тесты на разных окружениях и проверить код статическим анализатором, то вы однозначно не сможете пройти мимо инструментов CI.
20.10 – 20.40 TORS + ReportPortal. Анализ результатов автотестов
Александр Илюшкин расскажет, как можно решить проблему, когда при большом количестве автоматизированных тестов не хватает ресурсов для своевременной аналитики их результата. Для решения этой проблемы в продукте TORS используется интеграция с системой Report Portal. Поговорим о том, как это используется и работает.
Тестирование производительности – обобщенное понятие, которым часто обозначают разные виды проверки ПО. В данной статье команда A1QA с опорой на реальные кейсы расскажет, в какой последовательности проводится тестирование и что измеряется на каждом из этапов.
Первым в череде тестов проводится стресс-тест (StressTest), цель которого – установить предельный уровень производительности продукта. Стресс-тест позволяет проанализировать зависимость ключевых характеристик системы (времени отклика самых важных бизнес-транзакций, количества запросов в секунду, количества транзакций в секунду) от количества одновременно работающих пользователей.
Во время стресс-теста нагрузка на систему подается непрерывно до тех пор, пока не будет достигнут один из критериев его остановки. Например, стресс-тест банковской системы был остановлен при превышении отметки в 1500 пользователей, когда высокая загруженность процессора (более 80%) привела к увеличению среднего времени отклика в пять раз и массовому появлению ошибок HTTP(S).
На втором этапе проводится нагрузочный тест(Load Test), с помощью которого оценивается способность системы справляться с длительной нагрузкой (4-8 часов). Количество пользователей для нагрузочного теста определяется в количестве 80% от результата максимальной производительности, выявленной при стресс-тесте. Уровень нагрузки при тестировании банковской системы поддерживался на одном уровне в течение восьми часов и составил 1200 пользователей. Нагрузочный тест показал существенное ухудшение производительности системы с течением времени, а дополнительное профилирование ее компонентов позволило обнаружить дефекты, проявляющиеся только при длительной работе большого количества пользователей (например, утечки памяти).
