Для чего тестировщику git

double-trouble2 / QA Engineer

This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters. Learn more about bidirectional Unicode characters

QA engineer/тестировщик

SCRUM

SCRUM-митинги

Делать по ходу спринта несколько версий сборок

у каждого члена команды не может одновременно находиться в работе, например, более двух задач, а общее число задач в тесте и готовых для проверки не может превышать (тоже например) шести в каждом случае, если в команде три разработчика.

Persistency

Баг-трекер

Stakeholders(тестовой группы заказчика )

Test Management — планирование работ

Test Design — проектирование тестов

Test Execution — выполнение тестирования

Test Analysis — анализ полученных результатов

Verification — Верификация, это процесс оценки системы или её компонентов с целью определения удовлетворяют ли результаты текущего этапа разработки условиям, сформированным в начале этого этапа [IEEE]. Т.е. выполняются ли наши цели, сроки, задачи по разработке проекта, определенные в начале текущей фазы.

Validation — Валидация, это определение соответствия разрабатываемого ПО ожиданиям и потребностям пользователя, требованиям к системе [BS7925-1].

Test Plan – План Тестирования, это документ, описывающий весь объем работ по тестированию, начиная с описания объекта, стратегии, расписания, критериев начала и окончания тестирования, до необходимого в процессе работы оборудования, специальных знаний, а также оценки рисков с вариантами их разрешения.

Bug Report — Баг/Дефект Репорт

Виды Тестирования ПО (можно условно разделить на следующие группы)

1. Функциональные

2. Нефункциональные

3. Связанные с изменениями

Тестировщик осуществляет контроль качества продукта после его разработки, в то время как задача QA тестера — обеспечение качества продукции на всех этапах разработки, выпуска и эксплуатации ПО.

Главные должностные обязанности тестировщика:

Контроль качества разрабатываемых продуктов.

• Выявление и анализ ошибок и проблем, возникающих у пользователей при работе с программными продуктами.

• Разработка автотестов и их регулярный прогон.

• Разработка сценариев тестирования.

• Документирование найденных дефектов.

Также должность тестировщика может предполагать составление технической документации на русском и иностранном (чаще английском) языках.

Требования к тестировщику

Главные требования к тестировщику:

• Опыт организации и проведения различных видов тестирования.

• Знание языков программирования.

• Знание инструментов и библиотек для автотестирования.

• Опыт написания автотестов.

• Высшее образование.

• Аналитические способности.

Дополнительные требования:

• Умение тестировать веб-приложения.

• Знание мобильных платформ (iOS, Android).

• Знание английского языка на уровне, достаточном для чтения и написания технических текстов.

Методика тестирования

Широко используемыми методами тестирования являются модульное тестирование, интеграционное тестирование, приемочное тестирование, и тестирование системы. Программное обеспечение подвергается этим испытаниям в определенном порядке.

1) Модульное тестирование

2) Интеграционное тестирование

3) Системное тестирование

4) Приемочные испытания

Модульное тестирование

В первую очередь проводится модульный тест. Как подсказывает название, это метод испытания на объектном уровне. Отдельные программные компоненты тестируются на наличие ошибок. Для этого теста требуется точное знание программы и каждого установленного модуля. Таким образом, эта проверка осуществляется программистами, а не тестерами. Для этого создаются тест-коды, которые проверяют, ведет ли программное обеспечение себя так, как задумывалось.

Интеграционное тестирование

Отдельные модули, которые уже были подвергнуты модульному тестированию, интегрируются друг с другом, и проверяются на наличие неисправностей. Такой тип тестирования в первую очередь выявляет ошибки интерфейса. Интеграционное тестирование можно осуществлять с помощью подхода «сверху вниз», следуя архитектурному сооружению системы. Другим подходом является подход «снизу вверх», который осуществляется из нижней части потока управления.

Системное тестирование

Home

