Введение в работу тестировщика программного обеспечения
Что первое, что приходит на ум, когда вы думаете о работе по тестированию программного обеспечения? Некодирующая работа? Или профессия, которая очень проста, поскольку она дает вам возможность находить ошибки в работе других (поиск ошибок, когда в других - самая легкая задача для всех нас)? Или вы думаете об этом как о профессии, которая занимается проверкой правильности продукта? Все эти мысли верны и являются повседневной деятельностью для тестировщика программного обеспечения. Однако тестирование программного обеспечения не ограничивается только этими действиями.
Понимание приложения
Приложение может быть из любой области - здравоохранение, страхование, финансы и т. Д. Изучение области приложения очень важно для любой работы программного обеспечения, чтобы открыть двери для размышлений с разных точек зрения и с разных точек зрения пользователя при тестировании приложения. Выявление и проверка очевидных и не очень очевидных путей применения всегда является основным ожиданием от этого. Глубокое знание приложения помогает эффективно проверять продукт, в то же время тестер может стать активом проекта, в котором он / она рассматривается как один из основных источников знаний о поведении продукта.
Хотя изучение предметной области и функциональности является непрерывным процессом для любого другого важного фактора, имейте знания о процессе тестирования
Процесс тестирования
Процесс тестирования может варьироваться от этой компании к компании или даже от одного проекта к другому. Сегодня у нас есть различные модели разработки программного обеспечения, такие как модель V, модель прототипирования или совершенно другая методология, такая как Agile-подход к разработке программного обеспечения. С изменением модели разработки подход к тестированию также меняется. Работа в модели V будет иметь четко определенные процессы, в то время как работа в гибкой методологии, как ожидается, будет тестироваться в постоянно меняющихся условиях.
Работа еще не прошла гладко, если у вас есть приемлемые знания предметной области и понимание процесса тестирования. Следующая трудность, с которой приходится сталкиваться, заключается в изучении различных инструментов.
инструменты
Инструменты подразумевают инструменты управления тестированием, инструменты регистрации дефектов, инструменты управления базами данных и так далее.
При наличии различного программного обеспечения для регистрации дефектов, его качества и инструментов, некоторых с открытым исходным кодом и некоторых лицензированных, всегда полезно знать о нескольких инструментах. Это помогает легко переносить проекты или команды, следуя различным инструментам. Обладая достаточным знанием предметной области, процессов и инструментов, в жизни Software Tester есть еще кое-что, что делает его / ее рабочие дни сложными и захватывающими. Сотрудничество внутри команд является одним из важных факторов успеха любого проекта, и для эффективного сотрудничества коммуникация играет очень важную роль.
Рекомендуемые курсы
- Полный курс J2EE
- Онлайн обучение программированию на R
- Go курс программирования
- Сертификационный онлайн-тренинг по программе Haskell
связь
Коммуникация играет очень важную роль для программного обеспечения, поскольку она качественна, поскольку на начальных этапах разработки программного обеспечения члены группы тестирования (в качестве передовой практики) участвуют в обсуждении требований, опрашивая бизнес-аналитиков в случае каких-либо запросов или пробелов в требовании. Tster с эффективными коммуникационными навыками может эффективно сообщать о рисках, может эффективно общаться с командой разработчиков и может эффективно передавать результаты испытаний и отчеты о тестировании.
Планирование работ по тестированию программного обеспечения
Как следует из названия, планирование тестирования - это фаза, на которой проводится подготовка к тестированию. Подготовка к тестированию будет включать различные типы действий, которые выполняет тестер для эффективного применения. Это поможет в проверке приложения и эффективном выявлении дефектов в приложении. Чтобы начать планирование, тестируемый проходит требования, чтобы понять ожидания.
1. Требования
Требования могут быть предоставлены группе тестирования в виде каркасов, раскадровок, листов Excel. Цель всех этих документов - представить требования клиента эффективным и простым для понимания способом. Каркасный документ - это не что иное, как документ, который может быть в форме презентации PowerPoint, которая отображает требования клиента. В тех же строках раскадровки обычно отображают требуемый вид / дизайн экранов. В настоящее время на рынке доступны различные инструменты, которые можно использовать для подготовки необходимых документов. Создание необходимых документов является основной обязанностью бизнес-аналитика. Предполагается, что дегустатор будет полностью понимать требования. Для того, чтобы тесты, а также разработчики правильно поняли требования, бизнес-аналитики держат форум открытым для всех, чтобы поднять и получить ответы на вопросы по любому из требований. Платформа для обсуждения и обсуждения открытых вопросов и запросов варьируется от проекта к проекту. Это может быть цепочка сообщений электронной почты, конференц-связь или даже хранилище общих дисков, которое отслеживает все открытые вопросы и ответы на них, предоставленные бизнес-аналитиком.
Четкое общение и запись общения играют очень важную роль для доказательства. Небольшое допущение в требовании иногда может привести к серьезному дефекту продукта. На каждом этапе рекомендуется, чтобы специалист по тестированию программного обеспечения поддерживал связь в чистоте. Software Tester Рабочее общение может быть с бизнес-аналитиками или даже внутри команды. Четкое общение помогает не допускать предположений во время планирования и выполнения. В то же время рекомендуется иметь запись о связи (желательно по электронной почте). Наличие письменного сообщения о запросах в требованиях помогает на более поздних этапах выполнения теста, когда функциональность может быть не разработана, как подтверждено в записанном сообщении.
2. Сценарий
Когда требования понятны, тестер начинает документировать сценарии в документе «Сценарий тестирования». Сценарий, как следует из названия, представляет собой поток функциональных возможностей, которым следует пользователь для выполнения задачи.
Примеры сценариев -
- Пользователь должен иметь возможность успешно войти в систему.
- Пользователь должен иметь возможность бронировать билеты в системе.
- Пользователь должен иметь возможность отменить билеты в системе.
- Пользователь должен иметь возможность просматривать / обновлять данные профиля.
Это логические задачи, которые пользователь выполняет в системе. Эти логические задачи, сгруппированные вместе, помогают запоминать все возможные сценарии, которые пользователь должен выполнить. Эти сценарии обычно документируются в таблицах Excel или иногда с использованием некоторых инструментов. Преуспевающий человек извлекает все такие сценарии из документов требований. Документ, содержащий такие сценарии, называется Документ сценария тестирования (или где-то как Документ сценария высокого уровня). Этот документ служит входным документом для составления тестовых примеров.
3. Дело
Этот случай является более подробной версией рабочего сценария Software Tester, где сценарий разбит на более подробные шаги, которые пользователь фактически выполнит при использовании приложения. Простой пример, основанный на вышеупомянутых сценариях:
Сценарий - пользователь должен иметь возможность успешно войти в систему.
Тестовые случаи:
- Убедитесь, что пользователь может ввести правильное имя пользователя.
- Убедитесь, что пользователь может ввести пароль.
- Проверьте, нажимая кнопку «Вход» после ввода правильного имени пользователя и пароля, пользователь может успешно войти в систему.
Такой список этих случаев может включать проверку правильности каждого поля, проверку отрицательных сценариев и так далее.
Ниже приведены некоторые дополнительные примеры этих случаев -
- Убедитесь, что имя пользователя, если оно не введено, система выдает соответствующую ошибку.
- Если пароль не введен, система выдает соответствующую ошибку.
- Убедитесь, что имя пользователя и пароль, если они не введены, система выдает соответствующую ошибку.
- Убедитесь, что при вводе неверного пароля система выдает соответствующее сообщение об ошибке.
- Убедитесь, что при вводе неверного имени пользователя система выдает соответствующее сообщение об ошибке.
4. Матрица прослеживаемости требований (RTM)
Матрица прослеживаемости требований, как следует из названия, помогает проверить и включить охват требований, предоставленных Business, в документы тестирования, такие как сценарии и контрольные примеры.
В качестве наилучшей практики это отдельный документ, в котором показано сопоставление номера требования со сценарием / случаем, включающим это требование.
Этот документ может использоваться не всеми типами проектов, но при его использовании он помогает надежно проследить высокоуровневые сценарии, соответствующие требованиям. Он указывает на покрытие и может быть использован для проверки наличия хотя бы одного из этих случаев в отношении каждого требования. Создание и поддержка RTM-документа считается наилучшей практикой, однако не во всех видах проектов (например, Agile) используется документ Software Pro Work. Когда требования меняются очень часто, ведение этого документа может быть подслушано. Чтобы избежать этих издержек и в то же время иметь способ отслеживания требований, некоторые проекты включают часть прослеживаемости в рабочий сценарий Software Tester или сам документ сценария.
Важный аспект заключается в том, чтобы иметь возможность проследить сценарии / случаи до требований и наоборот. Хорошо документированные требования облегчают задачу создания и ведения этих документов в Prover. Неоднозначные требования, постоянно меняющиеся требования усложняют жизнь доказателей и могут привести к непоследовательности поставляемых документов, что приведет к пропуску некоторой проверки и, следовательно, к дефекту в конечном продукте.
Поездка до сих пор для тестировщика планировалась и готовилась к тестированию. Поскольку подготовка к войне является частью войны, то же самое применимо и здесь. Чем лаконичнее создаются эти документы, тем легче проверяющему проверить функциональность и обнаружить почти все дефекты. Следующим этапом путешествия тестера является выполнение.
Выполнение программных тестеров
На этом этапе все вышеперечисленные документы вводятся в действие. Требования были использованы для создания сценария, сценарий - для его создания. этот документ дела является самодостаточным документом для начала проверки приложения. Prover начинает проверку приложения, выполняя шаги из этого кейс-документа. Несколько этих случаев могут использоваться для проверки одного сценария, или даже один контрольный пример может соответствовать одному сценарию тестирования. Все зависит от сложности сценариев или, иногда, от стандарта, применяемого в группе тестирования. Следовательно, один документ теста может содержать 20-50 тестов или 100-120 тестов. Эти цифры приведены только для пояснения, они могут сильно отличаться от проекта к проекту. Результатом этого этапа являются тестовые дефекты. Количество действительных дефектов, выявленных на этом этапе, дает хорошее представление о стабильности приложения, качестве тестирования, качестве сборки и многих других факторах, которые напрямую влияют на продукт. Этот этап является наиболее важным этапом, поскольку тестировщик успешно охватывает все тестовые случаи (проверяет почти все необходимые пути пользователя) и в то же время выявляет как можно больше допустимых дефектов. Все подготовительные, коммуникативные навыки, запросы, запрашиваемые для бизнеса, вступают в действие на этом этапе тестирования.
Тестер программных дефектов работает
При выполнении этого случая любое поведение, которое не равно ожидаемому результату, возбуждается как Дефект. Каждый тестовый пример имеет описание, ожидаемый результат и столбец для фактического результата. В то время как эти планы Software Work Tester Work содержат описание и ожидаемые результаты, а также пустой столбец для фактических результатов. При выполнении тестовых случаев тестер должен заполнять столбец фактического результата. В то же время, если фактическое значение не равно ожидаемому результату, дефект регистрируется. Регистрация дефекта просто не означает информирование разработчика о проблеме. Это опять-таки формальный процесс, обычно выполняемый с помощью инструмента. В настоящее время на рынке существуют различные инструменты, некоторые с открытым исходным кодом, а некоторые по лицензии. Любой инструмент регистрации дефектов имеет следующие поля -
- Название проекта / релиза
- Краткое описание дефекта
- Дефект Детальное описание
- Степень серьезности дефекта
- Приоритет дефекта
- Фаза дефекта была найдена
- Назначено
- Вложения
Как мы видим, цель всех этих полей состоит в том, чтобы формально обработать детали найденной проблемы. Это помогает разработчикам воспроизвести дефект в своей среде и исправить его. Ниже приводится краткое описание всех этих полей -
- Название проекта / выпуска - имя выпуска, в котором обнаружен дефект, обычно проект имеет несколько выпусков, и один и тот же проект может иметь несколько подпроектов. Это поле помогает поднять проблему для определенного выпуска.
- Краткое описание дефекта - краткое однострочное описание найденного дефекта.
- Подробное описание дефекта - это подробное описание дефекта, оно должно включать такие детали, как среда, в которой обнаружен дефект, и используемые данные испытаний, фактические результаты, ожидаемые результаты, и любая дополнительная информация, которая добавляет заинтересованным сторонам более ценную информацию для понимания дефект.
- Серьезность дефекта - показывает, насколько серьезен дефект. Обычно он имеет значения, аналогичные критическим, высоким, средним, низким или числовым, например 4, 3, 2, 1.
- Приоритет дефекта - показывает, насколько срочно необходимо устранить дефект.
- Этап обнаружения дефекта - поскольку существует много этапов, когда дефект может быть зарегистрирован, этап модульного тестирования, SIT (тестирование интеграции системы), UAT (приемочное тестирование пользователя) или даже этап производства.
- Назначено - Имя разработчика или руководителя разработки.
- Вложения - это дает возможность тестеру прикрепить снимок экрана, на котором возникла проблема.
Выполнение теста и регистрация дефектов - это этап, на котором тестер может столкнуться со многими проблемами. Некоторые из них эффективно общаются с разработчиками. Можем ли мы утверждать, что регистрация дефекта со всей необходимой информацией недостаточна для разработчиков, чтобы понять дефект?
Это и в некоторых случаях требует дополнительного объяснения / обсуждения с разработчиками. Есть случаи, когда тестировщик сталкивается с неожиданным поведением, которое он / она не может быть уверен, если это дефект. С этими обстоятельствами обычно сталкиваются проверяющие, которые являются новичками в команде, имеют ограниченные знания предметной области или имеют двусмысленность в отношении требований. Ну, тестер не должен быть обвинен здесь, если есть сжатые сроки и есть постоянно меняющиеся требования, и в большинстве случаев доказательство узнает о домене, фактически планируя и выполняя тестовые случаи. Как мы видим, путь тестера не так прост, как кажется. Это требует постоянного обучения, хороших навыков общения, навыков сотрудничества и стремления приспособиться к условиям, в которых происходят изменения в областях, инструментах и используемых процессах. В то время как мы говорили о путешествии ручных тестеров, общий процесс относится и к автоматизированным тестерам. Автоматизация, с другой стороны, претерпевает значительные изменения в процессе, поскольку объемы тестирования и планирования существенно различаются.
Рассматривая продвижение провайдера, как обсуждалось выше, можем ли мы все же сказать, что работа тестировщика качеств программного обеспечения проще, чем работы разработчика?
Можно сказать, что помимо сравнения ролей тестера с разработчиком будет более полезно обсудить, как совместная работа двух может привести к значительному успеху продукта в целом. Иногда мы забываем, что работа тестировщика состоит в том, чтобы находить проблемы в приложении, а не указывать на ошибки разработчиков. Когда мы забываем саму идею нашей работы, это иногда приводит к ненужной дискуссии. Тем не менее, было замечено, что есть такие же хорошие команды тестирования, где все понимают, что конечная цель - заставить приложение работать так, как ожидается. Будем надеяться, что все будут смотреть на положительную сторону работы по тестированию как на роль, которая помогает в очистке продукта, а не на ту, которая просто находит ошибки!
Рекомендуемые статьи
Это руководство для выявления и подтверждения очевидных и не очень очевидных путей применения - всегда главное ожидание от работы тестировщика программного обеспечения. Это следующая внешняя ссылка, связанная с работой тестировщика программного обеспечения.
- Жизненный цикл дефекта при тестировании программного обеспечения
- 6 самых удивительных вопросов для интервью по тестированию программного обеспечения
- Карьера в тестировании программного обеспечения