К основному контенту

Сообщения

Как готовится хороший баг?

Рассмотрим еще одну интересную тему "Рецепт хорошего бага" (источник: http://www.xmind.net/m/kwhk). Ниже представлена схема построения бага. Разберем по частям. Для начала хочется обсудить, кто заинтересован в заведении бага? Вы думаете только тестировщик? Дефекты позволяют тимлиду команды оценить степень готовности проекта на данном этапе, возможно изменить ход работы команды с задачами. Некоторые дефекты появляются по причине недопонимания разработчика разрабатываемого функционала или потому, что описание функционала не однозначно и все члены команды понимают его по разному. Дефект для разработчика – это корректировка упущенной (или специально пропущенной?:) ) части функционала. Для аналитика дефект показывает: 1)     Возможно ошибку в описании функционала, что позволяет исправить ее на ранней стадии проекта 2)     Оценить корректность описанного функционала, ведь тестировщик (как говорилось выше) и аналитик могут воспринимать описанный функц...

Заблуждения о профессии тестировщика в России

На одном из занятий в МГТУ им. Баумана была рассмотрена интересная тема, касаемая профессии тестировщика. Ниже приведена схема "Топ 10 заблуждений о профессии тестировщика в России". (источник: http://www.xmind.net/m/mKd7)            Так как данная профессия установилась относительно недавно, многие заблуждения постепенно развеиваются. Но поговорить о них все таки стоит.            Я бы сравнила тестировщика с поваром. Он тестирует продукт по рецепту, который написан в книге, но добавляет свою изюминку, что позволяет найти больше несоответствий в программном продукте. Ведь не все люди могут готовить одинаково.           В профессии повара есть разделения: кто-то идеально готовит десерты, кто-то горячие блюда, а кто-то закуски. Так и в тестировании: кто-то функциональщик, кто-то автоматизатор, а кто-то нагрузочник. У тестирования, как и у кулинарии, есть свой шеф-повар, гуру, к уровню которо...

Дымовое, критического пути и расширенное тестирование

Из приведенной ранее классификации тестирования (в статье " С чего начинать изучение тестирования? Конечно же с методов! ") нам осталось рассмотреть «по степени важности тестируемых функций». Но, на этом теория еще не заканчивается) Итак, по степени важности тестируемых функций разделяют следующие виды: - «Дымовое» (smoke) - тестирование, которое состоит из минимального набора тестов на явные ошибки. Дымовое тестирование на начальном этапе выявляет основные критические дефекты. Исходя из того, что данные проверки практически всегда одинаковы и редко претерпевают изменениям, целесообразно будет их автоматизировать. Ежедневная сборка продукта и smoke тестирование являются передовыми практическими методами. Программу, не проходящую "дымовой тест", не имеет смысла отдавать для более глубокого тестирования. - Критического пути ( critical path test ) — основной тип тестовых испытаний, во время которого значимые элементы и функции приложения проверяются н...

С чего начинать: модульного, интеграционного или системного тестирования?

Продолжаем разбираться в понятиях тестирования, и в данном блоге рассмотрим классификацию «по уровню детализации приложения»: модульное, интеграционное и системное ( рис.1). Рисунок 1. Схематичное представление классификации тестирования по уровню детализации приложения Уровни тестирования в основном предназначены для выявления недостающих областей и предотвращения дублирования и повторения между этапами жизненного цикла разработки. В моделях жизненного цикла разработки программного обеспечения существуют определенные этапы, такие как сбор и анализ требований, проектирование, кодирование или внедрение, тестирование и развертывание.  Каждая фаза проходит тестирование.   Модульным тестированием (unit testing, module testing, component testing) в основном занимаются (хорошие, но не все=) ) разработчики, чтобы убедиться что разрабатываемая часть кода работает верно в соответствии с документацией. Тестовый модуль является наименьшим проверяемым час...

Ручное и автоматизированное тестирование

В блоге "LoadTest тонкого и толстого клиента в VS" были описаны практические навыки автоматизированного нагрузочного тестирования. По этой причине в данном блоге рассмотрим классификацию тестирования по степени автоматизации. На рис. 1 представлено всего 2 вида: ручное и автоматизированное, но в некоторых источниках встречается еще полуавтоматизированное тестирование. Рисунок 1. Классификация тестирования Ручное тестирование — тестирование, в котором тест-кейсы выполняются человеком вручную, без использования средств автоматизации. Э то процесс поиска дефектов в работе программы, когда тестировщик проверяет работоспособность всех компонентов программы, как если бы он был пользователем. Для точности проверки, тестировщик использует заранее заготовленный план тестирования, в котором отмечены наиболее важные аспекты работы программы. Автоматизированное тестирование - выполнение тестов, реализуемое при помощи заранее записанной последовательности тестов. Тест-кейсы ча...

Запуск Unit test VS на build сервере TFS

1.  Для дальнейшей работы в TFS необходимо наличие соответствующих прав 2.      На билд сервере потребуется установить Visual Studio . 3.      После установки VS в списке возможностей билд-агентов  должно появиться (или добавить вручную) VS , VSTest , msbuild , dotNetFramework и прочие capabilities с адресом расположения на сервере 4.      В TFS , на вкладке сборка, необходимо собрать следующие шаги (первые 2 не обязательны): 5.      В NuGet installer необходимо заполнить поля Path to Solution и NuGet arguments (если используется локальный нагет сервер) Причем в NuGet arguments нужно указать 2 адреса: локальный (-Source http://локальное расположение/Packages/nuget) и внешний (-Source https://api.nuget.org/v3/index.json ). 6.   В шаге VSTest нужно указать адрес $(build.sourcesDirectory)/Папка_автотестов/**/UnitTest.dll;-:**\obj\**  Но предварительно н...