Для тестировщика, который только начал создавать тест-автоматизацию, использование системы контроля версий вроде Git может показаться опасным и запутанным. Однако способность получить свежайший код, обновить его и создать запрос на включение кода – это очень важно для любого командного проекта? Сегодня я расскажу об основах Git.

Что такое Git?

Git – это система контроля версий. Система контроля версий – это система, позволяющая группе людей совместно работать над кодом, не рискуя случайно перезаписать чужую работу. Она также позволяет группе отслеживать, кто менял код и когда это произошло, и поэтому можно легко докопаться до источника проблемы.

Зачем нужен Git?

Представьте себе редактирование файла без использования систеым контроля версий. Допустим, у вас есть рецепт шоколадного пирожного. Вы отправляете рецепт своему другу, и он решает изменить в нем количество какао. Когда он вносит свое изменение – оно отражается только в его версии файла, а не в вашей. Ваши файлы теперь различаются. Если вы внесете изменение количества ванили, расхождений между вашими версиями станет еще больше.

Можно легко увидеть, что для программного кода это недопустимо! В системе контроля версий есть одна «мастер-версия» – одобренная версия кода. Эта мастер-версия живет в GitHub (или другом сервисе контроля версий), и может быть «получена» любым пользователем. Если кто-то хочет внести изменения в код, они «вытягивают» мастер-версию кода, создают «ветку» – копию мастер-версии, вносят изменения в ветку, пушат ветку назад на GitHub, а затем создают запрос на включение кода – просьбу к кому-то провести ревью кода и слить его с веткой мастера.

Запутались? Не волнуйтесь, на примере все станет намного понятнее. Предположим, что у нас есть репозиторий исходного кода по имени «Гостевая книга думающего тестировщика». Давайте посмотрим, что произойдет, если Прюнелла Прюнвип хочет добавить свое имя в гостевую книгу.

Инструкции предполагают, что Прюнелла уже установила Git на свою машину, и создала учетную запись в GitHub.

Шаг первый: Прюнелла клонирует репозиторий исходного кода

Это часто называется «клонированием репозитория» или «выкачкой репозитория». Прюнелла делает это, переходя по URL в GitHub с исходным кодом, и нажимая на зеленую кнопку » Clone or download». Появляется выпадающее меню с URL, необходимым для клонирования кода. Она нажимает маленькую кнопку буфера обмена справа от URL, чтобы копировать его.

Затем Прюнелла открывает командную строку и переходит в папку, куда планирует положить исходный код. Оказавшись там, она вводит команду git clone и вставляет URL после этой команды. Репозиторий копируется из GitHub в новую папку.

Теперь, когда репозиторий находится в папке на ее машине, она может открыть эту папку в диспетчере файлов и посмотреть, что в ней находится. Она видит единственный текстовый файл «guestBook.txt». В нем написано следующее:

«Кристин Джеквони была здесь 11 мая 2019 года».

Шаг второй: Прюнелла создает новую ветку и добавляет в нее свои изменения

Прежде чем вносить какие-либо изменения в guestBook.txt, Прюнелла должна создать новую ветку и переключиться на нее. В командной строке она переходит в новую папку, клонированную ранее, вводя

Она может проверить, что она в мастер-ветке, введя команду git status – она получит ответ вроде этого:

On branch master.

Теперь она может создать новую ветку и переключиться на нее, вводя git checkout -b NewEntry. Команда «-b» говорит Git, что нужно создать новую ветку. «NewEntry» – это имя ветки, выбранное Прюнеллой. А команда checkout заставляет Git переключиться на новую ветку.

Если на этом этапе Прюнелла введет git status, она получит ответ «On branch NewEntry».

Теперь, когда Прюнелла находится в правильной ветке, она внесет изменения в файл guestBook.txt, добавив в него одну строчку. Теперь он выглядит так:

«Кристин Джеквони была здесь 11 мая 2019 года.

Прюнелла Прюнвип была здесь 13 мая 2019 года».

