Бурное развитие современных цифровых технологий и их глубокое проникновение во все сферы жизнедеятельности человека влечет за собой потребность в создании новых, более совершенных, программных решений, обладающих расширенным функционалом и дружественным интерфейсом.
Процесс разработки различных информационных систем, приложений и утилит, как правило, сводится к трем главным этапам:
- Определение объема предстоящих работ и детализация отдельных позиций на основании полученного технического задания.
- Осуществление проектирования и последующее кодирование структуры, алгоритмов, модулей и операций будущего продукта.
- Проверка работоспособности созданного программного решения посредством разнообразных испытаний и тестов.
Виды тестирования 1С
Для решения повседневных задач в области программирования и устранения возникших проблем при использовании программных продуктов 1С общего или отраслевого назначения, проводятся соответствующие испытания и исследования, среди которых наиболее распространены несколько видов (способов) тестирования.
Тестирование Программного Обеспечения — урок №1 — Введение
— Модульное – используется непосредственно разработчиками программы, при этом осуществляется не только проверка работоспособности модулей исходного кода (операторов, функций, ветвей, интерфейсов), но и создание необходимых драйверов. Такое тестирование легко поддается автоматизации.
— Сценарное – заключается в выполнении ранее составленных тест–кейсов (сценариев) испытаний, которые представляют собой набор действий и операций, производимых с исследуемым программным продуктом. В роли тестировщиков могут выступать сисадмины или подготовленные сотрудники.
— Регрессивное – необходимо для выявления ошибок и дефектов, допущенных при устранении ранее обнаруженных сбоев работы программы, а также после внесенных изменений или дополнений в программное обеспечение. Данное исследование может проводиться либо ручным способом, либо в автоматическом режиме.
— Приемо-сдаточное – используется непосредственно конечным потребителем и служит для проверки соответствия возможностей разработанного программного продукта с первоначальными требованиями и техническому заданию заказчика. В этом случае осуществляется тестирование только основного функционала программы.
— Нагрузочное – является нефункциональным испытанием, которое проводится с целью исследования реакции и поведения программного обеспечения в условиях пониженной, номинальной или чрезмерной пиковой нагрузки. Позволяет выявлять уязвимые места и проблемы, снижающие ожидаемую производительность программы.
Средства автоматизации тестирования программ 1С
Здесь, прежде всего, необходимо отметить, что автоматизированное тестирование обладает определенными преимуществами и достоинствами:
- уменьшение времени, затраченного на проверку работоспособности исследуемого объекта;
- снижение нагрузки на персонал, занимающимся испытаниями программного продукта;
- дополнительная проверка модулей и блоков, смежных или влияющих на корректное функционирование тестируемых объектов;
- устранение влияния «человеческого фактора» на результаты исследований.
Для основной категории пользователей продуктов 1С (профессионалы, специалисты, подготовленные сотрудники) наибольший интерес представляют собой такие инструменты автоматизированных испытаний, как приложение «Vanessa ADD» и конфигурация 1С «Сценарное тестирование».
Тестировщик с нуля / Урок 1 / Что такое тестирование по
Общие сведения о конфигурации автоматизации тестирования 1С
Данное приложение 1С: Сценарное тестирование служит для составления и выполнения специальных тесов, позволяющих проверить работоспособность любой типовой или отраслевой конфигурации 1С как в стандартном исполнении (оригинальный релиз), так и после проведенных доработок, изменений, дополнений.
Интуитивно понятный, дружественный интерфейс и методика работы с программой обеспечивают проведение тестирования пользователями, которые не обладают специальными навыками и глубокими знаниями в программировании, но имеют общее представление о свойствах испытуемой конфигурации.
Некоторые возможности приложения 1С: Сценарное тестирование:
- Пошаговое составление и редактирование теста с возможностью его немедленного выполнения.
- Составление тестов в автоматическом режиме на основе ранее зафиксированного протокола действий сотрудника.
- Имитация (программное воспроизведение) действий пользователя в интерфейсе программного решения.
- Настройка реакции на спровоцированные ошибки (продолжить, игнорировать, остановить выполнение).
- Регистрация результатов исследований с фиксацией выявленных ошибок и сбоев.
Источник: itcons99.ru
Если бы вам пришлось ответить на вопрос «Что такое тестирование?», что бы вы сказали? Это понятие довольно трудно впихнуть в пару-тройку коротких предложений.
Плюс к тому многие недопонимают, что же такое тестирование, чем занимаются тестировщики – даже среди самих тестировщиков. Тестирование как навык и как профессия постоянно развивается. В этой статье мы рассматриваем, чем тестирование является, и чем нет.
Из чего состоит тестирование
Расследование
Расследование определяется как «наблюдение или изучение путем близкого наблюдения и систематического изучения» [1].
Процесс тестирования должен быть расследованием. Мы не всегда знаем, что получим на выходе, но наша задача – выяснить информацию, которая поможет людям принимать решения. Это не просто сравнение работы системы со спецификацией, где прописан ожидаемый результат. Мы должны мыслить критически, задавать сложные вопросы, рисковать, подмечать то, что на первый взгляд кажется несущественным, а при тщательном анализе оказывается важным и требующим дальнейшего изучения.
Исследование
Список требований всегда неполон – всегда найдутся неучтенные требования, которые опущены или предполагались по умолчанию. Вне зависимости от полноты ваших требований, они всегда будут неполны. Вы не будете заранее знать, что делает ваше приложение. И тут в игру вступает исследовательское тестирование.
Исследовательское тестирование определяется как одновременное обучение, тест-дизайн и прогон тестов [2]. Тестировщик исследует приложение, узнает новую информацию, учится, находит что-то новое для тестирования по ходу дела. Он может заниматься этим в одиночку или в паре с другим тестировщиком (а может, и разработчиком).
Тестирование не должно восприниматься, как прогон списка готовых тестов или тест-кейсов, дающих твердый «pass/fail’ результат. Если у вас есть юзер-стори или набор требований, конечно, важно иметь их в виду. Однако критерии приемки бывает полезно переформулировать как «критерии отказа». Когда критерии приемки не удовлетворены, продукт не принят, но если они в порядке, это не значит, что в ПО нет багов.
Проверки и верификация должны совмещаться с исследованием и расследованием, а также вопросами в духе «Что будет, если…», на которые вы можете не знать ответа, пока не попробуете, и ответы на которые не покрыты вашими готовыми кейсами.
Снижение рисков
Одна из причин, по которой мы тестируем – это поиск дефектов, рисков и другой информации о продукте, которая позволяет нам действовать, чтобы конечный пользователь не пострадал. Мы можем:
- Исправлять баги.
- Переоценить и изменить изначальные требования.
- Помочь пользователю с продуктом.
- Создать пользовательскую документацию.
- Донести информацию об имеющихся проблемах до заинтересованных лиц.
Устранить все возможные баги, с которыми может столкнуться пользователь, просто невозможно, каким бы сложным не было ваше ПО. Однако, тестируя, мы снижаем риск того, что пользователь с ними столкнется – или серьезность последствий такого столкновения.
Ценность
Тестирование – это ценная часть разработки ПО, но его часто недооценивают из-за его непредсказуемой и креативной природы.
Результат ежедневного труда разработчика – это код, аналитика – требования или документация, однако результаты труда тестировщика может быть довольно сложно измерить. Зачастую тестировщикам сложно рассказать о своих планах, своем прогрессе и результатах. Те, кто не разбирается в тестировании, в результате плохо понимают, что было сделано, как, и почему. В итоге понять ценность тестирования сложно. В мире множество компаний, разрабатывающих ПО вообще без тестировщиков.
Отсутствие счетного результата, создаваемого тестировщиками – одна из причин, по которой некоторые предпочитают использовать тест-кейсы как способ измерения – их можно легко сосчитать. Но ценность тестирования – это намного больше, чем тест-кейсы. Исследовательское тестирование, возможно, не дает в результате набора четких кейсов, однако тестировщик находит больше интересных багов, отступая от жестких сценариев.
Отчасти поэтому людям нравятся метрики, которые учитывают количество заведенных багов, написанных и пройденных кейсов, и других вещей, которые можно сосчитать. Некоторые проекты используют эти метрики, чтобы измерять качество продукта, а также качество работы разработчиков и тестировщиков. Эти метрики концентрируются на неправильных вещах и могут вас обманывать.
Тестирование ценно на всех стадиях жизненного цикла разработки, не только когда пишется код. Вот что еще можно протестировать:
- Идеи
- Требования
- Дизайн
- Предположения
- Документацию
- Инфраструктуру
- Процессы.
Задача тестировщика – задавать вопросы, исследовать, критически размышлять над этими вещами. В результате то, что могло бы стать багом в процессе разработки, можно изловить гораздо раньше.
Коммуникация
Коммуникация – это огромная часть работы тестировщика. Тестировщики предоставляют информацию о качестве программного продукта, поэтому очень важно передавать эту информацию точно, чтобы заинтересованные лица принимали верные решения.
Человек может начать работать тестировщиком, имея слабые технические навыки, но если он силен в коммуникации и может внятно донести свою мысль – это куда важнее.
Тестировщики должны использовать правильные слова и верно строить фразы, чтобы они не были противоречивыми – так снижается риск недопонимания. То, что вы хотели сказать – необязательно то, что вы в итоге сказали, и часто люди делают допущения и в результате предпринимают неверные действия, потому что коммуникация была плохой или недостаточной.
Нам нужно регулярно общаться с людьми, играющими различные роли, находящимися на разных позициях и обладающих разным объемом знаний о продукте.
- С разработчиками, задавая им вопросы и узнавая больше о продукте, который они создают. Разработчики помогают нам вникать в технические аспекты, и им мы объясняем, что за баги мы нашли и как их воспроизвести.
- С владельцами продукта, чтобы понимать требования, задавать вопросы по сценариям использования и делиться информацией насчет этих сценариев, чтобы они могли принимать решения насчет релизов продукта.
- С тестировщиками. Если вы работаете в команде тестировщиков, очень важно общаться с коллегами, обсуждать с ними проблемы и принимать решения. Возможно, вам придется тренировать новичка или джуниора, и очень важно внятно объяснять им их задачи и помогать, если им приходится нелегко.
- С пользователями и заказчиками, чтобы убедиться, что их ожидания и их проблемы правильно поняты. Если вы помогаете им решить проблему, вы должны быть способны объяснить, как пошагово избавиться от нее, так, чтобы собеседник вас отлично понял.
- С менеджерами, чтобы сообщить, что было проделано и что осталось сделать, чтобы проинформировать их о рисках и их последствиях, а также временных рамках. Если вы предлагаете улучшения, внятно рассказывайте о своих идеях и их влиянии на продукт.
Письменная коммуникация важна не меньше устной. Создать блестяще написанную, обширную документацию, которая никому не нужна, легче легкого. Мы должны убедиться, что используем правильный способ общения в каждом конкретном случае, будь то человек, процесс или проект.
Потенциальная бесконечность
По сути, мы всегда тестируем только выборку. Каждый нетривиальный продукт обладает непредставимым количеством параметров с большим количеством возможных значений. Откуда вы знаете, что тестируете важные значения? Мы не можем протестировать все.
Часть нашей работы – принятие решений о том, что тестировать, понимание последствий того, что будет протестировано только это, и способность обосновать свой выбор.
Из чего тестирование не состоит
Простота
О тестировании часто думают как о чем-то, чем может заниматься любой. Возможно, в какой-то степени это правдиво – любой может исследовать продукт, задавать вопросы о нем, прогнать пошагово тест-кейс или проверить, соответствует ли продукт списку требований. Но чтобы делать это хорошо и систематически, нужен настоящий навык.
Нам часто говорят «пишите кейсы так, чтобы их мог прогнать любой дурак», и из-за этого создается ложное впечатление, что тестировать очень просто. Мы тупо пишем тесты согласно критериям приемки, не так ли? Но тестировщики, тестирующие свободным поиском, знают, что это не так.
Даже проверки – не такое-то простое дело. Мы принимаем непростые решения, где нужны эти проверки, и какие из них следует автоматизировать. Эти решения требуют понимания фреймворков автоматизации, навыка программирования, знания, как работает API, и владения инструментами вроде Selenium. Резюмируя, мы должны разбираться в приличном наборе технологий. Помимо этого, нам нужно знать, что нужно автоматизировать, а к чему автотесты подпускать нельзя.
Автоматизируемость
«Ручные тестировщики нам больше не нужны – мы можем автоматизировать все!» Все мы видели те или иные вариации этой фразы в Твиттере, на форумах и в статьях. Тестирование – это исследовательская, детективная деятельность, и ее невозможно заменить автоматизированными проверками. Компьютер технически не способен исследовать продукт так, как это делает человек.