На сегодняшний день многие проекты, имеющие сложную разнообразную функциональность, характеризуются очень короткими промежутками между релизами. В таких случаях приходится часто выполнять большое количество повторяющихся проверок (регрессионных тестов). Возможно, этот факт и является главной (хотя и не единственной) движущей силой активного развития автоматизации тестирования. Все больше компаний в сфере IT принимают решение оптимизировать процесс тестирования, сократив затратные по времени и финансам действия.
При этом автоматизация является довольно молодым направлением. Опытных специалистов, владеющих соответствующими навыками, как правило, не хватает. Зачастую встает задача подготовить таких специалистов самостоятельно внутри компании в разумные сроки. Однако, освоение автоматизации предъявляет высокие требования к технической подготовленности тестировщика, так как от него требуется читать и писать программный код, редактировать конфигурационные файлы, читать логи и т. д. В этой статье речь как раз пойдет о том, какие именно шаги можно предпринять для достижения нужного уровня технической подготовленности такого специалиста.
C# Программа для тестирования
Мне пришлось осваивать автоматизацию «с нуля», т. е., не имея академического образования в сфере IT, навыков программирования и практики работы в смежных «технических» направлениях (например, в системном администрировании). Теперь, уже имея опыт написания тестов на двух языках программирования (Python и Java) и продолжая совершенствоваться в сфере автоматизации, я дам рекомендации, как приобрести нужные знания и опыт.
1. Учите английский (если еще не владеете им хотя бы на уровне intermediate).
Такая рекомендация в качестве самой первой может показаться неожиданной. Дело в том, что хотя бы среднее знание английского языка является необходимым для освоения любой «технической» области в IT (автоматизация тестирования, разработка программного кода, системное администрирование). Большая часть документации, полезных статей, обсуждений на форумах и площадках наподобие stackoverflow, как и большинство обучающих онлайн-курсов и программ, записаны на английском языке (даже если он не является родным для автора).
Фактически, знание английского является международным стандартом в сфере IT. Соответственно, владение им открывает для вас широкие возможности. Я не случайно подчеркнул – «хотя бы на уровне intermediate». Важен не только высокий уровень владения языком (хотя среднего уже достаточно для решения многих задач), но и то, что изучение литературного или разговорного языка всегда происходит дольше, чем изучение языка программирования или технологии.
Научиться писать несложный программный код, который действительно выполняет полезные задачи, можно за пару-тройку месяцев. Освоить хотя бы элементарный уровень владения иностранным языком за это же время гораздо сложнее. Если вы еще не владеете английским, то начните изучать его прямо сейчас . Да, это займет время. Но каждое новое слово, которое вы запомните, поможет вам лучше понимать документацию и обсуждения.
Создание теста по программированию на языке c#.
2. Учитесь читать код.
Прежде чем вы напишете что бы то ни было реально работающее и решающее полезные задачи, вам придется читать, а именно просматривать строки кода и логи, пытаться понять, что идет не так при отладке тестов. При этом навык чтения кода будет универсален, так как многие базовые идеи и понятия являются общими для большинства современных языков программирования: объявление переменных, типы данных (строка, целое, булевские значения «истина/ложь» и т. д.), массивы и условные конструкции (if/else).
С чего же начать развивать навык чтения? Желательно, с несложных вещей. Например, просматривая очередную веб-страничку, нажмите Ctrl+U и попытайтесь изучить структуру html-кода, который увидите. При этом не важно, чтобы вы поняли все. Разберите небольшой фрагмент, поищите описания тегов.
С одной стороны, html является языком разметки (не языком программирования), потому относительно несложен для понимания. С другой стороны, это хорошее подготовительное упражнение, так как при написании автоматизированных тестов, исполняемых через графический интерфейс в браузере (самая обширная область автоматизации на сегодня и вместе с тем самая несложная в освоении), вам придется часто просматривать html-код странички. Это пока не программирование, но уже чтение кода, при котором глаза привыкают искать нужную строчку и анализировать структуру.
3. Учитесь писать код.
Следующим вашим шагом должно стать освоение несложного онлайн-курса по программированию для начинающих, при прохождении которого вы будете делать самые простые базовые операции, сопровождаемые подробными комментариями. На сегодняшний день выбор обучающих ресурсов довольно обширен. Попробуйте поискать по запросам «programming for kids», «online coding courses for beginners».
Я рекомендую ресурс codecademy . Курс по языку Python , пройденный на этом сайте, позволил мне без особенных проблем написать тесты для первого проекта. Могу с уверенностью сказать, что форма обучения на нем удобна, а задания не слишком сложны для понимания новичком. Вообще, при возможности начните с изучения Python . Это серьезный язык программирования со всей широтой возможностей, его синтаксис несложен, и код хорошо читается.
Но не бойтесь «великого и ужасного» языка JAVA! В нем сначала пугает разнообразие модификаторов (public, protected, private) и строгая типизация (вы должны сразу указать, что именно хранится в переменной: строки, числа и т. д.). Однако, если вы все свои тестовые классы и методы объявите public («нет ограничений доступа»), то с большой вероятностью не изменится НИЧЕГО. Что касается типизации, то вы почти всегда в своем тесте знаете, что хотите получить: строку текста или число, true/false или еще что-то. Так что это тоже не вызовет проблем.
4. Запишите свои первые тесты рекордером и преобразуйте их в код.
Есть вспомогательные инструменты для записи тестов – так называемые рекордеры (например, Selenium IDE и Selenium Builder ). Вы можете установить их, запустить перед тем, как начнете записывать тест, и далее выполнять необходимые манипуляции в браузере. Ваши действия будут записаны в виде последовательности несложных команд. Вы можете сохранить эту последовательность и запускать для самостоятельного повторения браузером вашего теста. Даже на таком уровне легко производится автоматизация рутинных проверок и уменьшается количество ручной работы. Прелесть этих инструментов заключается и в том, что вы довольно быстро понимаете – писать код самому удобнее.
Составив первые тесты с помощью рекордера, проанализируйте последовательность полученных команд. Попробуйте самостоятельно ввести какие-либо действия или изменить существующие. Это удивительно, но как только вы выделите часто используемые команды и проанализируете их характерные последовательности, вам сразу станет удобнее добавлять их самому, не прибегая к автоматической записи.
Следующим вашим шагом станет преобразование инструкций записанного теста в язык программирования. Selenium IDE и Selenium Builder дают такую возможность. Проанализируйте сгенерированный код. Вы обнаружите, что многие фрагменты текста весьма похожи на уже знакомый и понятный язык команд рекордера, просто они уже включены в конструкции выбранного языка программирования.
С высокой вероятностью будет найдено некоторое количество ошибок и недочетов в последовательности действий. Это нормально. Механизм преобразования пока не идеален. Но вместе с тем, обнаружив такие ошибки, вы получите возможность их исправить и обретете уверенность в понимании кода.
Как только вы сами нашли ошибки в нескольких тестах и сумели их исправить, восстановив желаемую последовательность действий, рекордер становится вам практически не нужен. Таким образом, у вас есть все для того, чтобы продолжить писать тесты на языке программирования, обращаясь к самостоятельно подготовленным фрагментам кода.
5. Начните покрывать автотестами план регрессионного тестирования.
Эта рекомендация касается не только процесса освоения знаний в области автоматизации. Важно, чтобы ваши усилия по приобретению этих знаний не оказались напрасными на данном конкретном проекте. Ускорение прохождения регрессионных тестов – самое часто встречающееся применение автоматизации на сегодняшний день, хотя и не единственное.
Нужно быть готовыми к тому, что конкретные цели и задачи, которые ставятся перед специалистами по автоматизации, не всегда четко обозначаются в самом начале работы. Вам потребуется время, чтобы выявить потребности конкретного проекта и сделать это нужно обязательно. Но даже до тех пор, пока задание не прояснится в полной мере, вы уже сможете получить полезные результаты с помощью автоматизации регрессионных тестов, продолжая оттачивать свои навыки. Если вы сумеете обнаружить другие области, где применима автоматизация для вашего проекта (например, создание тестовых данных, подготовка тестовых окружений), ваша полезность только увеличится.
6. Пройдите обучающие курсы.
Выберите, например, курсы Алексея Баранцева (известного специалиста по автоматизации в РФ), курс от компании Luxoft или любой другой, где тренер поможет вам разобраться с материалом. Это сэкономит время (и ваше личное, и вашего проекта) в тех нередких случаях, когда вы будете привлечены к участию в автоматизации тестирования, не обладая нужными знаниями. Поинтересуйтесь, возможно, ваш проект согласится оплатить эти курсы. В любом случае, решающая роль остается за вашей готовностью к самостоятельной работе.
7. Общайтесь с коллегами.
Не стесняйтесь спрашивать, общайтесь с коллегами-автоматизаторами регулярно и независимо от уровня ваших знаний. Например, создайте общий чат, найдите тематический форум или группу в соцсетях. Обсуждайте решения.
Вы можете писать тесты на разных языках либо использовать разные фреймворки запуска тестов одного языка, но алгоритмические и архитектурные решения все равно будут иметь много общего. Кто-то будет знать больше вас – он может подсказать вам. Кто-то весьма вероятно будет знать уже меньше вас – вы сможете подсказать ему и еще раз уложить знания по вопросу в голове.
8. Улучшайте свой стиль написания кода.
Первый код, который вы получите с помощью конвертации, будет представлять собой простую последовательность элементарных команд, содержащую повторяющиеся фрагменты. Он окажется не очень удобным для понимания, когда вы проанализируете его по прошествии времени. К тому же, он будет неудобным для поддержки, ведь одно и то же изменение придется вносить в несколько разных мест. Вы столкнетесь с так называемым «спагетти-кодом», т. е. плохо структурированным, неудобным для работы.
Чтобы улучшить его качество, рекомендую выполнить следующие действия:
- Выявить повторяющиеся последовательности действий и вынести их в отдельные методы. Давайте методам понятные осмысленные названия (например, для метода, нажимающего кнопку поиска, хорошим названием будет clickSearchButton() ). Этим достигается более компактная и понятная запись теста, а также возможность при необходимости вносить изменения только в одном месте (например, если изменится веб-элемент, представляющий нажимаемую кнопку).
- Комментировать код. Это облегчит его понимание и вам, и тем, кто его будет просматривать после вас.
- Изучить и применить шаблон проектирования тестов Page Object. На сегодняшний день это стандарт при разработке автоматизированных тестов.
- Уделить время знакомству с принципами ООП (объектно-ориентированное программирование), так как именно этот подход используется для паттерна Page Object.
Выполнение этих рекомендаций поможет написать удобный в поддержке код, понятный вам и вашим коллегам-автоматизаторам.
В заключении
Хочу еще раз отметить, что самое главное – это ваша готовность регулярно самостоятельно учиться и находить ответы. Вы часто будете сталкиваться с новыми вопросами, ответы на которые только предстоит узнать, и никогда не будете знать достаточно. Но этот факт совершенно не мешает развиваться в области автоматизации и разрабатывать интересные и полезные решения.
Поэтому не ограничивайте себя в выборе задач теми областями, что вы уже знаете. Выбирайте новую интересную задачу и приобретайте необходимые знания в процессе ее решения. Именно такой подход позволит вам быстро продвигаться вперед и становиться профессионалом в выбранной области.
Источник: quality-lab.ru
Как написать программу тестирования знаний
Тесты и тренажеры для тестировщиков
Специалисту сложно оценить собственные знание: многое понятное кажется очевидным, а непонятное — недостижимым. А в вакансиях часто пишут «уверенное знание Java» или «опыт работы с Git». Но как оценить, достаточно ли знаний для работы?
Для того, чтобы облегчить вам жизнь, мы создали несколько тестов по наиболее популярным технологиям. Они помогут вам найти пробелы в ваших знаниях или убедиться в их отсутствии.
Если вы смогли пройти один из тестов на отлично — можете смело заявлять о базовых знаниях инструмента в своем резюме.
Наши выпускники знают ответ на каждый из этих и еще много других вопросов. И умеют применять знания на практике. Попробуйте и вы 🙂
Источник: www.learnqa.ru
Что такое тест план и как его написать?
Согласно стандарту IEEE 829, тест план должен состоять из 19 пунктов:
- Идентификатор тест плана
- Ссылки
- Введение
- Объекты тестирования
- Проблемы и риски
- Функции, которые нужно протестировать
- Функции, которые НЕ нужно тестировать
- Подходы
- Критерии прохождения тестов для объектов тестирования
- Критерии остановки и требования для возобновления тестирования
- Результаты тестирования
- Оставшиеся задачи тестирования
- Требования среды
- Требования по части кадров и их обучения
- Распределение обязанностей
- Расписание
- Планирование рисков и непредвиденных обстоятельств
- Утверждение
- Глоссарий
Хорошо написанная документация — залог эффективного тестирования. Она структурирует тестирование и привносит в него определенную логику. В некотором смысле документация объединяет членов команды вокруг поставленной цели, обеспечивая четкое понимание иерархии, задач и ожидаемых результатов.
Одна из важных частей документации — тест план.
В этой статье мы рассмотрим:
- что из себя представляет тест план
- чем он отличается от стратегии тестирования
- какова его роль в проекте
- какие виды тест планов бывают
- зачем команде нужен тест план
- и, самое главное, как его составить.
Прежде чем приступить к определениям и объяснениям, мы хотели бы объяснить еще один важный термин из сферы QA — артефакт тестирования.
Артефакты тестирования — побочные продукты, генерируемые в процесса тестирования ПО и использующиеся совместно с командой проекта. Проще говоря, это документы, которые помогают наладить коммуникацию между всеми участниками проекта.
А теперь давайте перейдем непосредственно к тест плану.
Что такое тест план?
Тест план — это артефакт тестирования, описывающий действия, которые будут происходить в процессе тестирования — от разработки стратегии до критериев поиска ошибок. Он также описывает логику завершения задач и оценку рисков со сценариями их разрешения.
Структура тест плана
Тест план имеет четкую структуру, установленную IEEE 829 — отраслевым стандартом для документации тестирования программ и систем. Это значит, что вы можете подготовить шаблон и использовать его для любого проекта, заполняя конкретными данными.
Создание тест плана в соответствии со стандартом IEEE 829 дает много преимуществ. Прежде всего, когда структура документа всем известна, такой документ и составлять легче, и пользоваться им проще. Стандарт IEEE 829 устраняет любые бесполезные дебаты относительно того, что включать в тест план и в каком порядке. Вместо этого тестировщики могут сосредоточиться на других, более важных вещах.
1. Идентификатор тест плана
В этом разделе мы указываем название и логотип компании, проводящей тестирование, название документа, его версию и год создания. Это титульная страница вашего тест плана.
2. Ссылки
Дальше идет история документа. Добавьте таблицу изменений со следующими столбцами:
С помощью этой таблицы команда сможет эффективно фиксировать и отслеживать изменения в документе и процессе, который он описывает.
3. Введение
Здесь мы кратко обозначаем, что собираемся делать. Введение — это пояснительная записка для клиента. В паре предложений опишите, какие услуги предоставит команда QA и зачем. Например:
«Наша компания осуществляет функциональное и UI-тестирование для выявления ошибок в программном продукте до выпуска. Мы выполняем тщательное тестирование заявленных функциональных возможностей, чтобы помочь достичь заданных целей бизнеса для вашего программного продукта».
Включите все виды тестирования, которые вы согласились осуществить, но не входите в детали. На этом этапе достаточно обозначить все в общих чертах.
4. Объекты тестирования
5. Проблемы и риски
В этом разделе мы описываем проблемы, с которыми команда может столкнуться во время тестирования. Например, если дедлайн установлен на летний период, разумно предположить, что люди могут уйти в отпуск, из-за чего возможны задержки. Здесь нужно упомянуть все значимые проблемы и риски: как связанные с кадрами, так и технологические аспекты.
6. Функции, которые нужно протестировать
Эта часть охватывает то, что, по мнению большинства людей, и должно быть в тест плане: подробный список функций для проверки и время, за которое они должны быть проверены.
Например, в «Объектах тестирования» мы упомянули функциональное тестирование. Тогда в функциях, которые необходимо протестировать, мы должны перечислить отдельные компоненты потока: ввод информации о доставке, выбор способа оплаты, подтверждение заказа и т. д. Что касается времени, клиент и компания, проводящая тестирование, обсуждают его до написания документации.
7. Функции, которые не нужно тестировать
Здесь вы перечисляете функции, которые тестировщики по каким-то причинам не будут тестировать. Неважно, почему вы не покрываете тестами эти фичи. Просто не забудьте указать, какие именно функции не охватываются тестированием и остаются в зоне ответственности клиента.
8. Подходы
Затем мы описываем методы и виды тестирования, которые будем применять. В этот раздел также включаются тест-кейсы. Благодаря этому клиент может получить полную картину действий по тестированию.
9. Критерии прохождения тестов
Каждый тест-кейс будет обозначен как «Pass» (пройден) или «Fail» (провален) в зависимости от двух критериев:
- Наличие и серьезность багов
- Уровень успешно выполненных требований.
И не забудьте определить критерии начала и окончания тестирования.
Критерии начала — то, что должно быть и что нужно сделать до начала тестирования. Например, вам могут понадобиться:
- законченная справочная документация
- программный продукт в том виде, в котором его будут получать клиенты
- специальные программные утилиты, конфигурационные файлы или данные
- требования к продукту и прочая документация и т.д.
Критерии начала тестирования служат для определения готовности или неготовности к тестированию. Будет полезно составить список того, что будет использоваться в качестве входных данных, и запросить материалы, необходимые для выполнения тестов.
Критерии окончания тестирования — это то, что вы считаете необходимым для завершения процесса тестирования. Тестировщики часто стараются сделать критерии окончания тестирования условием для поставки ПО, но это не реально. Это решение принимает собственник продукта (или другое ответственное лицо).
Пример критериев окончания тестирования:
«Все запланированные тесты проведены, все исправленные баги отмечены, сделаны уведомления обо всех новых обнаруженных багах. Все точки отказа (например, провал определенного набора тестов из-за неисправности железа) задокументированы».
10. Критерии остановки и требования для возобновления тестирования
Критерии остановки/возобновления описывают ситуацию, когда тестирование невозможно продолжать из-за найденных багов. Другими словами, если дела идут так плохо, что запланированные тесты нельзя провести, тестирование нужно остановить до устранения блокирующих багов.
11. Результаты тестирования
Чтобы засвидетельствовать результаты проведенной работы, мы отправляем их клиенту. Обычно результаты тестирования оформляют при помощи различных показателей: количество завершенных тестов, найденные баги и т.д. В некотором смысле эти показатели — индикаторы качества тестирования, хотя и не должны быть единственным критерием для оценки проделанной работы.
12. Оставшиеся задачи тестирования
Жизненный цикл ПО может быть непредсказуемым. Иногда проверка продукта занимает больше времени, чем первоначально ожидалось. Если времени мало, некоторые части функциональности могут оставаться непроверенными. В таком случае команда включает оставшиеся задачи в тест план. Кроме того, в этом разделе можно описать масштаб необходимой работы на случай, если все задачи будут закрыты до дедлайна.
13. Требования среды
В целом, в этом разделе описывается, что нужно для тестирования по части аппаратного обеспечения. Здесь мы перечисляем и инструменты, используемые для тестирования.
При необходимости вы можете описать какое-то особое оборудование и его функционал. Например, если в связи со спецификой проекта вам потребуется использовать комплект VR или какие-то специфические устройства, которые нужно приобрести.
14. Требования по части кадров и их обучения
Если мы получим задачу тестирования ПО для ядерных реакторов, вполне вероятно, что команда не будет полностью понимать специфику. Это, конечно, преувеличение. Но если команда должна протестировать проект из сферы, с которой они не знакомы, имеет смысл провести лекцию или краткий обучающий курс от экспертов. Это поможет тестировщикам понять особенности проекта и сделает их работу более эффективной.
15. Обязанности
В этом разделе описываются сферы ответственности каждого члена команды QA. Удобно составить таблицу с тремя столбцами — имя, должность и обязанности.
16. Расписание
Тест план должен также включать дедлайны. Команде нужно как-то оценивать скорость работы. Для этого им нужно знать, сколько времени отводится на тестирование. Если есть несколько этапов тестирования, нужно расписать их порядок и сроки.
17. Планирование рисков и непредвиденных обстоятельств
Этот раздел перекликается с п. 5 «Проблемы и риски». Здесь, в дополнение к перечню рисков, мы предоставляем разъяснения о том, как справиться с этими рисками, и что делать в случае форс-мажорных обстоятельств.
18. Утверждение
Каждый тест план должен содержать информацию о том, кто его составлял (имя, должность), и о том, кто его должен одобрить и дать команде зеленый свет на его использование.
19. Глоссарий
В этом разделе вы можете пояснить основные термины, используемые при написании тест плана. Глоссарий помогает предотвратить неправильное толкование используемой терминологии.
Виды тест планов
Несмотря на стандартную структуру, существует несколько типов тестовых планов. Они отличаются особенностями описанных задач и объемом работ. QA-команды, как правило, используют следующую классификацию:
Тест планы по уровням — планы модульного, интеграционного, системного, приемочного тестирования
Тест планы по типам — планы функционального тестирования, тестирования производительности или юзабилити, план автоматизированного тестирования и т.д.
Мастер тест план — это комплексный план тестирования. Включает высокоуровневую информацию, которая не часто меняется в ходе тестирования и требования к которой не часто пересматриваются.
По сравнению с простым тест планом мастер тест план более статичен. Это ключевое различие. Как правило, команда проекта использует один мастер тест план и несколько более подробных тест планов для разных уровней или типов тестирования, в которых описываются отдельные модули одного приложения.
Вы можете создать тест план любого типа без использования каких-то особых инструментов. Вам может повстречаться выражение «Инструменты управления тест планами», но это неточная формулировка. Тест план — это документ, и единственный инструмент, который вам нужен для управления им, это текстовый редактор. Обычно речь идет об инструментах управления тестированием, таких как TestRail, TestPad, Qmetry, KualItee и т. д.
Тест план и стратегия тестирования — в чем разница?
Многие считают, что разграничить тест план и стратегию тестирования сложно. Тем не менее, это два разных документа. Тест план более подробный и охватывает больше аспектов, чем стратегия тестирования. Последняя часто используется на организационном уровне и редко меняется. Между тем тест план более динамичен и используется на уровне проекта.
Стратегия обычно является частью плана.
Существует также QA-стратегия, которая выходит за пределы тестирования и охватывает другие виды деятельности и методологии обеспечения качества.
Итоги
Как видите, тест план — объемный, часто сложный в написании, но очень важный артефакт тестирования. Он хорошо структурирует процесс тестирования, предотвращая много стрессовых ситуаций и недоразумений. Более того, тест план помогает всем членам команды быть в курсе происходящего, поскольку все заинтересованные стороны имеют к нему доступ.
Написание тест плана требует сильных аналитических навыков, внимания к деталям, а также способности продумывать действия на несколько шагов вперед. Но результат стоит свеч.
В общем, даже если написание документации кажется менее интересным, чем тестирование, только вместе они делают процесс QA эффективным.
Источник: testengineer.ru