Шаг 3: Прюнелла коммитит свои изменения и пушит их в GitHub

Теперь, когда Прюнелла внесла нужные изменения, ей нужно закоммитить и запушить его. Для начала она может прогнать git status, получая следующий ответ:

On branch NewEntry

Он говорит о том, что файл guestBook.txt был изменен. Затем Прюнелле нужно добавить файл в коммит, введя git add guestBook.txt. Теперь, если она введет git status, она увидит ответ:

On branch NewEntry

Changes to be committed:

Затем Прюнелла коммитит свое изменения, вводя git commit -m «Adding a new entry». –m в этой команде означает «message», сообщение. Текст «Adding a new entry» – это сообщение, которое она добавляет, чтобы объяснить, что именно она коммитит. Командная строка ответит количеством файлов и строчек, которые были изменены.

Как только изменение закоммичено, Прюнелла может пушить его в репозиторий GitHub, вводя git push origin NewEntry. Значение NewEntry поясняет, что код должен попасть в ветку NewEntry, которая еще не существует в репозитории – по этой команде она будет создана. Origin относится к репозиторию GitHub (его также называют «удаленным»). Командная строка ответит несколькими строчками, последней из которых будет

* [new branch] NewEntry -> NewEntry

Эта строка показывает, что в оригинальном репозитории создана новая ветка NewEntry, скопированная с локальной ветки, созданной Прюнеллой, которая тоже называется NewEntry.

Шаг 4: Прюнелла создает запрос на включение кода (пулл-реквест) в GitHub

Теперь, когда новая ветка попала в GitHub, Прюнелла может создать пулл-запрос, чтобы попросить о слиянии своих изменений с мастер-веткой. Она делает это, перейдя в репозиторий GitHub и кликнув на кнопку «New Pull Request». Это перемещает ее на страницу «Compare». Она убеждается, что в левой части сравнения находится мастер-ветка, а затем выбирает ветку NewEntry из выпадающего меню. Она может видеть, как изменился файл guestBook.txt – новая добавленная строчка подсвечена зеленым, демонстрируя разницу между двумя файлами (если бы она что-то удалила, удаленная строка подсвечивалась бы красным). И, наконец, она нажимает на кнопку «Create Pull Request».

Шаг 5. Пулл-реквест Прюнеллы одобрен и объединен

Финальный шаг в процессе изменения файлов – это ревью изменения, его одобрение и слияние, которое проводит хозяин репозитория или члены команды, имеющие права на одобрение пулл-реквеста. Теперь, если Прюнелла переключится на мастер-ветку, введя git checkout master, выкачает изменения (git pull origin master) и посмотрит на файл guestBook.txt, она увидит, что в него добавлена новая запись:

«Кристин Джеквони была здесь 11 мая 2019 года.

Прюнелла Прюнвип была здесь 13 мая 2019 года».

Вот и все! В следующий раз я расскажу о полезных для Git штуках и фокусах, но этих шагов должно быть достаточно для коммита вашего собственного кода в репозиторий команды.

Git: инструменты тестировщика

Курс содержит все популярные команды из Git, а также множество домашних заданий на отработку знаний.

Купить полную версию

скидка: 90% выгода: 2710 руб.

Что внутри

формат записи: видео длительность: 1,5 часа объем: 276 Мб год: 2018 доступ: навсегда сайт: показать

Я в шоке! В приятном шоке. Не верила, что в самом деле можно купить курс за меньшие деньги.Ребята спасибо за работу. Очень бы хотелось купить крус по кройке и шитью Леся 23 мая

Спасибо. Быстро, удобно, честно. Лиза 18 июня

Хороший сервис. Хорошие материалы, доступные цены. Юрий 6 июля

Максимально эффективно вместе

О курсе «Git: инструменты тестировщика»

Тестировщик всегда работает в условиях недостатка времени: беклог не уменьшается, релиз на носу, а протестировать нужно еще многое. Чтобы обеспечить качество продукта, нужно постоянно повышать эффективность собственной работы. Один из способов — освоить некоторые инструменты, облегчающие рутинные действия в тестировании.

Для хранения и работы с кодом повсеместно используются системы контроля версий. Наиболее популярная среди них — Git. Он используется буквально в каждой второй компании. С помощью этой системы можно хранить большое количество различных версий кода, разрабатывать новый функционал без помехи работающему, проверять только новые изменения. Современный тестировщик сталкивается с такими задачами каждый день — и он должен уметь работать с Git

Курс « Инструменты тестировщика: Git» содержит все популярные команды из Git, а также множество домашних заданий на отработку знаний.

На этом курсе вы научитесь:

• Получать информацию о репозитории;
• Сравнивать файлы;
• Переключаться между различными ветками;
• Откатывать изменения;
• Настраивать удобную и информативную консоль;
• Решать конфликты кода;
• Создавать аккаунты на самых популярных сервисах и работать с ними.

Программа курса

• Что такое система контроля версий
• Обзор систем контроля версий
• Почему Git

Создание аккаунта на github:

• Регистрация
• Обзор интерфейса
• Создание собственного репозитория

Установка Git на локальный компьютер

Команда git clone

• git status
• git diff
• git log
• git show
• git blame

Работа с удаленной информацией:

Работа с локальными изменениями:

• git commit
• git push
• git merge

Работа с буфером:

Работа с ветками:

• git branch
• git branch delete
• git checkout

Работа с файлами:

• git add
• git reset
• git reset — soft
• git reset — hard
• git reset HEAD

• решение конфликта мержа ветки
• решение конфликта буфера

Регистрация на GitLab

Регистрация на BitBucket

Курс «Git: инструменты тестировщика» отлично дополнят

Несколько отзывов об ИнфоПоиске

Sofia 30 августа

Отличный, быстрый сервис, отзывчивая тех поддержка в любое время суток решают все вопросы, адекватные цены, никакого обмана, материал приходит сразу после оплаты. Спасибо.

Леся 23 мая

Я в шоке! В приятном шоке. Не верила, что в самом деле можно купить курс за меньшие деньги.Ребята спасибо за работу. Очень бы хотелось купить крус по кройке и шитью

Как оформить портфолио на Github для QA Manual

Во-первых, на рынке начинающих специалистов большая конкуренция.

Во-вторых, сократилось количество компаний, которые готовы вкладываться в обучение и найм джунов.

В-третьих, на курсах редко рассказывают и показывают ваши сильные стороны. А это основа для успешного прохождения собеседований.

В-четвертых, неправильно оформленное или сделанное “под копирку” резюме. Оба варианта быстро считываются hr cпециалистами и отклоняются на ранних этапах.

Что я советую и что действительно работает:

Любые навыки можно и нужно показывать: у дизайнеров есть макеты, разработчики могут показать свой код. А QA специалисты могут создать портфолио с тестовой документацией, коллекцией в Postman, и со всем тем, что может продемонстрировать ваши навыки и сильные стороны.

Портфолио выделит вас на фоне остальных ребят и поможет работодателю больше узнать про вас.

Для создания портфолио можно использовать разные инструменты, но самый удобный на мой взгляд — Github

Инструкция по созданию портфолио:

1. Зарегистрироваться на Github
2. Авторизоваться
3. Создать репозиторий

Вам необходимо создать репозиторий с тем же именем, что и ваш профиль на Github: https://github.com/new

4. Cоздать файл README

Мы создали файл, который необходимо оформить под ваше портфолио. Профили README написан в формате Markdown, поэтому вы можете вставлять картинки и GIF изображения.

Подробнее про синтаксис можно почитать здесь: Markdown

Основные пункты, которые стоит добавить:

• О себе
• Ссылка на резюме
• Список технологий и инструментов
• Портфолио
• Контакты

Идеи как оформить профиль можно посмотреть здесь