Тестирование по

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

Многие люди ошибочно считают, что раз пентестер это почти хакер, то и зарабатывать он должен 300к/наносек (минимум). Накануне старта нового потока нашего курса "Этичный хакер" разберёмся, действительно ли это так.

Чем занимается пентестер

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

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

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

В пул задач пентестера входит:

• Тест сети и приложений на уязвимости. Найти дырку в информационной системе крупной компании не так сложно. Куда сложнее понять:

  • Почему дырка именно здесь: банальная ошибка, лень, незнание технологии.

  • К чему может привести её использование хакером: потеря данных, проникновение в систему с рут-доступом, слив личной информации клиентов и сотрудников. Пентестер ведь не имеет права использовать уязвимость даже в тестовом формате. Поэтому просто проверить не получится.

  • Как исправить уязвимость, чтобы проблема не вылезла в другом месте и не стала еще более серьёзной.

• Ведение отчётов по всем проведённым тестам и найденным уязвимостям с подробным их описанием.

• Разработка общей политики информационной безопасности компании и отдельных сотрудников.

Пентестер ещё до начала работы связан договорами. Его работа и разрешённые тесты чётко регламентированы и отступать от них он не имеет права.

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

Как зарабатывает пентестер

Есть 3 основных пути, по которым может пойти тестировщик безопасности:

• Присоединиться к команде пентестеров или войти в отдел пентеста крупной компании. Из плюсов здесь полная защищённость со стороны закона, но зарплата не будет особо отличаться от средней в IT-сфере.

• Открыть ИП и работать по договору. По деньгам здесь можно заработать гораздо больше, но юридические вопросы полностью ложатся на плечи специалиста. Нередки случаи, что за уязвимости, найденные не там, где это было прописано в договоре, пентестеры получали не премию, а уголовное преследование.

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

Штатный пентестер: зарплата и возможности

Давайте рассмотрим каждую из возможностей поближе. Сначала зарубежный опыт. Начнём с штатного пентестера, который получает фиксированную зарплату.

По данным Indeed, специалист по пентесту в штате компаний США получает в среднем 118 316 долларов год. Это примерно столько же, сколько получает фуллстак разработчик или дата-сайентист.

Но вот Cyber Degrees не так оптимистичны в своих анализах. По данным их ежегодного отчёта, средняя зарплата пентестера в США составляет около 84 690 долларов в год. А это на 27 % меньше, чем даёт Indeed. Существенная разница.

При этом зарплата в профессии сильно зависит от опыта и компетенций специалиста. Новичок в сфере с опытом меньше полугода получает около 66 000 долларов в год, даже если у него обширный опыт в IT-специальностях вроде системного администрирования или разработки.

Middle-специалист, по мнению Cyber Degrees, зарабатывает примерно 106 000 долларов. В целом, даже если учесть разницу между отчетами, общая сумма не слишком отличается от других специальностей, связанных с разработкой и тестированием софта.

А вот портал Glassdoor более пессимистичен в оценках и среднюю зарплату штатного пентестера оценивает в 69 000 долларов. Но нужно учесть, что портал анализирует цифры, предложенные в вакансиях, а не зарплаты реальных специалистов, которые могут быть в разы больше.

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

По состоянию на 14 марта 2021 года, на Indeed открыта 41 вакансия сеньор-пентестера. Для сравнения: там же открыто 6867 вакансий сеньор-разработчика на Python. Можно понять, насколько большой разрыв спроса.

А теперь о ситуации в России. С русскоязычным рынком пентестеров дела обстоят как-то странно. Отдельные крупные компании и филиалы международных концернов нанимают команды пентестеров или пользуются услугами Bug Bounty, но вакансии конкретно пентестера открываются значительно реже.

Дело в том, что функции пентестера часто выполняют другие специалисты. К примеру, тестировщик или системный администратор.

На Хабр Карьера мы не нашли ни одной открытой вакансии пентестера. На hh.ru, по состоянию на 16 марта 2021 года, есть 29 вакансий на позицию пентестера. Но на самом деле только 15, потому что половина к пентесту не имеет никакого отношения.

В чём дело? Их часто ищут в других вакансиях, которые мы назвали выше. А сайты по поиску работы теряются и думают, что это разные вакансии и специальности, поэтому не подтягивают их вместе. Можете считать это первым тестом по специальности.

В сфере ИБ в целом вакансий достаточно, но именно пентестерских позиций немного. Специалист ИБ - это профессионал широкого профиля, с большим объёмом знаний. И понимание уязвимостей, атак и методологии пентеста помогает специалистам ИБ работать на стороне защиты. Мы рассказываем про опыт экспертов, которые работают в безопасной разработке, специалистами по безопасности. Есть ещё bug bounty, когда можно найти уязвимости, выложенные в открытый доступ крупными компаниями. Это уже международный уровень. Кроме того, сертификации в сфере кибербезопасности (CEH, OWASP) и практический боевой опыт повышает ценность специалиста.

Яна Суслова, методист курса Этичный хакер

Рынок только развивается, поэтому востребованность специалистов по безопасности стабильно растёт. Плюс, есть ещё несколько проверенных способов получить работу пентестера, не пользуясь такими сайтами. О них чуть ниже.

Чаще пентестеры работают как самозанятые или в составе отдельных команд. Что приводит нас к следующему разделу.

Пентестер как ИП, самозанятый или часть команды

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

Но для абсолютного большинства компаний малого и среднего бизнеса пентест это разовая или очень редкая акция. Для неё нет смысла нанимать специалиста в штат. Только крупные игроки могут позволить себе нанять штатного инженера по информационной безопасности.

В России это буквально единичные компании. Малый и часть среднего бизнеса нанимают индивидуальных пентестеров, крупный предпочитает нанимать команды с именем и пулом выполненных проектов.

Цена на пентест по договору зависит от многих факторов. В США она стартует от 2500 долларов. В России от 100 000 рублей. Имеет значение, какие именно системы тестируются, как глубоко, какие именно уязвимости на прицеле: только критические или все более-менее серьёзные.

Комплексный пентест зачастую берут команды, состоящие из 4-10 специалистов. Отдельные же задачи (к примеру, анализ уязвимостей баз данных) могут выполнять и индивидуальные специалисты.

В целом за пентест среднестатистический специалист получает 100-200 долларов в час. Но это - грязными, из которых нужно ещё вычесть определенную сумму на налоги и работу юриста с договорами. Без грамотного IT-юриста в пентесте вообще делать нечего даже небольшой косяк в договоре может обернуться большими проблемами для спеца.

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

Несмотря на трудности и риски, работа пентестера на себя приносит доход в среднем в 1,5-2 раза выше, чем при оформлении в штат. Но для этого нужно обладать отличными навыками коммуникации и переговоров заниматься ими нужно будет не меньше, чем самими пентестами.

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

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

Bug Bounty: альфа и омега для пентестера

Наконец, переходим к источнику заработка, который абсолютное большинство пентестеров считают своим основным. Программы Bug Bounty.

По информации из открытых источников и наших коллег-пентестеров, среднестатистический этичный хакер может зарабатывать на программах Bug Bounty 2000-3000 долларов в месяц.

Главный плюс программ можно сосредоточиться на уязвимостях, в которых вы хорошо разбираетесь. К примеру, вы профи в разработке приложений для Android и можете искать уязвимости и ошибки в безопасности таких приложений.

Можно вполне успешно работать в одной узкой сфере и нормально зарабатывать.

Топовые багхантеры вполне могут зарабатывать вплоть до 50 000 долларов в месяц. Да, это вполне реально. Опыт Марка Литчфилда это доказывает. В декабре 2015 года он заработал 47 750 долларов, используя ресурсы Hackerone, BugCrowd и программу PayPal.

Иван Григоров, интервью которого лежит на Хабре, также утверждает, что 25 000 долларов в месяц для опытного пентестера не проблема. Тоже рекомендуем почитать.

По более скромным оценкам, пентестеры действительно могут без особых проблем зарабатывать 2000-3000 долларов каждый месяц только на программах Bug Bounty. Но для этого нужно хорошо разбираться как минимум в одной отрасли программирования. Точнее определить сложно, ведь эффективность пентестера и количество обнаруженных уязвимостей прямо зависит от знаний, опыта и времени, которые багхантер уделяет пентесту.

Но можно сделать примерную оценку. На HackerOne за одну минорную уязвимость платят от 50 до 100 долларов.

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

Другие же предпочитают искать более серьёзные уязвимости, за которые оплата побольше.

Вот, к примеру, какую оплату предлагает компания PayPal:

За одну критическую уязвимость компания платит от 2000 до 10000 долларов. Понятно, что найти такую уязвимость совсем непросто, но тем не менее.

Тут уже выбор специалиста: искать редкие, серьёзные и дорогие проблемы или же сосредоточиться и находить небольшие, но часто. Всё остальное зависит от скилла пентестера.

И ещё: мы в одном из предыдущих разделов упоминали, как найти работу пентестеру без сайтов по поиску работы. Bug Bounty один из вариантов. Тут есть секрет, который опытные специалисты не раскрывают.

Помимо открытых программ существуют ещё и закрытые, куда специалистов приглашают лично. Это может быть альфа-версия продукта, сайта или системы безопасности, в которой совершенно точно есть баги и их нужно найти. Создавать открытую программу с сырым продуктом слишком дорого. Поэтому приглашают проверенных пентестеров, которые найдут все или почти все серьёзные и критические уязвимости до старта открытого пентеста.

Стать таким приглашённым тестером довольно несложно. Нужно всего лишь качественно работать на открытых программах. Если вы нашли несколько серьёзных багов, разработчик это заметит. Если он будет нуждаться в закрытом пентесте, то пригласит нескольких специалистов, которые хорошо показали себя в программе. Это дешевле, чем нанимать полноценную команду пентеста. А дальше, если всё всех устраивает, это может превратиться либо в стабильный контракт на подряд, либо в полноценное оформление в штат.

Что нужно знать и уметь пентестеру

Про хард-скилы мы писали в первой статье про этичный хакинг: как взламывать системы и при этом зарабатывать легально. Хотелось бы добавить, что нужны не только знания, но и жизненный опыт. Системный администратор с опытом стрессового поднятия сервера или программист на C++, который ищет ошибку в 200 000 строчках кода, из-за которой всё пошло по наклонной имеют большие шансы быть успешными в пентестинге. Не будем забывать про тестировщиков, у которых тоже есть необходимый бэкграунд. Пентестеру нужен практический опыт и предельно чистое понимание, как работает система или хотя бы её часть.

Попасть в пентест новичку сложно, но возможно. Если вы готовы, научиться всему можно на нашем комплексном курсе Этичный хакер, где студентам в освоении материала помогает опытный ментор, а карьерный специалист поможет с трудоустройством.

Узнайте, как прокачаться в других специальностях или освоить их с нуля:

• Профессия Data Scientist

• Профессия Data Analyst

• Курс по Data Engineering

В ноябре 2020 года провели шикарный Online митапчик в Redmadrobot. Была рада увидеть коллег и поделиться знаниями.

Особенности организации

Для меня этот митап был достаточно необычным, по факту для зрителей он Онлайн, для меня - офлайн. все действо происходило в робохранилище. Будто побывала на съемках кино: свет , звук и другие приблуды, Но ценность в другом, в эпоху пандемии это реальное общение и микро нетворкинг... Ну а теперь к делу!)

Делюсь результатами

Весь митапчик посмотреть и прочитать про другие доклады можно здесь http://personeltest.ru/aways/habr.com/ru/company/redmadrobot/blog/545236/

Коротко в чем суть моего докладика.

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

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

Основная цель тестирования своевременно оповещать команду о реальном состоянии системы или продукта

Основные точки опоры для построения тестирования

1. Анализ требований или технического задания.

2. Инфраструктура важно настроить окружение, выбрать целевые устройства, какие тестовые данные потребуются.

3. Процесс коммуникации нужно договориться, в каком формате мы выстраиваем обратную связь с командой (например, делаем отчеты о тестировании в Jira).

4. Разбираемся, как именно организовываем тестирование: какие виды тестирования, на каких этапах применяем, как распределяем ресурсы, планирование и так далее.

5. Уделяем время написанию отчетности и договариваемся, какая отчетность и в каком виде нужна.

6. Постоянно внедряем улучшения и анализируем изменения.

О чем тестировщик должен сообщать команде

• Что нужно автоматизировать.В процессе коммуникации с разработчиками и менеджерами тестировщику нужно определить и рассказать, какие тесты должны быть автоматизированы и на каком уровне.

• Как оптимизировать работу.Нужно делать постоянную оптимизацию тестов, чтобы они затрачивали меньше времени. Задача тестировщика минимизировать время выполнения тестов, оптимизировать фича тесты и регресс. Это нужно, для того чтобы быстро получать информацию о состоянии продукта.

• Обеспечить полезные метрики для бизнеса.Например, количество багов на продакшене, количество активностей, как двигается процесс написания документации, время, затраченное на тестирование и т.д. Такие метрики будут сигнализировать, всё ли у проекта хорошо. Кроме того, с помощью них тестировщик может показать результаты работы всей команды. Но стоит помнить, что не стоит закапываться в метриках, а нужно использовать скорее их как опорные точки. Ведь, помимо метрик, есть и другие системы отчетности.

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

Тестирование это как круговая оборона. Весь продукт охранять очень сложно, поэтому тестировщики создают датчики (некие красные флажки), которые в нужный момент сообщают: alarm! И подобные датчики это метрики, а также автотесты, различные приемы и т.д. Задача команды тестирования выстроить многослойную систему защиты, состоящую из нужных датчиков. Также стоит помнить, что помимо того, что QA тестирует, команда ещё сообщает реальное состояние системы, где все окей, где начинает рваться, а где все плохо и нужно срочно исправлять.

Как тестировщику обеспечивать обратную связь для команды

1. С помощью парного тестирования или программирования.Автоматизацию тестирования полезно делать при поддержке разработчиков. На этом этапе должно происходить взаимное ревью, это помогает тестировщику глубже узнать систему и уже на этом этапе обнаружить какие-то проблемы.

2. С помощью Code Reviews.Это не совсем работа тестировщика, но в проекте через Code Reviews можно получить обратную связь. Например, если у нас фича автоматизации типовая, и она долго ревьювится на разных проектах, то нужно выяснить причину.

3. Через модульные тесты (Unit tests).

4. С помощью автоматизированных интеграционных тестов (Automated Integration Test).

5. С помощью автоматизированных Acceptance Tests. Эту активность можно разделить с продакт-менеджерами.

6. По возможности следует автоматизировать Regression Test.

7. Постоянный Exploratory Testing.

8. Обратная связь от пользователей или бизнес-юзеров.

9. Постоянное UAT-тестирование + DEMO-сессии.

Через что тестировщик может организовать обратную связь с командой

• С помощью работы с дефектами (багами) нужно определить формат их заведения и оповещения о них, например, делать это в Jira или другом удобном инструменте. Разработчикам не всегда хватает информации в дефекте, чтобы приступить к фиксу, поэтому иногда требуется дополнительная коммуникация с багрепортером.

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

• Кросс-обучение внутри тестирования. Все специалисты разные, они могут учиться друг у друга, поэтому важно иногда собираться и обсуждать результаты работы и делиться лайфхаками и знаниями продукта. Это некий knowledge transfer.

• Тест-документация собирать отчетность по фичам, сборкам и по приемке. Для составления отчетности поможет изучение ГОСТов: в них описаны градации дефектов, как с ними быть и так далее. Для проектов, связанных с государственным подрядом, поможет изучение ГОСТ 34.603-92.

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

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

Содержание

• Что такое база данных

• Как она выглядит

• Как получить информацию из базы

• Как связать данные между собой

• Как ускорить запрос

• Преимущества базы данных

• Что знать для собеседования

• Статьи и книги по теме

• Резюме

Что такое база данных

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

Катя решила открыть свой магазинчик. Она нашла хорошую марку обуви, которую днем с огнем не сыскать в ее городе. Заказала оптовую партию и стала потихоньку распродавать через знакомых. Пришлось освободить половину шкафа под коробки, но вроде всё поместилось.

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

Но покупатели хотят новинок, разных размеров. Да и самих покупателей становится все больше и больше. В шкаф коробки уже не влезают!

Теперь, если покупатель просит определенную пару, Катьке сложно её найти. Пока коробок было мало, она помнила наизусть, где что лежит. А теперь уже нет, да и все попытки организовать систему провалились. Места мало, да и детки любят с коробками поиграть.

Тогда Катька решила орендовать складское помещение. И вот теперь красота! Не надо теснить своих домашних, дома чисто и свободно! И на складе место есть, появилась система тут босоножки, тут сапоги...

Чем больше объемы производства, тем больше нужно места. Если в начале пути склад не нужен, всё поместится дома, то потом это будет оправданно.

Тоже самое и в приложениях. Если приложение маленькое, то все данные можно хранить в памяти. Но учтите, что это память на вашем компьютере, вашем телефоне. И чем больше данных туда пихать, тем медленнее будет работать программа.

Место в памяти ограничено. Поэтому когда данных много, их нужно куда-то сложить. Можно писать в файлики, а можно сохранять информацию в базу данных (сокращенно БД). Выбор за вами. А точнее, за вашим разработчиком.

Как она выглядит

Да примерно как excel-табличка! Есть колонки с заголовками, и информация внутри:

Это называется реляционная база данных набор таблиц, хранящихся в одном пространстве.

Что за пространство? Ну вот представьте, что вы храните все данные в excel. Можно запихать всю-всю-всю информацию в одну огро-о-о-о-мную таблицу, но это неудобно. Обычно табличек несколько: тут информация по клиентам, там по заказам, а тут по адресам. Эти таблицы удобно хранить в одном месте, поэтому кладем их в отдельную папочку:

Так вот пространство внутри базы данных это та же самая папочка в винде. Место, куда мы сложили свои таблички, чтобы они все были в одном месте.

Цель та же выделить отдельное место, чтобы у вас не была одна большая свалка:

• заходишь в папку в винде видишь файлики только из этой папки

• заходишь в пространство видишь только те таблицы, которые в нем есть

Хранение данных в виде табличек это не единственно возможный вариант. Вот вам для примера запись из таблицы в системе Users. Там используется MongoDB база данных, она не реляционная. Поэтому вместо таблички словно в excel каждая запись хранится в виде объекта, вот так:

А еще есть файловые базы когда у вас вся информация хранится в файликах. Да-да, простых текстовых файликах!

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

Да, базы бывают разные. Классификацию можно изучить, можно выучить. Но по факту от начинающего тестировщика обычно нужно уметь достать информацию из реляционной БД (обычно != всегда, если что).

Как получить информацию из базы

Нужно записать свой запрос в понятном для базы виде на SQL. SQL (Structured Query Language) язык общения с базой данных. В нем есть ключевые слова, которые помогут вам сделать выборку:

• select выбери мне такие-то колонки...

• from из такой-то таблицы базы...

• where такую-то информацию...

Например, я хочу получить информацию по клиенту Назина Ольга. Составляю в уме ТЗ:

Дай мне информацию по клиенту, у которого ФИО = Назина Ольга

Переделываю в SQL:

select * from clients where name = 'Назина Ольга';

В дословном переводе:

select -- выбери мне* -- все колонки (можно выбирать конкретные, а можно сразу все)from clients -- из таблицы clientswhere name = 'Назина Ольга'; -- где поле name имеет значение 'Назина Ольга'

См также:

Комментарии в Oracle/PLSQL мой перевод остается работающим запросом, потому что я убрала лишнее в комментарии

Если бы у меня была не база данных, а простые excel-файлики, то же действие было бы:

1. Открыть файл с нужными данными (clients)

2. Поставить фильтр на колонку ФИО Назина Ольга.

То есть нам в любом случае надо знать название таблицы, где лежат данные, и название колонки, по которой фильтруем. Это не что-то страшное, что есть только в базе данных. Тоже самое есть в простом экселе.

Бывают запросы и сложнее когда надо достать данные не из одной таблицы, а из разных. В базе это будет выглядеть даже лучше, чем в эксельке. В экселе вам нужно открыть 1-2-3 таблицы и смотреть в каждую. Неудобно.

А в базе данных вы внутри запроса SQL указываете, какие колонки из каких таблиц вам нужны. И результат запроса их отрисовывает. Скажем, мы хотим увидеть заказ, который сделал клиент, ФИО клиента, и его номер телефона. И всё это в разных таблицах! А мы написали запрос и увидели то, что нам надо:

И пусть в таблице клиентов у нас будет 30 колонок, а в таблице заказов 50, в результате выборки мы видим ровно 4 запрошенные. Удобно, ничего лишнего!

Конечно, написать такой запрос будет немного сложнее обычного селекта. Это уже select join, почитать о нем можно тут. И я рекомендую вам его изучить, потому что он входит в базовое знание sql, которое требуется на собеседованиях.

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

Как связать данные между собой

Вот например, у нас есть интернет-магазин по доставке пиццы. Так выглядит его база данных:

• В таблице client лежат данные по клиентам: ФИО, пол, дата рождения и т.д.

• В таблице orders лежат данные по заказам. Что заказали (пиццу, суши, роллы), когда, насколько довольны доставкой?

Но как понять, где чей был заказ? Сколько раз заказывал Вася, а сколько Алина?

Тут есть несколько вариантов:

1. Запихать все данные в одну таблицу: тут и заказы, и информация по клиентам... В целом удобно, открыл табличку и сразу видишь ага, это Васин заказ, а это Машин.

Но есть минусы:

• Таблица все растет и растет, в итоге получается просто огромной! А когда данных много, легкость чтения пропадает, придется листать до нужной колонки.

• Поиск будет работать медленнее. Чем меньше информации в таблице, тем быстрее поиск. Когда у нас много строк, количество колонок становится существенным.

• Много дублей один человек может сделать хоть сотню заказов. И вся информация по нему будет продублирована сто раз. Неоптимальненько!

Чтобы избежать дублей, таблицы принято разделять:

• Клиенты отдельно

• Заказы отдельно

• Новые объекты отдельно

Но надо при этом их как-то связать между собой, мы ведь всё еще хотим знать, чей конкретно был заказ. Для связи таблиц используется foreign key, внешний ключ.

Нам надо у заказа сделать отметку о клиенте. Значит, таблица orders будет ссылаться на таблицу clients. Ключ можно поставить на любую колонку таблицы. Какую бы выбрать?

Можно ссылаться на имя. А что, миленько, в таблице заказов будем сразу имя видеть! Но минуточку... А если у нас два клиента Ивана? Или три Маши? Десять Саш... Ну вы поняли =) И как тогда разобраться, где какой клиент? Не подходит!

Можно вешать foreign key на несколько колонок. Например, на фамилию + имя, или фамилию + имя + отчество. Но ведь и ФИО бывают неуникальные! Что тогда? Можно добавить в связку дату рождения. Тогда шанс ошибиться будет минимален, хотя и такие ребята существуют. И чем больше клиентов у вас будет, тем больше шанс встретить дубликат.

А можно не усложнять! Вместо того, чтобы делать внешний ключ на 10 колонок, лучше создать в таблице клиентов primary key, первичный ключ. Первичный ключ отвечает за то, чтобы каждое значение в поле было уникальным, никаких дублей. При попытке добавить в таблицу запись с неуникальным первичным ключом получаешь ошибку:

Вот на него и нужно ссылаться! Обычно таким ключом является ID, идентификатор записи. Его можно сделать автоинкрементальным это значит, что он генерируется сам по алгоритму прошлое значение + 1.

Например, у нас гостиница для котиков. Это когда хозяева едут в отпуск, а котика оставить не с кем оставляем в гостинице!

Есть таблица постояльцев:

Тут привозят еще одного Барсика. Добавляем его в таблицу:

Имя Барсик, 5 лет! (мы не указываем ID)

Система добавляет:

ID сгенерился автоматически. Последнее значение было 2, значит, новый Барсик получил номер 3. Обратите внимание Барсиков уже два, но их легко различить, ведь у них разные идентификаторы!

Теперь, если в другой таблице надо будет сослаться на котика, мы будем делать это именно через уникальный идентификатор. Например, у нас есть таблица комнат для постояльцев, куда мы заносим информацию о том, кто там живет:

Мы видим, что в первой комнате живет котик с id = 1, а во второй с id = 2. В третьей комнате пока никто не живет. Так, благодаря связке таблиц, мы всегда можем понять, что именно за котофей там проживает.

Итак, теперь мы знаем, что идентификатор лучше делать первичным ключом, дабы обеспечить его уникальность. Можно сделать поле автоикрементальным, чтобы оно заполнялось само. Так и поступим в таблице клиентов:

И в таблице заказов! id_order пусть генерится сам и всегда будет уникален. А еще в таблицу заказов мы добавим колонку id_client и повесим на нее foreign key, ссылку на id_client в таблице клиентов.

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

И наоборот, несколько таблиц могут ссылаться на одну и ту же колонку текущей таблицы. ID клиента мы можем указывать в таблице адресов, телефонов, email адресов, документов, заказов... Ограничений на это нет.

Как ускорить запрос

Давайте представим, что у нас есть табличка excel. Если она небольшая (пара строк, пара колонок), то найти нужную ячейку не составит труда:

1. Открыли файлик открывается моментально (если нет проблем с жестким диском)

2. Нажали Ctrl + F, ввели запрос тут же нашли результат.

Но что, если у нас сотни колонок и миллионы строк в файлике? Тогда начинаются тормоза. Файл открывается долго, в поиск значение ввели и система подвисла, обрабатывая результат...

Всё то же самое и в базе данных. Если табличка маленькая, любой запрос к ней отработает моментально. Если же таблица будет большая и с кучей данных, то результата запроса можно ждать минут по 15. А иногда и пару часов!

Что делать, чтобы запросы были быстрее? Тут есть несколько путей:

1. На этапе создания таблицы добавить индексы

2. На этапе написания запроса к большой таблице использовать хинты

3. Пересобрать статистику базы

Есть и другие, но мы остановимся на этих трех.

Индексы в таблице

Если вы заранее знаете, что данных в базе будет много, нужно продумать основные сценарии поиска. И на колонки, по которым будете искать, нужно повесить индексы.

Индекс это как алфавитный указатель в библиотеке. Вот представьте, заходите вы в библиотеку и хотите найти Преступление и наказание Достоевского. А все книги стоят от балды, никакого порядка. Чтобы найти нужную, надо обойти все стелажи и просмотреть все полки!

Совсем другое дело, если книги отсортированы по авторам. А внутри автора по названию. Тогда найти нужную книгу будет легко!

Индекс играет ту же роль для базы данных. Если повесить его на колонку таблицы, поиск по ней пойдет быстрее!

Хинты

Хинт это код, вставляемый в SQL-запрос, который позволяет изменить план выполнения запроса. Выглядит это примерно так:

SELECT /*+ NO_UNNEST( @SEL$4 ) */*FROM v;

Хинт идет внутри блока /* */.

А что еще за план выполнения запроса? Смотрите, когда вы выполняете любой запрос, что делает система:

1. Строит план выполнения запроса (как ей кажется, оптимальный)

2. Выполняет его

Посмотреть план можно через ключевые слова EXPLAIN PLAN (в Oracle):

EXPLAIN PLAN FOR -- построй мне план для...SELECT last_name FROM employees; -- вот такого запроса!

А если вы работаете через sql developer (графический интерфейс для обращения к базе Oracle), то можно просто выделить запрос и нажать F10:

Что мы видим на этой картинке? Запрос говорит: достань мне всю информацию из таблицы клиентов. Так как нет никаких условий where, то мы просто проходим фулл-сканом Table Access (full) по этом таблице. План показывает стоимость (cost) этого запроса 857 ms.

А теперь изменим запрос, сделав выборку по одному конкретному человеку по колонке с индексом:

Оп, цена запроса уже 5 ms. Это, на минуточку, в 170 раз быстрее!

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

Вот пример плана чуть более сложного запроса, когда мы делаем выборку из двух таблиц:

Вы не обязаны понимать, что тут вообще происходит, но вам нужно уметь получать этот план. Пригодится.

Допустим, поступает жалоба от заказчика клиент открывает карточку в вебе, а она открывается минуту. Что-то где-то тормозит! Но что и где? Начинаем разбираться. Причины бывают разные:

1. Тормозит на уровне БД тут или сам запрос долго отрабатывает, или статистику давно не пересобирали, или диски подыхают.

2. Тормозит на уровне приложения тогда надо копаться внутри кода функции открыть карточку, что она там делает, получив ответ от Базы (и снова есть вариант подыхают диски, на которых установлено ПО).

3. Тормозит на уровне сети сервер приложения и сервер БД обычно размещают на разных машинах. Значит, есть общение между ними по интернету. А интернет может тупить.

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

Собираете план, сохраняете в файлик и прикладываете в задачу в джире. Или отправляете по почте.

У меня бывало, что именно так находился баг на тестовой базе запрос идет по правильному пути, а на боевой нет. И на боевой идет не по индексам, что сильно его тормозит. Тут уже дальше разработчик думает, почему так получилось и как именно это исправить. Добавить индекс, хинт, или как-то иначе.

См также

17 Optimizer Hints в Oracle хинты в базе Oracle

Статистика

Именно статистика позволяет базе данных выбрать оптимальный план выполнения запроса. Почему вообще возникают проблемы вида на тестовой базе один план, на боевой другой?

Да потому, что один и тот же запрос можно выполнить несколькими способами. Например, у нас есть таблица клиентов и таблица телефонов, и мы пишем такой запрос:

Найди мне всех клиентов, созданных в этом году,

У которых оператор связи в телефоне Мегафон

Как можно выполнить запрос? Можно сначала обойти таблицу клиентов и поискать тех, кто создан в этом году. А потом уже для них проверять телефоны. Можно наоборот, проверить все телефоны на оператора и потом уже для связанных клиентов проверять дату создания.

Какой вариант будет лучше? Никто не скажет без данных по таблицам. Может, у нас мало клиентов, но кучи телефонов (база перекупщиков), тогда быстрее будет начать с клиентов. А может, у нас куча миллионы клиентов, но всего пара сотен телефонов, тогда мы начнем с них.

Так вот, в статистике по БД хранится в том числе информация о распределении данных и характеристики хранения таблиц и индексов. И когда вы запускаете запрос, база (а точнее, оптимизатор внутри нее) строит возможные планы выполнения. Для каждого плана рассчитывает примерное время выполнения, а потом выбирает лучшее.

Время же он рассчитывает, ориентируясь на статистику:

• Сколько данных находится в таблице?

• Есть ли индекс по колонке, по которой я буду искать?

Именно поэтому просто пересбор статистики иногда убирает проблему у нас тут тормозит. Прилетело в таблицу много данных, а статистика об этом не знает, и чешет по таблице через фуллскан, считая, что информации там мало.

См также:

Ручной и автоматический сбор статистики оптимизатора в базе данных Oracle

Преимущества базы данных

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

1. Базы поддерживают требования ACID (по крайней мере транзакционные БД)

2. Это единый синтаксис SQL, который используется повсеместно

Требования ACID

ACID это аббревиатура из требований, которые обеспечивают сохранность ваших данных:

• Atomicity Атомарность

• Consistency Согласованность

• Isolation Изолированность

• Durability Надёжность

Если база данных не поддерживает их, то могут быть печальные последствия из серии Деньги с одного счета ушли, на другой не пришли? Ну сорян, бывает.

См также:

Требования ACID на простом языке подробнее об этих требованиях

Единый синтаксис SQL

Я спросила знакомого разработчика:

Ну и что, что единый синтаксис? В чем его плюшка то?

Ответ прекрасен, так что делюсь с вами:

Почему в школе все преподают на русском? Почему не каждый свой язык? Одна школа один, другая другой. А ещё лучше не школа, а для каждого человека. Почему вавилонскую башню недостроили?

Как разработчик пишет код? Написал, проверил на коленке. Если не работает думает, почему. Если непонятно, идет гуглить похожие ошибки. А что проще нагуглить? Ошибку распространенной БД, или сделанный на коленке костыль для работы с файлами? Вот то-то и оно...

Что знать для собеседования

Для начала я хочу уточнить, что я сама тестировщик. И мои статьи в первую очередь для тестировщиков ))

Так вот, тестировщика на собеседовании не будут спрашивать про базы данных. Разработчика ещё могут спросить, а вас то зачем? Вполне достаточно понимания, что это вообще такое. И про ключи могут спросить что такое primary или foreign key, зачем они вообще нужны.

Зато тестировщика спрашивают про SQL. Вот вам обсуждение из чатика выпускников, пригодится для повторения материала:

В вакансии написано: уметь составлять простые SQL запросы. А простые это какие в народном понимании?

(inner, outer) join, select, insert, update, create, последнее время популярны индексы, group by, having, distinct.

SQL выходит за рамки данной статьи, здесь я лишь пояснила, что это вообще такое. А дальше читайте статьи / книги из следующего раздела, или гуглите каждое слово из цитаты выше.

Статьи и книги по теме

База данных

Википедия

Какие бывают базы данных

Базы данных. Виды и типы баз данных. Структура реляционных баз данных. Проектирование баз данных. Сетевые и иерархические базы данных.

SQL

Книги:

Изучаем SQL. Линн Бейли Обожаю эту линейку книг, серию Head First O`Reilly. И всем рекомендую)) Просто и доступно даже о сложном пишут.

Статьи:

Как изучить основы SQL за 2 дня

Полезные запросы

Тренажеры:

http://www.sql-ex.ru/ Бесплатный тренажер для практики

Ресурсы и инструменты для практики с базами данных | SQL

Задачка по SQL. Найти объединенные данные

Резюме

База данных это место для хранения данных. Они бывают самых разных видов, даже файловые! Но самые распространенные реляционные базы данных, где данные хранятся в виде таблиц.

Если посмотреть на информацию о таблице в БД, мы можем увидеть ее ключи и индексы. Что это такое:

1.PK primary key, первичный ключ. Гарантирует уникальность данных, часто используется для колонки с ID. Если ключ наложен на одну колонку каждое значение в ячейках этой колонки уникальное. Если на несколько комбинации строк по колонкам уникальны.

2.FK foreign key, внешний ключ. Нужен для связки двух таблиц в разных соотношениях (1:1, 1:N, N:N). Этот ключ указываем в "дочерней" таблице, то есть в той, которая ссылается на родительскую (в таблице с данными по лицевому счету отсылка на client_id из таблицы клиентов).

3.Индекс. Нужен для ускорения выборки из таблицы.

Транзакционные базы данных выполняют требования ACID:

• Atomicity Атомарность

• Consistency Согласованность

• Isolation Изолированность

• Durability Надежность

См также:

Что такое транзакция

И за это их выбирают разработчики. Мы получаем не просто хранилище данных. Наши данные защищены от неприятностей типа отключения электричества на середине бизнес-операции (с одного счета деньги списать, на другой записать). А еще по ним можно быстро искать, ведь разработчики баз данных оптимизируют свои приложения для этого.

Поэтому логика приложения отдельно, база отдельно. Так и получается клиент-серверная архитектура =)

См также:

Клиент-серверная архитектура в картинках

Чтобы достать данные из базы, надо написать запрос к ней на языке SQL (Structured Query Language). Разработчики пишут SQL-запросы внутри кода приложения. А тестировщики используют SQL для:

• Поиска по базе правильно ли данные сохранились? В нужные таблицы легли? Это select-запросы.

• Подготовки тестовых данных а что, если это значение будет пустое? А что, если у меня будет 2 лицевых счета на одной карточке? Можно готовить данные через графический интерфейс, но намного быстрее отправить несколько запросов в базу. Когда есть к ней доступ и вы знаете SQL =)

План-минимум для изучения: select, join, insert, update, create, delete, group by, having, distinct.

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Что такое Impact Analysis?

Прежде всего, Impact Analysis (импакт анализ) - это исследование, которое позволяет указать затронутые места (affected areas) в проекте при разработке новой или изменении старой функциональности, а также определить, насколько значительно они были затронуты.

Затронутые области требуют большего внимания во время проведения регрессионного тестирования.

Отмечу сразу, чтобы не пугать QA: импакт анализ не есть "чтение кода". Он включает в себя и иные способы исследования.

Когда нужно проводить Impact Analysis?

Импакт анализ может быть полезным в следующих случаях:

• есть изменения в требованиях;

• получен запрос на внесение изменений в продукт;

• ожидается внедрение нового модуля или функциональности в существующий продукт;

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

Как мы знаем, в настоящее время продукты становятся всё более большими и комплексными, а компоненты всё чаще зависят друг от друга. Изменение строчки кода в таком проекте может "сломать" абсолютно всё.

Для чего нужно проводит Impact Analysis?

Информация о взаимосвязи и взаимном влиянии изменений могут помочь QA:

• сфокусироваться на тестировании функциональности, где изменения были представлены;

• принять во внимание части проекта, которые были затронуты изменениями и, возможно, пострадали;

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

Как провожу Impact Analysis я?

1. Изучаю issue\ticket\bug\change request *.

2. Читаю email переписку **.

3. Разговариваю в разработчиками **.

4. Смотрю на место где было изменение (commit place) ***.

5. Смотрю на описание изменения (commit description) ***.

6. Смотрю на изменения в коде *****.

'*' показывает "уровень сложности" этого действия. Как видно, только "шаг 6" требует умения читать код, с "шагами 1-5" способен справится QA и без знаний языком программирования.

1. Изучение issue\ticket\bug\change request *

Самое основное и базовое (поэтому и сложность *), что нужно сделать, - это внимательно изучить ишью в баг-трекинговой системе. Следует обратить внимание на все поля, особенно:

• Steps To Repeat;

• Description;

• Additional Background Information;

• Attachment;

Некоторые важные условия или особенности, описанные в ишью, помогут вам идентифицировать область тестирования. Например, при внимательном прочтении ишью, вы обнаружили, что в 'Additional Background Information' стоит пометка, что проблема воспроизводится только при использовании HTTPs. Поэтому для себя можно отметить, что при тестировании неплохо было бы проверить и случай с HTTP.

2. Чтение emails

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

• больше деталей от заказчиков;

• результаты исследований от других членов команды;

• список похожих проблем;

• картинки, графики, схемы и другое.

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

3. Разговор с разработчиками **

Во время тестирования изменений ваша цель - найти как можно больше "поломавшегося" и поэтому стоит смело подойти к разработчикам, к тем "кто возможно поломал" и спросить напрямую: "Ты сделал изменения, подскажи, на что они могут повлиять, какие области\модули мне нужно проверить тщательнее". Хороший разработчик, понимающий, что чем раньше баг будет обнаружен, тем дешевле будет его исправить, поможет вам советом, даже если будет абсолютно уверен в своих сделанных изменениях.

4. Изучение места, где было сделано изменение ***

Изменения, которые сделаны, должны быть куда-то внесены. В моём случае, это git, где достаточно легко можно определить место, где были сделаны изменения. Под "местом" я понимаю "конкретный файл, конкретная функция\метод, конкретный модуль". И следовательно, это "место" (этот модуль, функциональность) следует перепроверить, протестировать на наличие регрессий.

Например, на картинке выше видно, что изменения были в 'ExtendedClassification' функциональности, поэтому хотя бы, Smoke Test для этой функциональности должен быть пройден.

Так же, если изменения были в каких-то клиентских файлах ( JS, HTML, CSS, etc.), то следует провести кроссбраузерное тестирование.

Сложность "***" - чтение кода всё ещё не требуется, но нужно иметь представление об архитектуре проекта.

5. Изучение описания изменений ***

Для того, чтобы QA могли описания изучать, сначала нужно добиться того, чтобы Developers начали писать грамотные и понятные описания изменений. В моём отделе мы придерживается следующего шаблона, для описания изменении (git commits):

Ticket number and title

- Bug:

{В чём состоит дефект, какое актуальное поведение системы?}

- Problem:

{первопричина дефекта, что в системе работает не так?}

- Fix:

{в чём состоит изменение}

Например, исходя из описания исходной проблемы "Логика не работает при версировании root ItemType" (изображение сверху), следует, что нужно проверить "данную логику при версировании root ItemType". И имея в наличие только bug и его описание, эта важная проверка не столь очевидна и может быть пропущена.

6. Исследование кода изменений *****

Тут всё банально просто - нужно читать код и представлять, что он делает. Конечно, не многим это под силу на данном этапе, но есть к чему стремиться. К тому же, он QA не требуется глубокого понимание кода. Базовых знаний программирования и поверхностных знаний ООП (в моём случае) вполне достаточно, чтобы представить use case, покрывающий основные функции этого кода.

Почему я решила написать об этом?

Недавно в отделе столкнулась с тем, что разработчик сделал кое-какие изменения и отправил это в тестирование QA. Тестировщик естественно принял решение провести регрессионное тестирование, но без особого разбора и исследований установил, что нужно пойти все регрессионные тесты, которые в сумме занимают 25ч (проверка доступов, отработка разной функциональности, проверка в разных браузерах). Когда я решила взглянуть на сделанные изменения, то обнаружила следующее:

т.е. единственное изменение, которое было сделано, - это добавлена проверка, если ItemType не равен "HG_Modification Orger", то делай всё то же, что и делал раньше (сделай изменения и обнови окно), если ItemType равен "HG_Modification Orger", то пропусти (ничего не делай и просто обнови окно). Т.е. эти изменения никак не относятся к клиентской части (проверка в разных браузерах не нужна). Изменения никак не затрагивают доступы, отрисовку. Они затрагивают лишь определённую функциональность, которую нужно проверить для ItemType = "HG_Modification Orger" и для ItenType != "HG_Modification Orger". Эти проверки займут 30 минут в худшем случае. Но никак не 25 часов.

Это наглядный пример, как impact analysis помог уменьшить время проведения необходимого тестирование значительно.

За пять лет работы в Аркадии компании-разработчике программного обеспечения на заказ, где я работаю тестировщиком, мне довелось поучаствовать в самых разных проектах. Большая часть из них была связана с веб-разработкой, меньшая с мобильной. Некоторые проекты длились более года, другие были краткосрочными (полгода или даже пару месяцев). Менялся и размер команд: от трёх до трёх десятков человек.

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

Как всё начинается

Иногда к нам обращаются заказчики, которым нужно быстро разработать небольшой программный продукт. Например, новый сайт или приложение для смартфонов. Работы по такому проекту не очень много, и всё должно быть готово через несколько месяцев.

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

Поэтому заказчик хочет перевести мобильных пользователей на нативное приложение, содержащее основные возможности для пользователей. Функции, нужные только для контент-менеджеров, будут доступны в десктопной версии сайта.

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

Вся эта основа для проекта попадает к нашей команде. На краткосрочных проектах она невелика и состоит из менеджера проекта, двух-трёх программистов, UX/UI-дизайнера и тестировщика.

Когда и как начинается тестирование

Тестирование на краткосрочном проекте начинается с Shift left, то есть со сдвига тестирования влево относительно традиционного места в хвосте производственной цепочки, состоящей из определения требований, анализа и проектирования, кодирования, тестирования и развертывания.

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

Источник картинки:https://devopedia.org/shift-left

Ниже приведён набор вопросов, который поможет тестировщику сориентироваться на старте краткосрочного проекта.

Вопросник: тестирование концепции

Целевая аудитория и условия использования ПО

Материальная база тестирования на чём тестируем

Интеграция с тем, что уже есть

Опросив заказчика и изучив основу проекта, мы получаем детальное представление о концепции того софта, который нужно разработать. Всё это заносится в трекер задач и в вики проекта.

Тестирование требований

После того как концепция проекта сложилась, мы переходим к тестированию требований. Откудаэтитребования вообще берутся?У насониприходят от заказчика, фиксируются менеджером проекта и сразу идут в работу.

Поэтому тестирование требований идёт параллельно с тем, как программисты пишут код, а UX-дизайнер разрабатывает прототип. Задача тестировщика на этом этапе создать максимально целостное и непротиворечивое описание продукта и его работы. То есть описать ожидаемое поведение.

Описывая ожидаемое поведение, тестировщик закладывает базу для чек-листов, выявляет противоречия и пустые места. А затем находит ответы, задавая вопросы программистам и заказчику. Так мы отлавливаем часть багов ещё до того, как софт попадает на проверку. Иногда даже до того, как программист напишет код.

Тестировщик берёт требования в том виде, в котором они есть. Допустим, это будут user stories (пользовательские истории).

1. User story

Userstory(пользовательская история) состоитиз заголовка, представляющего собой основной сценарийиспользованияи дополнительныхсценариевсконкретикой.

Дополнительные сценарии могут быть описаны в критериях приёмки (acceptance criteria). О том, как их можно конкретизировать, я расскажу позже.

AcceptanceCriteria

2. Глоссарий проекта

Поскольку пользовательские истории пишутся человеческим, а не техническим языком, важно удостовериться, что:

а) понятия, упомянутые в истории, понимаются одинаково всеми участниками разработки. Например, под словом упражнения команда разработки и заказчик имеют в виду одно и то же;

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

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

Пример глоссария

3. Умолчания и дополнения

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

После восстановления умолчаний задаём вопросы для получения дополнительной информации:

4. Acceptance Criteria основа для чек-листа

Тестируя требования таким образом, мы получаем двойную выгоду:

а) конкретизируемAcceptanceCriteria;

б) закладываем основу для чек-листа.

Далее переходим к созданию основы чек-листа. На этом этапе выкидываем обороты типа система должна и также ожидаемо и отжимаем текст от воды до списка требований по пунктам.

Таким образом я обрабатываю как позитивные, так и негативные требования в том же порядке, в каком они встречаются в пользовательской истории. Потом сортирую: негативные требования идут в конец списка Acceptance Criteria, а позитивные в начало.

После того, как были конкретизированыAcceptanceCriteria, переходим к тест-дизайну.

Тест-дизайн и тестирование прототипа

Заголовок user story становится заголовком для группы проверок. Acceptance Criteria становится заголовком отдельного чек-листа или интеллект-карты, куда мы выписываем и ранжируем проверки.

Что получается в результате

Создание тест-кейсов на краткосрочных проектах, как правило, нецелесообразно. Специфика тест-кейсов заключается в том, что это подробное описание шагов, ожидаемой реакции системы и конечного результата. Это полезно, когда продукт большой, сложный, разработка идёт долго, в команду регулярно приходят новые люди. Тогда тест-кейсы пригодятся при подключении к разработке новичков, а для старых сотрудников при проверке сложной функциональности с неочевидными шагами.

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

Примеринтеллект-карты

Источник картинки: автор статьи

Для того, чтобы создать максимально эффективные проверки, при их разработке используем техники тест-дизайна. Например, разбиение на классы эквивалентности, анализ граничных значений, таблицы решений.

В параллель с тем, как тестировщик пишет чек-листы, UX/UI-дизайнер создаёт прототип. Тестировщик проверяет интерфейс прототипа, корректирует чек-листы, обсуждает найденное с командой.

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

Специфика тестирования в краткосрочном проекте

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

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

Начинаем с позитивных кейсов. Мы хотим убедиться,чтоесли пользователь делает всё как надо, он получает ожидаемый результат.

Пример позитивного кейса

<Пользователь может делать задания с 9:00 утра до 8:59 вечера>

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

Пример негативного кейса

<Задания недоступны для просмотра и выполнения с 9:00 вечера до 8:59 утра>

До релиза тестировщик проверяет как функционал, описанный в отдельных пользовательских историях, так и весь продукт целиком. Смотрит, корректно ли происходит установка, обновление, удаление продукта. Даёт обратную связь программистам, фиксирует баги в трекере, дорабатывает чек-листы.

Баги в трекере наряду с чек-листами помогают поддерживать и сопровождать продукт. Заказчик знает, какие дефекты есть в продукте, и может выбрать, какие из них исправлять в первую очередь.

Жизнь после релиза

И вот наш продукт становится доступен конечным пользователям. От них приходят первые отзывы и первые баги.Это нормально, поскольку исчерпывающее тестированиена начальном этапенедостижимо,икакие-тоошибкивсё равно будут.

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

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

Перепроверяя фикс, тестировщик добавляет проверки в чек-листы, углублённо тестирует функционал вокруг бага. Иногда таким образом тестировщик находит связанные баги, которые команда успевает починить до того, как их обнаружат пользователи.

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

Да и самому себе оставить памятку дело нелишнее. Краткосрочность краткосрочностью, но иногда маленький проект становится основой большего. И через какое-то время использования софта приходит заказ на написание дополнительного функционала.

Заключение

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

Далее следует этап тестирования требований, во время которого тестировщик создаёт максимально целостное и непротиворечивое описание продукта и его работы. Здесь идёт работа с user story и acceptance criteria, на основе которых тестировщик составляет чек-листы и интеллект-карты со списком конкретных проверок.

Следующими этапами тестирования будут: тестирование прототипа от UX/UI-дизайнера, тестирование отдельных функциональностей от программистов и тестирование готовых версий. Использование трекера задач на всех этапах проекта важно не только для длительного проекта, но и для краткосрочного, так как помогает поддерживать и сопровождать продукт, что особенно ценно при передаче проекта заказчику.

Сразу напрашивается вопрос, а кто спрашивает?

Воображение рисует студента последнего курса технического ВУЗа, знания которого более менее свежи, информации дано много, программирование потрогано на нескольких языках, но вот оно не притягивает. Вот стартануть будет в профессии легко, дообучения будет много, но и рост знании будет шустрыи. Работать будет становиться все сложнеи, но потому , что знания позволят залезть глубже в работу программистов, в продукт. Бекграунд позволит предположить вариантов проблем больше, но и наидено будет не мало. Не будет легко, но легко было бы и не интересно.

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

Если уж ударяться в краиности, то дальше воображаем человека лет 50-55, работал где-то, даже программировал , но, например, на чистом C. Новое не изучал, но вот подумал, что надо что-то менять, попробовать. Честно в резюме описываешь опыт , весь сугубо техническии. Но откликов нет, все же понимают, что придется обучать. Опыт привлекает, но возраст отпугивает , и не понимают, сможет ли такои человек обучаться новому и быстро. А тут уж даже если и устроится человек, то простым его путь не вижу.

Получается, что путь легким в данных ситуациях не выглядит. Но если смотреть прицельно, то а кто спрашивает?

Если подняла до этого абстрактныи вопрос, сложно ли работать в целом, то дальше хочу рассмотреть конкретные сложности.

Их можно мне кажется перечислять очень долго, уже не говоря о том, что у каждого они свои. То, что проблема для одного тестировщика, совсем не проблема для другого.

Не знание какого-то инструмента.

Часто приходится работать с каким новым инструментом. Либо его использует вся команда, а ты видишь первыи раз. Либо надо было какои-то внедрять, кто-то изучил и выбрал, а ты уже поставлен перед фактом. Второи вариант удобнее, так как изучивший не только должен подготовить какие-то инструкции и демонстрации, но и совместно внедряя, будет подниматься много вопросов, которые сразу же будут решаться. В первом варианте приходится делать большинство исследовании самому, и повезет, если внедряя, параллельно написали инструкции и гаиды, что делается не всегда. И если есть хороший ментор или наставник, то один раз он может помочь и настроить, и провести какие то первые тесты вместе. Рекомендую искать инструкции по настроике и использованию на официальном саите. Вроде простая рекомендация, но первым делом идут в гугл, а я частенько замечала копирования просто с официального сайта. И возможно его инструкций будет с головой хватать для решения всех вопросов, как минимум на первых порах.

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

Одним из сложных моментов я бы ещё назвала неоднозначные формулировки в описании ТЗ (техническое задание, по которому тестируем).

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

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

Часто решением проблемы однозначного понимания занимается проджект проекта. Хотя это цель всей команды разработки. Главное, определить места, которые могут быть поняты неоднозначно. Вся команда заинтересована на первых же этапах выяснить то, что на самом деле мы делаем и зачем. И чтобы это поняли все участники разработки (от постановщика до тестировщика).

Про разные проблемы и сложности в работе QA можно долго рассказывать, попробовала выделить какие то совсем больные точки, на которые я натыкалась. Если хоть немного было интересно, то могла бы продолжить.

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

Чем это лучше простого поиска? Тем, что позволяет задать шаблон.

Например, на вход приходит дата рождения в формате ДД.ММ.ГГГГГ. Вам надо передать ее дальше, но уже в формате ГГГГ-ММ-ДД. Как это сделать с помощью простого поиска? Вы же не знаете заранее, какая именно дата будет.

А регулярное выражение позволяет задать шаблон найди мне цифры в таком-то формате.

Для чего применяют регулярные выражения?

1. Удалить все файлы, начинающиеся на test (чистим за собой тестовые данные)

2. Найти все логи

3. grep-нуть логи

4. Найти все даты

5. ...

А еще для замены например, чтобы изменить формат всех дат в файле. Если дата одна, можно изменить вручную. А если их 200, проще написать регулярку и подменить автоматически. Тем более что регулярные выражения поддерживаются даже простым блокнотом (в Notepad++ они точно есть).

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

Содержание

1. Где пощупать

2. Поиск текста

3. Поиск любого символа

4. Поиск по набору символов

5. Перечисление вариантов

6. Метасимволы

7. Спецсимволы

8. Квантификаторы (количество повторений)

9. Позиция внутри строки

10. Использование ссылки назад

11. Просмотр вперед и назад

12. Замена

13. Статьи и книги по теме

14. Итого

1. Поиск текста

2. Поиск любого символа

3. Поиск по набору символов

4. Перечисление вариантов

5. Метасимволы

6. Спецсимволы

7. Квантификаторы (количество повторений)

8. Замена

9. Итого

Где пощупать

Любое регулярное выражение из статьи вы можете сразу пощупать. Так будет понятнее, о чем речь в статье вставили пример из статьи, потом поигрались сами, делая шаг влево, шаг вправо. Где тренироваться:

1. Notepad++ (установить Search Mode Regular expression)

2. Regex101 (мой фаворит в онлайн вариантах)

3. Myregexp

4. Regexr

Инструменты есть, теперь начнём

Поиск текста

Самый простой вариант регэкспа. Работает как простой поиск ищет точно такую же строку, как вы ввели.

Текст: Море, море, океан

Regex: море

Найдет: Море, море, океан

Выделение курсивом не поможет моментально ухватить суть, что именно нашел regex, а выделить цветом в статье я не могу. Атрибут BACKGROUND-COLOR не сработал, поэтому я буду дублировать регулярки текстом (чтобы можно было скопировать себе) и рисунком, чтобы показать, что именно regex нашел:

Обратите внимание, нашлось именно море, а не первое Море. Регулярные выражения регистрозависимые!

Хотя, конечно, есть варианты. В JavaScript можно указать дополнительный флажок i, чтобы не учитывать регистр при поиске. В блокноте (notepad++) тоже есть галка Match case. Но учтите, что это не функция по умолчанию. И всегда стоит проверить, регистрозависимая ваша реализация поиска, или нет.

А что будет, если у нас несколько вхождений искомого слова?

Текст: Море, море, море, океан

Regex: море

Найдет: Море, море, море, океан

По умолчанию большинство механизмов обработки регэкспа вернет только первое вхождение. В JavaScript есть флаг g (global), с ним можно получить массив, содержащий все вхождения.

А что, если у нас искомое слово не само по себе, это часть слова? Регулярное выражение найдет его:

Текст: Море, 55мореон, океан

Regex: море

Найдет: Море, 55мореон, океан

Это поведение по умолчанию. Для поиска это даже хорошо. Вот, допустим, я помню, что недавно в чате коллега рассказывала какую-то историю про интересный баг в игре. Что-то там связанное с кораблем... Но что именно? Уже не помню. Как найти?

Если поиск работает только по точному совпадению, мне придется перебирать все падежи для слова корабль. А если он работает по включению, я просто не буду писать окончание, и все равно найду нужный текст:

Regex: корабл

Найдет:

На корабле

И тут корабль

У корабля

Это статический, заранее заданный текст. Но его можно найти и без регулярок. Регулярные выражения особенно хороши, когда мы не знаем точно, что мы ищем. Мы знаем часть слова, или шаблон.

Поиск любого символа

. найдет любой символ (один).

Текст:

Аня

Ася

Оля

Аля

Валя

Regex: А.я

Результат:

Аня

Ася

Оля

Аля

Валя

Точка найдет вообще любой символ, включая цифры, спецсисимволы, даже пробелы. Так что кроме нормальных имен, мы найдем и такие значения:

А6я

А&я

А я

Учтите это при поиске! Точка очень удобный символ, но в то же время очень опасный если используете ее, обязательно тестируйте получившееся регулярное выражение. Найдет ли оно то, что нужно? А лишнее не найдет?

Точку точка тоже найдет!

Regex: file.

Найдет:

file.txt

file1.txt

file2.xls

Но что, если нам надо найти именно точку? Скажем, мы хотим найти все файлы с расширением txt и пишем такой шаблон:

Regex: .txt

Результат:

file.txt

log.txt

file.png

1txt.doc

one_txt.jpg

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

Но если мы хотим найти именно точку, то нужно ее заэкранировать то есть добавить перед ней обратный слеш:

Regex: \.txt

Результат:

file.txt

log.txt

file.png

1txt.doc

one_txt.jpg

Также мы будем поступать со всеми спецсимволами. Хотим найти именно такой символ в тексте? Добавляем перед ним обратный слеш.

Правило поиска для точки:

. любой символ

\. точка

Поиск по набору символов

Допустим, мы хотим найти имена Алла, Анна в списке. Можно попробовать поиск через точку, но кроме нормальных имен, вернется всякая фигня:

Regex: А..а

Результат:

Анна

Алла

аоикА74арплт

Аркан

А^&а

Абба

Если же мы хотим именно Анну да Аллу, вместо точки нужно использовать диапазон допустимых значений. Ставим квадратные скобки, а внутри них перечисляем нужные символы:

Regex: А[нл][нл]а

Результат:

Анна

Алла

аоикА74арплт

Аркан

А^&а

Абба

Вот теперь результат уже лучше! Да, нам все еще может вернуться Анла, но такие ошибки исправим чуть позже.

Как работают квадратные скобки? Внутри них мы указываем набор допустимых символов. Это может быть перечисление нужных букв, или указание диапазона:

[нл] только н и л

[а-я] все русские буквы в нижнем регистре от а до я (кроме ё)

[А-Я] все заглавные русские буквы

[А-Яа-яЁё] все русские буквы

[a-z] латиница мелким шрифтом

[a-zA-Z] все английские буквы

[0-9] любая цифра

[В-Ю] буквы от В до Ю (да, диапазон это не только от А до Я)

[А-ГО-Р] буквы от А до Г и от О до Р

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

[абв] только а, б или в

[а б в] а, б, в, или пробел (что может привести к нежелательному результату)

[а, б, в] а, б, в, пробел или запятая

Единственный допустимый разделитель это дефис. Если система видит дефис внутри квадратных скобок значит, это диапазон:

• Символ до дефиса начало диапазона

• Символ после конец

Один символ! Не два или десять, а один! Учтете это, если захотите написать что-то типа [1-31]. Нет, это не диапазон от 1 до 31, эта запись читается так:

• Диапазон от 1 до 3

• И число 1

Здесь отсутствие разделителей играет злую шутку с нашим сознанием. Ведь кажется, что мы написали диапазон от 1 до 31! Но нет. Поэтому, если вы пишете регулярные выражения, очень важно их тестировать. Не зря же мы тестировщики! Проверьте то, что написали! Особенно, если с помощью регулярного выражения вы пытаетесь что-то удалить =)) Как бы не удалили лишнее...

Указание диапазона вместо точки помогает отсеять заведомо плохие данные:

Regex: А.я или А[а-я]я

Результат для обоих:

Аня

Ася

Оля

Аля

Результат для А.я:

А6я

А&я

А я

^ внутри [] означает исключение:

[^0-9] любой символ, кроме цифр

[^ёЁ] любой символ, кроме буквы ё

[^а-в8] любой символ, кроме букв а, б, в и цифры 8

Например, мы хотим найти все txt файлы, кроме разбитых на кусочки заканчивающихся на цифру:

Regex: [^0-9]\.txt

Результат:

file.txt

log.txt

file_1.txt

1.txt

Так как квадратные скобки являются спецсимволами, то их нельзя найти в тексте без экранирования:

Regex: fruits[0]

Найдет: fruits0

Не найдет: fruits[0]

Это регулярное выражение говорит найди мне текст fruits, а потом число 0. Квадратные скобки не экранированы значит, внутри будет набор допустимых символов.

Если мы хотим найти именно 0-левой элемент массива фруктов, надо записать так:

Regex: fruits\[0\]

Найдет: fruits[0]

Не найдет: fruits0

А если мы хотим найти все элементы массива фруктов, мы внутри экранированных квадратных скобок ставим неэкранированные!

Regex: fruits\[[0-9]\]

Найдет:

fruits[0] = апельсин;

fruits[1] = яблоко;

fruits[2] = лимон;

Не найдет:

cat[0] = чеширский кот;

Конечно, читать такое регулярное выражение становится немного тяжело, столько разных символов написано...

Без паники! Если вы видите сложное регулярное выражение, то просто разберите его по частям. Помните про основу эффективного тайм-менеджмента? Слона надо есть по частям.

Допустим, после отпуска накопилась гора писем. Смотришь на нее и сразу впадаешь в уныние:

Ууууууу, я это за день не закончу!

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

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

Разберем по частям регулярное выражение fruits\[[0-9]\]

Сначала идет просто текст fruits.

Потом обратный слеш. Ага, он что-то экранирует.

Что именно? Квадратную скобку. Значит, это просто квадратная скобка в моем тексте fruits[

Дальше снова квадратная скобка. Она не экранирована значит, это набор допустимых значений. Ищем закрывающую квадратную скобку.

Нашли. Наш набор: [0-9]. То есть любое число. Но одно. Там не может быть 10, 11 или 325, потому что квадратные скобки без квантификатора (о них мы поговорим чуть позже) заменяют ровно один символ.

Пока получается: fruits[любое однозназначное число

Дальше снова обратный слеш. То есть следующий за ним спецсимвол будет просто символом в моем тексте.

А следующий символ ]

Получается выражение: fruits[любое однозназначное число]

Наше выражение найдет значения массива фруктов! Не только нулевое, но и первое, и пятое... Вплоть до девятого:

Regex: fruits\[[0-9]\]

Найдет:

fruits[0] = апельсин;

fruits[1] = яблоко;

fruits[9] = лимон;

Не найдет:

fruits[10] = банан;

fruits[325] = абрикос ;

Как найти вообще все значения массива, см дальше, в разделе квантификаторы.

А пока давайте посмотрим, как с помощью диапазонов можно найти все даты.

Какой у даты шаблон? Мы рассмотрим ДД.ММ.ГГГГ:

• 2 цифры дня

• точка

• 2 цифры месяца

• точка

• 4 цифры года

Запишем в виде регулярного выражения: [0-9][0-9]\.[0-9][0-9]\.[0-9][0-9][0-9][0-9].

Напомню, что мы не можем записать диапазон [1-31]. Потому что это будет значить не диапазон от 1 до 31, а диапазон от 1 до 3, плюс число 1. Поэтому пишем шаблон для каждой цифры отдельно.

В принципе, такое выражение найдет нам даты среди другого текста. Но что, если с помощью регулярки мы проверяем введенную пользователем дату? Подойдет ли такой regexp?

Давайте его протестируем! Как насчет 8888 года или 99 месяца, а?

Regex: [0-9][0-9]\.[0-9][0-9]\.[0-9][0-9][0-9][0-9]

Найдет:

01.01.1999

05.08.2015

Тоже найдет:

08.08.8888

99.99.2000

Попробуем ограничить:

• День недели может быть максимум 31 первая цифра [0-3]

• Максимальный месяц 12 первая цифра [01]

• Год или 19.., или 20.. первая цифра [12], а вторая [09]

Вот, уже лучше, явно плохие данные регулярка отсекла. Надо признать, она отсечет довольно много тестовых данных, ведь обычно, когда хотят именно сломать, то фигачат именно 9999 год или 99 месяц...

Однако если мы присмотримся внимательнее к регулярному выражению, то сможем найти в нем дыры:

Regex: [0-3][0-9]\.[0-1][0-9]\.[12][09][0-9][0-9]

Не найдет:

08.08.8888

99.99.2000

Но найдет:

33.01.2000

01.19.1999

05.06.2999

Мы не можем с помощью одного диапазона указать допустимые значения. Или мы потеряем 31 число, или пропустим 39. И если мы хотим сделать проверку даты, одних диапазонов будет мало. Нужна возможность перечислить варианты, о которой мы сейчас и поговорим.

Перечисление вариантов

Квадртатные скобки [] помогают перечислить варианты для одного символа. Если же мы хотим перечислить слова, то лучше использовать вертикальную черту |.

Regex: Оля|Олечка|Котик

Найдет:

Оля

Олечка

Котик

Не найдет:

Оленька

Котенка

Можно использовать вертикальную черту и для одного символа. Можно даже внутри слова тогда вариативную букву берем в круглые скобки

Regex: А(н|л)я

Найдет:

Аня

Аля

Круглые скобки обозначают группу символов. В этой группе у нас или буква н, или буква л. Зачем нужны скобки? Показать, где начинается и заканчивается группа. Иначе вертикальная черта применится ко всем символам мы будем искать или Ан, или ля:

Regex: Ан|ля

Найдет:

Аня

Аля

Оля

Малюля

А если мы хотим именно Аня или Аля, то перечисление используем только для второго символа. Для этого берем его в скобки.

Эти 2 варианта вернут одно и то же:

• А(н|л)я

• А[нл]я

Но для замены одной буквы лучше использовать [], так как сравнение с символьным классом выполняется проще, чем обработка группы с проверкой на все её возможные модификаторы.

Давайте вернемся к задаче проверить введенную пользователем дату с помощью регулярных выражений. Мы пробовали записать для дня диапазон [0-3][0-9], но он пропускает значения 33, 35, 39... Это нехорошо!

Тогда распишем ТЗ подробнее. Та-а-а-ак... Если первая цифра:

• 0 вторая может от 1 до 9 (даты 00 быть не может)

• 1, 2 вторая может от 0 до 9

• 3 вторая только 0 или 1

Составим регулярные выражения на каждый пункт:

• 0[1-9]

• [12][0-9]

• 3[01]

А теперь осталось их соединить в одно выражение! Получаем: 0[1-9]|[12][0-9]|3[01]

По аналогии разбираем месяц и год. Но это остается вам для домашнего задания

State & Transition Diagram (сокращенно S&T) схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.

Мы рисуем:

• кружочки состояния объекта;

• стрелочки то, благодаря чему из состояния А в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Например, задача запустилась автоматически в 10 часов вечера.

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

Схема состояний и переходов относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:

1. Вариант использования

2. Decision Table (таблицы решений)

3. State & Transition Diagram (схема состояний и переходов) текущая статья

4. Другие диаграммы, схемы, картинки (бонус такой к техникам) TBD

Сегодня поговорим про State & Transition Diagram:

1. Как рисовать диаграмму

2. Примеры S&T

3. Типовые ошибки при составлении карты

   • Вместо объекта GUI

   • Несколько объектов в одной карте

   • Несколько одинаковых состояний

4. Плюсы подхода

5. Минусы подхода

6. Инструменты для рисования

7. Итого

Как рисовать диаграмму

Очень важно: S&T рисуется на объект! Один объект. В идеале на объект, имеющий аналог в базе данных продукта.

Шаг 1. Вы выбираете объект в своём проекте (рабочем или учебном, не суть).

Шаг 2. Думаете, какие у него состояния. Они не должны пересекаться, то есть: объект не может быть разом в двух состояниях, и при этом он всегда хоть в каком-то одном есть

Шаг 3. Рисуете эти состояния кружочками.

Шаг 4. Соединяете их стрелочками. Стрелочки - это действия, их надо подписать.

Шаг 5. Смотрите, что получилось и анализируете, есть ли у объекта другие состояния? А другие действия между текущими состояниями? Переход на шаг 2.

Кто не будет выполнять эту последовательность шагов, очень рискует вместо S&T нарисовать схему вышивки крестиком)))

Чтобы начать, задайте себе вопросы:

1. Какой конкретно объект вы выбрали? Как он называется? (только один!)

2. Какие у этого объекта есть состояния?

Основное определение состояния "набор доступных и недоступных действий с объектом". Продукт всегда должен знать, в каком состоянии каждый его объект. Вообще, когда будете думать об объектах и состояниях, старайтесь представлять их аппаратную реализацию.

Объект это практически всегда строка в базе данных, старайтесь абстрагироваться от интерфейса вообще, и представляйте те действия, которые вы могли бы делать с объектом прямыми запросами в базу.

Вот пример хорошей диаграммы:

State Transition на примере тортика!

В чатике моей школы для тестировщиков был очень интересный диалог по поводу рисования State Transition. Студентка рисует его для просмотра сериала и пытается разобраться, как это сделать:

В ДЗ получила фидбэк, что сделала не схему состояний и переходов, а некую инструкцию по просмотру сериала, по факту показывающую одно его состояние в процессе просмотра. Но суть как раз в том, что сериал из непросмотренного может быть перемещен в другие состояния, отраженные в виде разделов в личном кабинете, с помощью четырех кнопок, которые на схеме являются действиями. Больше никаких действий с сериалом пользователю не доступно (загрузка, редактирование и т.д.)

Ну смотрите, Вы продолжаете описывать и смотреть на вещи, как пользователь, а надо как тестировщик. Сериалы из пустоты не берутся. Кто-то их закачивает. Значит, все же связка "сериала не существует" и "сериал загружен на сайт" уже есть)

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

По-хорошему у тестировщиков на это есть права) и им дают необходимый доступ.

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

Тут моя коллега решила объяснить рисование карты на примере... Тортика! Дальнейший диалог был просто потрясающий, не могу не поделиться им с вами (разумеется, с разрешения коллеги, все же это ее идея, а не моя). Итак, приступаем:

Вот смотрите... Торт любите? Или другую еду какую-нибудь)

Допустим)

Отлично.

Чтобы приготовить торт, нам нужны ингредиенты, правильно? Это то, из чего он состоит. Как и наши объекты из параметров, но только в граммах.

Так вот, от того, что какого-то ингредиента будет больше/меньше, состояние торта не изменится. Он будет по-прежнему "не существует".

Чтобы его состояние изменилось надо начать что-то с ними делать. Например, смешать, залить в форму и отправить в духовку. Тогда состояние будет "В процессе готовки".

Потом, когда бисквит испечется, мажем его кремом и украшаем. Он становится у нас "Торт украшен".

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

Мы можем съесть торт, тогда он станет "Торт съеден".

Возможно, мы уедем и не съедим торт, пока его можно есть. Тогда он станет "Торт испорчен".

Кстати, в процессе приготовления могли быть и другие ответвления. Например:

передержали бы бисквит, состояние изменилось бы на "Торт испорчен";

не стали бы украшать бисквит и корж испортился бы "Торт испорчен";

Ну тут-то я, получается, покупаю готовый торт. И уже размышляю, что с ним делать.

Ок, изначально торта у Вас не было. Потом у Вас появилось состояние "Торт куплен". А дальше то, что происходит после "Торт готов" \_()_/

Торт может быть съеден, может стать испорченным, может быть подарен, а только потом его уже съедят/не съедят, может быть выброшен. Все зависит от системы.

То есть, я правильно понимаю?

1.Купила

2.Поставила в холодильник на потом

3.Передумала, достала, надкусала

4.Снова передумала, решила съесть целиком, осилила половину

5. Расстроилась и решила не доедать вообще и выкинуть

Это всё не важно и состояние торта не меняется, пока он не съеден или не стух?)

Ну он же еще является тортом? Если его начали есть, но не закончили можно ввести промежуточное состояние "В процессе уничтожения" =))

1-2 это торт куплен

3-4 это в процессе уничтожения

5 выброшен

Тогда чем это отличается от

1. Купила добавлен на сайт/загружен на сайт/находится на сайте

2. Поставила в холодильник на потом сохранен, чтобы посмотреть позже

3 - 4. Передумала, достала, надкусала, снова передумала, решила съесть целиком, осилила половину в процессе просмотра/уничтожения

5. Расстроилась и решила не доедать вообще и выкинуть просмотр прерван/торт в помойке

5-е он еще в процессе.

У сериалов обычно прогресс есть, и его просто так не убрать :)

- либо досмотрел

- либо он в процессе просмотра

Спасибо!

Примеры S&T

Примеры диаграмм можно посмотреть в конфлюенсе (доступ открытый без авторизации). Туда я выношу хорошие работы своих студентов. Их там сильно больше, чем в этом разделе статьи + обычно там можно и сам исходник скачать, чтобы внимательно всё рассмотреть. Welcome =)

Вот некоторые из этих работ:

Ольга (объект тест)

Кристина (Fallout Shelter)

Fallout Shelter игра под iOS, Android. В постапокалиптическом мире несколько людей было выбрано для создания светлого будущего. Их поместили в небольшое убежище, уходящее под землю. Это убежище необходимо развивать, защищать от угроз из внешнего мира, увеличивать количество жителей, производить ресурсы, выполнять квесты.

State Transition для пина в Pinterest

Типовые ошибки при составлении карты

На примере своих студентов мы собрали несколько типовых ошибок, которые допускают тестировщики, впервые рисуя карту:

1. Вместо объекта GUI

Очень важно: S&T рисуется на объект! Это не зарисовка графического интерфейса открыта страница такая, открыта страница сякая... Если вы описываете разные странички GUI это уже не S&T.

Зарисовывать страницы смысла обычно нет. Это как при рисовании майнд-карты мы не рисуем графический интерфейс, мы описываем функционал. То, зачем пользователь вообще пришел на сайт. Это намного полезнее!

См также:

Как нарисовать карту приложения (mind map)

Другой вариант той же ошибки: искать билет (результаты поиска) открыть форму покупки (форма открыта) ввести данные кредитной карты (данные введены).

2. Несколько объектов в одной карте

На прошлой картинке у нас несколько объектов: результаты поиска, форма, данные. И все плохие. Потому что там мы явно что-то покупаем, вот это что-то и есть объект!

Но когда мы описываем покупку, тоже легко скатиться в несколько объектов в одной карте: "пицца в корзине", "заказ оформлен".

Товар тоже очень часто путают, потому что есть два варианта:

1. как на авито продается конкретная вещь: "Нет на сайте", "Продается", "Продан".

2. просто "товарная позиция", как какие-нибудь носки в магазине одежды: "Отсутствует", "В наличии", "Ожидается поступление" и так далее.

Если речь о сайте типа авито, то объект лучше выбрать "объявление", будет логичнее. А вот если мы покупаем пиццу это будет товарной позицией.

3. Несколько одинаковых состояний

Вспомните пример с тортиком:

1. Купила.

2. Поставила в холодильник на потом.

3. Передумала, достала, надкусала.

4. Снова передумала, решила съесть целиком, осилила половину.

5. Расстроилась, решила не доедать вообще и выкинуть.

Половину пунктов можно объединить. Ведь состояние торта не меняется от того, купили вы его только что или час назад, сидите любуетесь на него, переставляете с места на место или убираете в холодильник:

• 1-2 это торт куплен;

• 3-4 в процессе уничтожения;

• 5 выброшен.

Другой пример объект пин:

• пин создан;

• пин откоментирован;

• пин перенесен другим пользователем себе на доску.

Но, когда пин откомментирован или сдублирован это тоже самое, когда он просто создан. Состояние самого пина не меняется!

Или например:

• товар в базе

• товар найден при поиске

Одно и то же с точки зрения товара. Он как был, так и есть =)

Плюсы подхода

Плюс рисования это визуализация ТЗ, которая:

1. Красиво выглядит

2. Позволяет увидеть, что мы упустили

На входе унылая стена текста, а мы красиво зарисовали, при этом разными цветами вот данные попали туда, вот сюда... В итоге наглядно видим весь маршрут нашего объекта.

И пока мы рисуем его маршрут, мы можем сразу же заметить, что Ага! Вот из этого состояния, наверное, можно вернуться ещё вот в это, то есть мы можем понять, что упускаем. А если бы не нарисовали, то даже не додумались бы до такого теста!

Минусы подхода

Не всегда визуализация делает ТЗ понятнее. И тогда начинаем думать, как это решать:

1. Слишком насыщенная карта разбиваем на несколько маленьких.

2. Сложно поддерживать нужна ли она вообще?

Если на диаграмме куча всего это плохо, ведь ее главная фишка понятность. И если мы на нее смотрим и просто теряемся в этом объеме стрелочек значит, схема нам не помогает.

Поэтому если схема насыщенная разбиваем на мелкие. Которые, возможно, ссылаются друг на друга. То есть вот есть верхнеуровневая схема, а вот на каждое действие есть уровни подетализированнее.

Не стоит рисовать все-все-все стрелочки. Из любого состояния можно закрыть браузер, но не надо рисовать это. Просто держите в уме, что есть кнопка закрыть, а еще может интернет пропасть, или сервер упадет, или еще какая катастрофа случится...

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

Инструменты для рисования

1. Бумага и ручка!!

2. Маркер и доска

3. Xmind (freemind, etc)

4. Microsoft Visio

5. PowerPoint

6. YeD

7. ...

Основной инструмент ручка и бумага, или маркер и доска. Потому что если вам надо просто обсудить, что будет, если из этого состояния перейти в это, и как должна система реагировать, если происходит вот то, то вполне достаточно нарисовать это от руки.

К тому же от руки получается быстрее, а иногда еще и красивее. Почему? Потому что когда мы начинаем использовать инструмент, то он нас ограничивает. Вот, нам надо нарисовать стрелочку, так, а как нам это сделать... Мы начинаем думать в стиле инструмента. Это как когда мы создаем презентации в power point, то вместо мыслей о докладе думаем, как бы назвать новый слайд.

А если бумажка рядом, можно спокойно генерить в голове идеи и условия. Что придумал? Зарисовал кое-как. Если очень хочется, потом перерисовал красиво. А, может, и так сойдет.

В любом случае смотрите сами. Если удобен какой-то инструмент используйте его! Хорошо получаются такие схемы в Xmind или Yed, или в гуглодокументах. Попробуйте использовать несколько разных инструментов, а потом выберите тот, что больше по душе. Но в целом бумага и ручка вполне себе вариант!

Итого

Рисунок мощнейший инструмент визуализации. Вот вы открываете статью с картинками, типа этой. На что вы смотрите в первую очередь на картинку или на текст? Правильно, на картинку.

Поэтому я за то, что рисовать! Нарисовали? Добавили в ТЗ! Всем удобнее, даже заказчику. Ведь с картинками текс становится понятнее.

Настоятельно рекомендую рисовать диаграмму состояний и переходов. Пусть даже одноразово,маркером на доске, чтобы обсудить новое ТЗ, которое пришло от аналитиков.

Зарисовали, позвали аналитика и стали обсуждать:

А вот смотрите, вот эта стрелочка... может нам стоит сделать еще вот это?

А что будет, если вот так?

Кстати, лайфхак. Если зарисовали маркером и жалко свое творчество (уж больно продуктивное общение с командой вышло) сфотографируйте и выложите в конфлюенс рисунок! Не обязательно тратить время на перерисовку =)

См также:

Как составлять вариант использования вариант оформления требований без рисований.

Decision Table что это и как применять и ещё один вариант, рисуем таблички.

PowerPoint как инструмент тестировщика да, так тоже можно было =)

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

State & Transition Diagram (сокращенно S&T) схема состояний и переходов. Техника для визуализации ТЗ. Она наглядно показывает, как некий объект переходит из одного состояния в другое.

Вот объект находился в состоянии А, потом произошло какое-то действие, и он попал в состояние В. Потом он попадет в состояние С и другие... Принцип не меняется, было одно состояние, стало другое.

Мы рисуем:

• кружочки состояния объекта;

• стрелочки то, благодаря чему из состояния А в состояние В. Это действие, но его может совершить не только пользователь, но и система сама. Например, задача запустилась автоматически в 10 часов вечера.

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

Схема состояний и переходов относится к техникам тест-дизайна. Значит, про неё спрашивают на собеседованиях. И поэтому я сделаю небольшой цикл статей по таким техникам в помощь начинающим тестировщикам. Чтобы ознакомиться с каждой техникой:

1. Вариант использования

2. Decision Table (таблицы решений)

3. State & Transition Diagram (схема состояний и переходов) текущая статья

4. Другие диаграммы, схемы, картинки (бонус такой к техникам) TBD

Сегодня поговорим про State & Transition Diagram:

1. Как рисовать диаграмму

2. Примеры S&T

3. Типовые ошибки при составлении карты

   • Вместо объекта GUI

   • Несколько объектов в одной карте

   • Несколько одинаковых состояний

4. Плюсы подхода

5. Минусы подхода

6. Инструменты для рисования

7. Итого

Как рисовать диаграмму

Очень важно: S&T рисуется на объект! Один объект. В идеале на объект, имеющий аналог в базе данных продукта.

Шаг 1. Вы выбираете объект в своём проекте (рабочем или учебном, не суть).

Шаг 2. Думаете, какие у него состояния. Они не должны пересекаться, то есть: объект не может быть разом в двух состояниях, и при этом он всегда хоть в каком-то одном есть

Шаг 3. Рисуете эти состояния кружочками.

Шаг 4. Соединяете их стрелочками. Стрелочки - это действия, их надо подписать.

Шаг 5. Смотрите, что получилось и анализируете, есть ли у объекта другие состояния? А другие действия между текущими состояниями? Переход на шаг 2.

Кто не будет выполнять эту последовательность шагов, очень рискует вместо S&T нарисовать схему вышивки крестиком)))

Чтобы начать, задайте себе вопросы:

1. Какой конкретно объект вы выбрали? Как он называется? (только один!)

2. Какие у этого объекта есть состояния?

Основное определение состояния "набор доступных и недоступных действий с объектом". Продукт всегда должен знать, в каком состоянии каждый его объект. Вообще, когда будете думать об объектах и состояниях, старайтесь представлять их аппаратную реализацию.

Объект это практически всегда строка в базе данных, старайтесь абстрагироваться от интерфейса вообще, и представляйте те действия, которые вы могли бы делать с объектом прямыми запросами в базу.

Вот пример хорошей диаграммы:

State Transition на примере тортика!

В чатике моей школы для тестировщиков был очень интересный диалог по поводу рисования State Transition. Студентка рисует его для просмотра сериала и пытается разобраться, как это сделать:

В ДЗ получила фидбэк, что сделала не схему состояний и переходов, а некую инструкцию по просмотру сериала, по факту показывающую одно его состояние в процессе просмотра. Но суть как раз в том, что сериал из непросмотренного может быть перемещен в другие состояния, отраженные в виде разделов в личном кабинете, с помощью четырех кнопок, которые на схеме являются действиями. Больше никаких действий с сериалом пользователю не доступно (загрузка, редактирование и т.д.)

Ну смотрите, Вы продолжаете описывать и смотреть на вещи, как пользователь, а надо как тестировщик. Сериалы из пустоты не берутся. Кто-то их закачивает. Значит, все же связка "сериала не существует" и "сериал загружен на сайт" уже есть)

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

По-хорошему у тестировщиков на это есть права) и им дают необходимый доступ.

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

Тут моя коллега решила объяснить рисование карты на примере... Тортика! Дальнейший диалог был просто потрясающий, не могу не поделиться им с вами (разумеется, с разрешения коллеги, все же это ее идея, а не моя). Итак, приступаем:

Вот смотрите... Торт любите? Или другую еду какую-нибудь)

Допустим)

Отлично.

Чтобы приготовить торт, нам нужны ингредиенты, правильно? Это то, из чего он состоит. Как и наши объекты из параметров, но только в граммах.

Так вот, от того, что какого-то ингредиента будет больше/меньше, состояние торта не изменится. Он будет по-прежнему "не существует".

Чтобы его состояние изменилось надо начать что-то с ними делать. Например, смешать, залить в форму и отправить в духовку. Тогда состояние будет "В процессе готовки".

Потом, когда бисквит испечется, мажем его кремом и украшаем. Он становится у нас "Торт украшен".

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

Мы можем съесть торт, тогда он станет "Торт съеден".

Возможно, мы уедем и не съедим торт, пока его можно есть. Тогда он станет "Торт испорчен".

Кстати, в процессе приготовления могли быть и другие ответвления. Например:

передержали бы бисквит, состояние изменилось бы на "Торт испорчен";

не стали бы украшать бисквит и корж испортился бы "Торт испорчен";

Ну тут-то я, получается, покупаю готовый торт. И уже размышляю, что с ним делать.

Ок, изначально торта у Вас не было. Потом у Вас появилось состояние "Торт куплен". А дальше то, что происходит после "Торт готов" \_()_/

Торт может быть съеден, может стать испорченным, может быть подарен, а только потом его уже съедят/не съедят, может быть выброшен. Все зависит от системы.

То есть, я правильно понимаю?

1.Купила

2.Поставила в холодильник на потом

3.Передумала, достала, надкусала

4.Снова передумала, решила съесть целиком, осилила половину

5. Расстроилась и решила не доедать вообще и выкинуть

Это всё не важно и состояние торта не меняется, пока он не съеден или не стух?)

Ну он же еще является тортом? Если его начали есть, но не закончили можно ввести промежуточное состояние "В процессе уничтожения" =))

1-2 это торт куплен

3-4 это в процессе уничтожения

5 выброшен

Тогда чем это отличается от

1. Купила добавлен на сайт/загружен на сайт/находится на сайте

2. Поставила в холодильник на потом сохранен, чтобы посмотреть позже

3 - 4. Передумала, достала, надкусала, снова передумала, решила съесть целиком, осилила половину в процессе просмотра/уничтожения

5. Расстроилась и решила не доедать вообще и выкинуть просмотр прерван/торт в помойке

5-е он еще в процессе.

У сериалов обычно прогресс есть, и его просто так не убрать :)

- либо досмотрел

- либо он в процессе просмотра

Спасибо!

Примеры S&T

Примеры диаграмм можно посмотреть в конфлюенсе (доступ открытый без авторизации). Туда я выношу хорошие работы своих студентов. Их там сильно больше, чем в этом разделе статьи + обычно там можно и сам исходник скачать, чтобы внимательно всё рассмотреть. Welcome =)

Вот некоторые из этих работ:

Ольга (объект тест)

Кристина (Fallout Shelter)

Fallout Shelter игра под iOS, Android. В постапокалиптическом мире несколько людей было выбрано для создания светлого будущего. Их поместили в небольшое убежище, уходящее под землю. Это убежище необходимо развивать, защищать от угроз из внешнего мира, увеличивать количество жителей, производить ресурсы, выполнять квесты.

State Transition для пина в Pinterest

Типовые ошибки при составлении карты

На примере своих студентов мы собрали несколько типовых ошибок, которые допускают тестировщики, впервые рисуя карту:

1. Вместо объекта GUI

Очень важно: S&T рисуется на объект! Это не зарисовка графического интерфейса открыта страница такая, открыта страница сякая... Если вы описываете разные странички GUI это уже не S&T.

Зарисовывать страницы смысла обычно нет. Это как при рисовании майнд-карты мы не рисуем графический интерфейс, мы описываем функционал. То, зачем пользователь вообще пришел на сайт. Это намного полезнее!

См также:

Как нарисовать карту приложения (mind map)

Другой вариант той же ошибки: искать билет (результаты поиска) открыть форму покупки (форма открыта) ввести данные кредитной карты (данные введены).

2. Несколько объектов в одной карте

На прошлой картинке у нас несколько объектов: результаты поиска, форма, данные. И все плохие. Потому что там мы явно что-то покупаем, вот это что-то и есть объект!

Но когда мы описываем покупку, тоже легко скатиться в несколько объектов в одной карте: "пицца в корзине", "заказ оформлен".

Товар тоже очень часто путают, потому что есть два варианта:

1. как на авито продается конкретная вещь: "Нет на сайте", "Продается", "Продан".

2. просто "товарная позиция", как какие-нибудь носки в магазине одежды: "Отсутствует", "В наличии", "Ожидается поступление" и так далее.

Если речь о сайте типа авито, то объект лучше выбрать "объявление", будет логичнее. А вот если мы покупаем пиццу это будет товарной позицией.

3. Несколько одинаковых состояний

Вспомните пример с тортиком:

1. Купила.

2. Поставила в холодильник на потом.

3. Передумала, достала, надкусала.

4. Снова передумала, решила съесть целиком, осилила половину.

5. Расстроилась, решила не доедать вообще и выкинуть.

Половину пунктов можно объединить. Ведь состояние торта не меняется от того, купили вы его только что или час назад, сидите любуетесь на него, переставляете с места на место или убираете в холодильник:

• 1-2 это торт куплен;

• 3-4 в процессе уничтожения;

• 5 выброшен.

Другой пример объект пин:

• пин создан;

• пин откоментирован;

• пин перенесен другим пользователем себе на доску.

Но, когда пин откомментирован или сдублирован это тоже самое, когда он просто создан. Состояние самого пина не меняется!

Или например:

• товар в базе

• товар найден при поиске

Одно и то же с точки зрения товара. Он как был, так и есть.

Плюсы подхода

Плюс рисования это визуализация ТЗ, которая:

1. Красиво выглядит

2. Позволяет увидеть, что мы упустили

На входе унылая стена текста, а мы красиво зарисовали, при этом разными цветами вот данные попали туда, вот сюда... В итоге наглядно видим весь маршрут нашего объекта.

И пока мы рисуем его маршрут, мы можем сразу же заметить, что Ага! Вот из этого состояния, наверное, можно вернуться ещё вот в это, то есть мы можем понять, что упускаем. А если бы не нарисовали, то даже не додумались бы до такого теста!

Минусы подхода

Не всегда визуализация делает ТЗ понятнее. И тогда начинаем думать, как это решать:

1. Слишком насыщенная карта разбиваем на несколько маленьких.

2. Сложно поддерживать нужна ли она вообще?

Если на диаграмме куча всего это плохо, ведь ее главная фишка понятность. И если мы на нее смотрим и просто теряемся в этом объеме стрелочек значит, схема нам не помогает.

Поэтому если схема насыщенная разбиваем на мелкие. Которые, возможно, ссылаются друг на друга. То есть вот есть верхнеуровневая схема, а вот на каждое действие есть уровни подетализированнее.

Не стоит рисовать все-все-все стрелочки. Из любого состояния можно закрыть браузер, но не надо рисовать это. Просто держите в уме, что есть кнопка закрыть, а еще может интернет пропасть, или сервер упадет, или еще какая катастрофа случится...

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

Инструменты для рисования

1. Бумага и ручка!!

2. Маркер и доска

3. Xmind (freemind, etc)

4. Microsoft Visio

5. PowerPoint

6. YeD

7. ...

Основной инструмент ручка и бумага, или маркер и доска. Потому что если вам надо просто обсудить, что будет, если из этого состояния перейти в это, и как должна система реагировать, если происходит вот то, то вполне достаточно нарисовать это от руки.

К тому же от руки получается быстрее, а иногда еще и красивее. Почему? Потому что когда мы начинаем использовать инструмент, то он нас ограничивает. Вот, нам надо нарисовать стрелочку, так, а как нам это сделать... Мы начинаем думать в стиле инструмента. Это как когда мы создаем презентации в power point, то вместо мыслей о докладе думаем, как бы назвать новый слайд.

А если бумажка рядом, можно спокойно генерить в голове идеи и условия. Что придумал? Зарисовал кое-как. Если очень хочется, потом перерисовал красиво. А, может, и так сойдет.

В любом случае смотрите сами. Если удобен какой-то инструмент используйте его! Хорошо получаются такие схемы в Xmind или Yed, или в гуглодокументах. Попробуйте использовать несколько разных инструментов, а потом выберите тот, что больше по душе. Но в целом бумага и ручка вполне себе вариант!

Итого

Рисунок мощнейший инструмент визуализации. Вот вы открываете статью с картинками, типа этой. На что вы смотрите в первую очередь на картинку или на текст? Правильно, на картинку.

Поэтому я за то, что рисовать! Нарисовали? Добавили в ТЗ! Всем удобнее, даже заказчику. Ведь с картинками текс становится понятнее.

Настоятельно рекомендую рисовать диаграмму состояний и переходов. Пусть даже одноразово,маркером на доске, чтобы обсудить новое ТЗ, которое пришло от аналитиков.

Зарисовали, позвали аналитика и стали обсуждать:

А вот смотрите, вот эта стрелочка... может нам стоит сделать еще вот это?

А что будет, если вот так?

Кстати, лайфхак. Если зарисовали маркером и жалко свое творчество (уж больно продуктивное общение с командой вышло) сфотографируйте и выложите в конфлюенс рисунок! Не обязательно тратить время на перерисовку =)

См также:

Как составлять вариант использования вариант оформления требований без рисований.

Decision Table что это и как применять и ещё один вариант, рисуем таблички.

PowerPoint как инструмент тестировщика да, так тоже можно было.

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Чем проще и понятнее описаны требования тем меньше багов будет в функционале. Потому что не будет разных прочтений, додумок и прочего. А еще в простыне текста легко потеряться и что-то просто забыть реализовать.

Как же сделать ТЗ понятнее? Можно улучшить текст вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...

Причем сделать это может не только аналитик, но и любой член команды. Тестировщикам особенно полезно визуализировать ТЗ, потому что это помогает сразу увидеть проблемные места и уточнить их ещё до реализации. Раннее тестирование и всё такое =)

А ещё техники, помогающие лучше понять требования, относятся к техникам тест-дизайна. Значит, о них стоит знать! В одну статью всё запихивать не стала и сделала отдельные:

1. Вариант использования

2. Decision Table (таблицы решений)

3. State & Transition Diagram (схема состояний и переходов)

Но значит ли это, что таблица или S&T единственный способ визуализации? Разумеется, нет! Можно рисовать вообще всё, что вам вздумается. Главное чтобы картинка помогала лучше понять требование или тест (да, при описании тестов визуализация тоже помогает!).

И сегодня я покажу разные примеры визуализации из своей практики, или работ моих студентов. Может, что-то из этого приглянётся и вам! =)

1. Как рисовать картинку

2. Примеры

3. Плюсы подхода

4. Минусы подхода

5. Инструменты для рисования

6. Итого

Как рисовать картинку

Берем требование и представляем в графическом виде. Всё!

Главное отличие от S&T в том, что нам необязательно рисовать именно объект. Мы рисуем всё, что захотим. Всё, что поможет сделать ТЗ более читабельным, да хоть интерфейс в виде карты! Или блок-схема, или что-то ещё.

Примеры

.

Карта сценариев

Функционал взаимодействия с конкретной книгой (взято из работ моих студентов):

Это карта сценариев, а не S&T, но он этого она не менее полезная!

.

Загрузка инкремента

Блок-схема про то, как это работает под капотом. На одном из проектов мы сделали довольно хитрую схему импорта данных из буферной таблицы. Для пользователей написан вариант использования, и там всё просто:

• Исходная система выгрузила данные в буферные таблицы.

• В таблице increment добавила номер выгруженного инкремента это будет флаг для нашей системы начинать забор данных.

А на нашей стороне надо проверить таблицу инкрементов, попробовать выбрать новый инкремент, создать новые карточки, обновить существующие... Если смотреть через админку, это три разные задачи:

1. Подготовка данных

2. Загрузка

3. Очистка буфера

Каждая задача выполняет внутри кода несколько действий. А мне надо подготовить набор автотестов на каждый этап. Значит, надо разобраться, что там происходит. Я сначала долго тупила над пользовательской докой, пытаясь понять, как оно устроено внутри, а потом пошла к разработчику и попросила объяснить для блондинок.

Это было продуктивное общение! Пока он объяснял, я рисовала на бумажке схему и задавала по ней вопросы. После нескольких вопросов раработчик признал, что я молодец, он про вот это и то не думал. Не зря рисовала! Без рисунка я бы просто не удержала всё в голове, и не обнаружила проблемные зоны.

По итогам обсуждения я создала в вики раздел Техническая сторона сценариев, алгоритмы и переписала туда все со своего листочка, полученный алгоритм и рисунок (в visio накидала):

1. null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1.

2. Удаляем неактуальные записи из буферных таблиц (физ лица и телефонов).

3. Грузим физиков по условию in (id_increment, для которого import_status in 1).

4. Грузим телефоны по условию in (import_status in 1).

5. Создаем связи телефон - физик или телефон - юрик (тип контрагента смотрим по таблице staging).

6. Удаляем физиков из буфера, если не было ошибок на этапе загрузки.

7. Удаляем те телефоны, у которых есть связи (проверяем наличие record_id физика/юрика в staging).

8. 1 => 2. Выбираем все записи из таблицы INCREMENTS, где import_status = 1 и устанавливаем им значение import_status = 2.

Согласитесь, при наличии такой картинки тесты на каждый раздел писать намного проще! Я четко вижу, что задача подготовки выполняет три действия. Значит, тестируем каждое!

null => 1. Выбираем все записи из таблицы INCREMENTS, где import_status is null и устанавливаем им значение import_status = 1.

Добавляем запись с пустым import_status проверяем, что статус изменился на 1.

А если исходно был статус 1?

А если исходно другой статус?

Так, дальше идет вызов oracle-процедуры. На схеме записано, как она называется ищем по названию в коде, изучаем, что она делает. И готовим тестовые данные, как позитивные, так и негативные.

Что у нас дальше? ...

И так по каждому пункту. Потом, когда к проекту подключались другие люди и тоже не могли понять, как тестировать задачу, я давала ссылку на эту страничку в конфлюенсе. И все сразу вставало на свои места!

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

.

Тесты в PowerPoint!

Метод рисунка работает не только с ТЗ, но и с тестами!

Тестировала оракловые вьюшки (view). Фактически это просто табличка с нужными мне колонками. Как любой отчет в интерфейсе. Cтроится отчет по определенному диапазону времени. Если сущность менялась в этом диапазоне она попадет во view. Если нет то увы.

На входе у меня есть текущее состояние базы когда объект был создан, а когда закрыт. И параметры диапазона:

• from_date начальная дата

• to_date конечная дата

Я набросала все интересные мне тесты в блокноте это быстрее всего. Допустим, объект создали 5 числа, а удалили 10. Какие интервалы между ними мне надо посмотреть?

Рисунки помогают мне быстро охватить картину покрытия тестами. Так, вот только создание попадает в диапазон есть. А оба события сразу есть. А между ними? Есть. А... И так далее. Накидаешь идей за пару минут мозгового штурма, и можно с ними работать. Переносить в код и описывать на вики.

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

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

Обычно я рисую в yEd. Но черточки и текст отдельно там сделать проблематично. Тут не подходит. Хм... Paint? Открыла его, нарисовала кривую "прямую" :) Тоже неудобно, хочется, чтобы симпатичненько смотрелось, а мышкой я прямые линии буду полчаса рисовать. Visio покупать надо... О, PowerPoint!

Открыла, попробовала. Поставила исходные засечки "создан 5, закрыт 10". Добавила прямоугольник на задний план идеально! Просто перетаскиваешь прямоугольник, то сужая, то расширяя его, и делаешь скриншоты. А как наглядно получается:

Добавим картинки в описание тестов на конфлюенсе (вики):

Красота!

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

Есть картинки и посложнее. Когда событий будет поболее, чем просто "создали один объект и его же закрыли". Тут мне было удобнее рисовать время по вертикальной оси:

Вот тут то меня PowerPoint и выручил! Если делать зарисовки от руки, то на каждый тест надо повторять основу, а потом обводить кружочком нужный диапазон. Получится долго. А без визуализации "что я уже сделала" мне тяжело. А в программе вжух-вжух поперемещал желтый прямоугольничек, заскринил каждую вариацию и готово! Даже круче блокнотика и ручки :)

Плюсы подхода

Визуализация!

1. Позволяет увидеть, что мы упустили

2. Помогает там, где много входных условий

Двойной профит визуализации: пока вы рисуете, то видите все слабые зоны ТЗ. А ещё делаете его более наглядным. Теперь каждый, кто будет читать ТЗ после вас, сразу всё поймет!

Минусы подхода

Картинку должен кто-то поддерживать, и это кто-то явно вы =)

Но всегда можно нарисовать ее одноразово!

Инструменты для рисования

1. Бумага и ручка!!

2. Маркер и доска

3. Xmind (freemind, etc)

4. Microsoft Visio

5. PowerPoint

6. YeD

7. ...

Если задача простая используйте бумагу и ручку. Будет быстрее.

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

Итого

Рисунок мощнейший инструмент визуализации. Если вам сложно что-то понять, зарисуйте это! Это может быть сложный участок ТЗ или чек-лист тестов. Пробуйте, экспериментируйте это время обязательно окупится. Причем сразу же, ведь, пока рисуешь, приходит вдохновение "проверить еще вот тут"!

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Для будущих студентов курса "QA Lead" и всех интересующихся областью тестирования подготовили перевод полезного материала.

Приглашаем также всех желающих на открытый вебинар по теме Организация процесса тестирования в agile и не agile-командах. На этом бесплатном демо-уроке мы рассмотрим вопросы:
1. Организация процесса работы в waterfall проекте;
2. Организация процесса тестирования в scrum команде;
3. Организация процесса тестирования в команде, работающей по kanban методу;
4. Организация процесса работы в масштабируемых agile-подходах.

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

1."Будущее тестирования программного обеспечения"- публикация Angie Jones

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

2. Эвристики для сбора грибов (и тестирования) - публикация Helena Jeret-Mae

Эта статья посвящена QA для всех тех, кто работает в этой области. А также, эта публикация является одной из немногих статей о тестировании программного обеспечения, которая не слишком сложная с технической точки зрения, а достаточно простая и понятная по своей сути, ее очень приятно читать. Статья автора написана просто, что делает чтение про QA не только чем-то, что нужно делать для работы, но и чем-то, что может вам лично понравиться.

3.Три желания с Волшебной Лампой Аладдина - публикация Luke Liu

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

4.Книга Позитива от David Williams

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

5.Получение отзывов онлайн-сообществ о продуктах - публикация Rosie Sherry

У Рози статьи лаконичны и обоснованы. Некоторые из них состоят из 50 слов, другие более объемные. Эта статья не столько о QA, сколько о том, как разговаривать с людьми и понимать продукт, выясняя, куда он должен попасть и что нужно для этого сделать. Не каждая статья должна быть технической, иногда полезно почитать об идеях про людей, чтобы вы понимали, кто ваш конечный пользователь.

6.Хрустальный шар будущего - Автоматизация через десять лет - публикация Richard Bradshaw

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

7.Состояние автоматизированного тестирования: 7 Ключевых тенденции для наблюдения - публикация Joe Colantonio

У Джо есть много подробных статей, которые хорошо читаются, если вы работаете в мире QA. Именно эта статья идеально подходит для того, чтобы заглянуть в будущее и узнать, что будет в ближайшие несколько лет, когда речь зайдет о тестировании. Эта легкая для чтения статья покажет вам тенденции, о которых вы должны знать, и расскажет как подготовиться к изменениям, которые ожидают вас в будущем.

8.Я не думаю, что это значит то, что ты думаешь, это значит. - публикация Keith Klain

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

9.Как попросить о помощи - публикация Alan Richardson

Помощь это то, о чем мы часто не знаем, как попросить или предложить. В этой статье рассказывается о том, как лучше всего это сделать и как получить ответ, который вам поможет, и будет двигать вас вперед. Немного затянуто, но в этой статье Алан объясняет, как QA может помочь людям, и рассказывает, как получить помощь, если вы в затруднительном положении и нуждаетесь в дополнительном участии. Эта статья предлагает отличное чтение о создании сообщества и помощи другим.

10.Поощряем живое мышление - публикация James Bach

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

11. Ошибочный вывод о бездефектности - публикация Jeff Nyman

Стиль письма Джеффа ясен и реалистичен. Эта конкретная программная статья рассматривает недостижимый идеал нулевых дефектов и объясняет почему это происходит. Джефф предлагает взглянуть на реальные проблемы и то, что даже если мы увидим ноль, мы не сможем доказать, что это ноль. По итогу, это хорошее чтение для команд, где язык нулевых дефектов существует, но должен быть изменен.

12.Не верьте этим 4 мифам о клиентах - публикация Kristel Kruustuk

Кристель написала эту статью для журнала "Entrepreneur" (Предприниматель). Публикация содержит отличные практические советы по проведению QA-тестирования. Ее внимание к людям как конечному пользователю важно и практично. Это то, о чем необходимо помнить каждому QA специалисту. Не может быть такого, чтобы все это было бы связано с автоматизацией.

13.Каково будущее тестирования программного обеспечения? - публикация Grace Barnott

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

14.Таблица как инструмент тестирования нуждается в вас- публикация Kate Falanga

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

Узнать подробнее о курсе "QA Lead".

Смотреть вебинар по теме Организация процесса тестирования в agile и не agile-командах.

Система контроля версий (от англ. Version Control System, VCS) это место хранения кода. Как dropbox, только для разработчиков!

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

А потом я подробнее расскажу, как VCS работает что значит "создать репозиторий", "закоммитить и смерджить изменения", и другие страшные слова. В конце мы пощупаем одну из систем VCS руками, скачаем код из открытого репозитория.

Итого содержание:

• Что это такое и зачем она нужна

• Как VCS работает

  • Подготовительная работа

    1. Создать репозиторий

    2. Скачать проект из репозитория

  • Ежедневная работа

    1. Обновить проект, забрать последнюю версию из репозитория

    2. Внести изменения в репозиторий

    3. Разрешить конфликты (merge)

    4. Создать бранч (ветку)

• Популярные VCS и отличия между ними

• Пример выкачиваем проект из Git

  1. Через консоль

  2. Через IDEA

  3. Через TortoiseGit

• Итого

Что это такое и зачем она нужна

Допустим, что мы делаем калькулятор на Java (язык программирования). У нас есть несколько разработчиков Вася, Петя и Иван. Через неделю нужно показывать результат заказчику, так что распределяем работу:

• Вася делает сложение;

• Петя вычитание;

• Иван начинает умножение, но оно сложное, поэтому переедет в следующий релиз.

Исходный код калькулятора хранится в обычной папке на сетевом диске, к которому все трое имеют доступ. Разработчик копирует этот код к себе на машину, вносит изменения и проверяет. Если всё хорошо кладет обратно. Так что код в общей папке всегда рабочий!

Итак, все забрали себе файлы из общей папки. Пока их немного:

• Main.java общая логика

• GUI.java графический интерфейс программы

С ними каждый и будет работать!

Вася закончил работу первым, проверил на своей машине все работает, отлично! Удовлетворенно вздохнув, он выкладывает свой код в общую папку. Вася сделал отдельный класс на сложение (Sum.java), добавил кнопку в графический интерфейс (внес изменения в GUI.java) и прописал работу кнопки в Main.java.

Петя химичил-химичил, ускорял работу, оптимизировал... Но вот и он удовлетворенно вздохнул готово! Перепроверил ещё раз работает! Он копирует файлы со своей машины в общую директорию. Он тоже сделал отдельный класс для новой функции (вычитание Minus.java), внес изменения в Main.java и добавил кнопку в GUI.java.

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

Все довольны, Вася с Петей обсуждают планы на следующий релиз. Но тут с показа продукта возвращается расстроенная Катя, менеджер продукта.

Катя, что случилось??

Вы же сказали, что всё сделали! А в графическом интерфейсе есть только вычитание. Сложения нет!

Вася удивился:

Как это нет? Я же добавлял!

Стали разбираться. Оказалось, что Петин файл затер изменения Васи в файлах, которые меняли оба: Main.java и GUI.java. Ведь ребята одновременно взяли исходные файлы к себе на компьютеры у обоих была версия БЕЗ новых функций.

Вася первым закончил работу и обновил все нужные файлы в общей папке. Да, на тот момент всё работало. Но ведь Петя работал в файле, в котором ещё не было Васиных правок.

Поэтому, когда он положил документы в хранилище, Васины правки были стерты. Остался только новый файл Sum.java, ведь его Петя не трогал.

Хорошо хоть логика распределена! Если бы всё лежало в одном классе, было бы намного сложнее совместить правки Васи и Пети. А так достаточно было немного подправить файлы Main.java и GUI.java, вернув туда обработку кнопки. Ребята быстро справились с этим, а потом убедились, что в общем папке теперь лежит правильная версия кода.

Собрали митинг (жаргон собрание, чтобы обсудить что-то):

Как нам не допустить таких косяков в дальнейшем?

Давайте перед тем, как сохранять файлы в хранилище, забирать оттуда последние версии! А ещё можно брать свежую версию с утра. Например, в 9 часов. А перед сохранением проверять дату изменения. Если она позже 9 утра, значит, нужно забрать измененный файл.

Да, давайте попробуем!

Вася с Петей были довольны, ведь решение проблемы найдено! И только Иван грустит. Ведь он целую неделю работал с кодом, а теперь ему надо было синхронизировать версии... То есть объединять свои правки с изменениями коллег.

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

Когда он пришел с утра, в офисе был переполох. Вася бегал по офису и причитал:

Мои изменения пропали!!! А я их не сохранил!

Увидев Ваню, он подскочил к нему и затряс за грудки:

Зачем ты стер мой код??

Стали разбираться. Оказалось что Вася вчера закончил свой кусок работы, проверил, что обновлений файлов не было, и просто переместил файлы со своего компьютера в общую папку. Не скопировал, а переместил. Копий никаких не осталось.

После этого изменения вносил Иван. Да, он внимательно вычитывал файлы с кодом и старался учесть и свои правки, и чужие. Но изменений слишком много, часть Васиных правок он потерял.

Код теперь не работает! Ты вообще проверял приложение, закончив синхронизацию?

Нет, я только свою часть посмотрел...

Вася покачал головой:

Но ведь при сохранении на общий диск можно допустить ошибку! По самым разным причинам:

• Разработчик начинающий, чаще допускает ошибки.

• Случайно что-то пропустил если нужно объединить много файлов, что-то обязательно пропустишь.

• Посчитал, что этот код не нужен что он устарел или что твоя новая логика делает то же самое, а на самом деле не совсем.

И тогда приложение вообще перестанет работать. Как у нас сейчас.

Ваня задумался:

Хм... Да, пожалуй, ты прав. Нужно тестировать итоговый вариант!

Петя добавил:

И сохранять версии. Может, перенесем наш код в Dropbox, чтобы не терять изменения?

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

Через пару дней ребята снова собрали митинг:

Ну как вам в дропбоксе?

Уже лучше. По крайней мере, не потеряем правки!

Петя расстроенно пожимает плечами:

Да, только мы с Васей одновременно вносили изменения в Main.java, создалась конфликтующая версия. И пришлось вручную их объединять... А класс то уже подрос! И глазками сравнивать 100 строк очень невесело... Всегда есть шанс допустить ошибку.

Ну, можно же подойти к тому, кто создал конфликт и уточнить у него, что он менял.

Хорошая идея, давайте попробуем!

Попробовали. Через несколько дней снова митинг:

Как дела?

Да всё зашибись, работаем!

А почему код из дропбокса не работает?

Как не работает??? Мы вчера с Васей синхронизировались!

А ты попробуй его запустить.

Посмотрели все вместе и правда не работает. Какая-то ошибка в Main.java. Стали разбираться:

Так, тут не хватает обработки исключения.

Ой, подождите, я же её добавлял!

Но ты мне не говорил о ней, когда мы объединяли правки.

Да? Наверное, забыл...

Может, еще что забыл? Ну уж давай лучше проверим глазами...

Посидели, выверили конфликтные версии. Потратили час времени всей команды из-за пустяка. Обидно!

Слушайте, может, это можно как-то попроще делать, а? Чтобы человека не спрашивать что ты менял?

Можно использовать программу сравнения файлов. Я вроде слышал о таких. AraxisMerge, например!

Ой, точно! В IDEA же можно сравнивать твой код с клипбордом (сохраненным в Ctrl + C значении). Давайте использовать его!

Точно!

Начали сравнивать файлы через программу жизнь пошла веселее. Но через пару дней Иван снова собрал митинг:

Ребята, тут такая тема! Оказывается, есть специальные программы для хранения кода! Они хранят все версии и показывают разницу между ними. Только делает это сама программа, а не человек!

Да? И что за программы?

Системы контроля версий называются. Вот SVN, например. Давайте попробуем его?

А давайте!

Попробовали. Работает! Еще и часть правок сама синхронизирует, даже если Вася с Петей снова не поделили один файл. Как она это делает? Давайте разбираться!

Как VCS работает

Подготовительная работа

Это те действия, которые нужно сделать один раз.

1. Создать репозиторий

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

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

А потом Вася берет код из дропбокса, и кладет его в VCS специальной командой. В разных системах контроля версии разные названия у команды, но суть одна создать репозиторий, в котором будет храниться код.

Всё! Теперь у нас есть общее хранилище данных! С ним дальше и будем работать.

2. Скачать проект из репозитория

Теперь команде нужно получить проект из репозитория. Можно, конечно, и из дропбокса скачать, пока там актуальная версия, но давайте уже жить по-правильному!

Поэтому Петя, Вася и Иван удаляют то, что было у них было на локальных компьютерах. И забирают данные из репозитория, клонируя его. В Mercurial (один из вариантов VCS) эта команда так и называется clone. В других системах она зовется иначе, но смысл всё тот же клонировать (копировать) то, что лежит в репозитории, к себе на компьютер!

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

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

Ежедневная работа

А это те действия, которые вы будете использовать часто.

1. Обновить проект, забрать последнюю версию из репозитория

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

Так, Вася обновил проект утром и увидел, что Ваня изменил файлы Main.java и GUI.java. Отлично, теперь у Васи актуальная версия на машине. Можно приступать к работе!

В SVN команда обновления называется update, в Mercurial pull. Она сверяет код на твоем компьютере с кодом в репозитории. Если в репозитории появились новые файлы, она их скачает. Если какие-то файлы были удалены удалит и с твоей машины тоже. А если что-то менялось, обновит код на локальном компьютере.

Тут может возникнуть вопрос в чем отличие от clone? Можно же просто клонировать проект каждый раз, да и всё! Зачем отдельная команда?

Клонирование репозитория производится с нуля. А когда разработчики работают с кодом, у них обычно есть какие-то локальные изменения. Когда начал работу, но ещё не закончил. Но при этом хочешь обновить проект, чтобы конфликтов было меньше.

Если бы использовалось клонирование, то пришлось бы переносить все свои изменения в новый репозиторий вручную. А это совсем не то, что нам нужно. Обновление не затронет новые файлы, которые есть только у вас на компьютере.

А еще обновление это быстрее. Обновиться могли 5 файликов из 1000, зачем выкачивать всё?

2. Внести изменения в репозиторий

Вася работает над улучшением сложения. Он придумал, как ускорить его работу. А заодно, раз уж взялся за рефакторинг (жаргон улучшение системы, от англ. refactor), обновил и основной класс Main.java.

Перед началом работы он обновил проект на локальном (своём) компьютере, забрав из репозитория актуальные версии. А теперь готов сохранить в репозиторий свои изменения. Это делается одной или двумя командами зависит от той VCS, которую вы используете в работе.

1 команда commit

Пример системы SVN.

Сделав изменения, Вася коммитит их. Вводит команду commit и все изменения улетают на сервер. Всё просто и удобно.

2 команды commit + push

Примеры системы Mercurial, Git.

Сделав изменения, Вася коммитит их. Вводит команду commit изменения сохранены как коммит. Но на сервер они НЕ уходят!

Чтобы изменения пошли на сервер, их надо запушить. То есть ввести команду push.

Это удобно, потому что можно сделать несколько разных коммитов, но не отправлять их в репозиторий. Например, потому что уже code freeze и тестировщики занимаются регрессией. Или если задача большая и может много всего сломать. Поэтому её надо сначала довести до ума, а потом уже пушить в общий репозиторий, иначе у всей команды развалится сборка!

При этом держать изменения локально тоже не слишком удобно. Поэтому можно спокойно делать коммиты, а потом уже пушить, когда готов. Или когда интернет появился =) Для коммитов он не нужен.

Итого

Когда разработчик сохраняет код в общем хранилище, он говорит:

Закоммитил.

Или:

Запушил.

Смотря в какой системе он работает. После этих слов вы уверены код изменен, можно обновить его на своей машине и тестировать!

3. Разрешить конфликты (merge)

Вася добавил вычисление процентов, а Петя деление. Перед работой они обновили свои локальные сборки, получив с сервера версию 3 файлов Main.java и Gui.java.

Для простоты восприятия нарисуем в репозитории только эти файлы и Minus.java, чтобы показать тот код, который ребята трогать не будут.

Вася закончил первым. Проверив свой код, он отправил изменения на сервер. Он:

• Добавил новый файл Percent.java

• Обновил Main.java (версию 3)

• Обновил Gui.java (версию 3)

При отправке на сервер были созданы версии:

• Percent.java версия 1

• Main.java версия 4

• Gui.java версия 4

Петя закончил чуть позже. Он:

• Добавил новый файл Division.java

• Обновил Main.java (версию 3, ведь они с Васей скачивали файлы одновременно)

• Обновил Gui.java (версию 3)

Готово, можно коммитить! При отправке на сервер были созданы версии:

• Division.java версия 1

• Main.java версия 4

• Gui.java версия 4

Но стойте, Петя обновляет файлы, которые были изменены с момента обновления кода на локальной машине! Конфликт!

Часть конфликтов система может решить сама, ей достаточно лишь сказать merge. И в данном случае этого будет достаточно, ведь ребята писали совершенно разный код, а в Main.java и Gui.java добавляли новые строчки, не трогая старые. Они никак не пересекаются по своим правкам. Поэтому система сливает изменения добавляет в версию 4 Петины строчки.

Но что делать, если они изменяли один и тот же код? Такой конфликт может решить только человек. Система контроля версий подсвечивает Пете Васины правки и он должен принять решение, что делать дальше. Система предлагает несколько вариантов:

• Оставить Васин код, затерев Петины правки если Петя посмотрит Васны изменения и поймет, что те лучше

• Затереть Васины правки, взяв версию Петра если он посчитает, что сам все учел

• Самому разобраться в таком случае в файл кода добавляются обе версии и надо вручную слепить из них итоговый кусок кода

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

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

Особая боль глобальный рефакторинг, когда затрагивается МНОГО файлов. Обновление версии библиотеки, переезд с ant на gradle, или просто выкашивание легаси кода. Нельзя коммитить его по кусочкам, иначе у всей команды развалится сборка.

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

А что делать? Обновляет проект и решает конфликты. Иногда в работе над большой задачей разработчик каждый день обновляется и мерджит изменения, а иногда только через несколько дней.

Тестировщик будет сильно реже попадать в конфликтные ситуации, просто потому, что пишет меньше кода. Иногда вообще не пишет, иногда пополняет автотесты. Но с разработкой при этом почти не пересекается. Однако выучить merge все равно придется, пригодится!

4. Создать бранч (ветку)

На следующей неделе нужно показывать проект заказчику. Сейчас он отлично работает, но разработчики уже работают над новыми изменениями. Как быть? Ребята собираются на митинг:

Что делать будем? Не коммитить до показа?

У меня уже готовы новые изменения. Давайте закоммичу, я точно ничего не сломал.

Катя хватается за голову:

Ой, давайте без этого, а? Мне потом опять краснеть перед заказчиками!

Тут вмешивается Иван:

А давайте бранчеваться!

Все оглянулись на него:

Что делать?

Иван стал рисовать на доске:

Бранч это отдельная ветка в коде. Вот смотрите, мы сейчас работаем в trunk-е, основной ветке.

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

Потом Вася закоммитил изменения по улучшению классов появилась версия 1 кода.

Потом он добавил проценты появилась версия кода 2.

При этом в самой VCS сохранены все версии, и мы всегда можем:

• Посмотреть изменения в версии 1

• Сравнить файлы из версии 1 и версии 2 система наглядно покажет, где они совпадают, а где отличаются

• Откатиться на прошлую версию, если версия 2 была ошибкой.

Потом Петя добавил деление появилась версия 3.

И так далее сколько сделаем коммитов, столько версий кода в репозитории и будет лежать. А если мы хотим сделать бранч, то система копирует актуальный код и кладет отдельно. На нашем стволе появляется новая ветка (branch по англ. ветка). А основной ствол обычно зовут trunk-ом.

Теперь, если я захочу закоммитить изменения, они по-прежнему пойдут в основную ветку. Бранч при этом трогать НЕ будут (изменения идут в ту ветку, в которой я сейчас нахожусь. В этом примере мы создали branch, но работать продолжаем с trunk, основной веткой)

Так что мы можем смело коммитить новый код в trunk. А для показа использовать branch, который будет оставаться стабильным даже тогда, когда в основной ветке всё падает из-за кучи ошибок.

С бранчами мы всегда будем иметь работающий код!

Подожди, подожди! А зачем эти сложности? Мы ведь всегда может просто откатиться на нужную версию! Например, на версию 2. И никаких бранчей делать не надо!

Это верно. Но тогда тебе нужно будет всегда помнить, в какой точке у тебя всё работает и тут есть все нужные функции. А если делать говорящие названия бранчей, обратиться к ним намного проще. К тому же иногда надо вносить изменения именно в тот код, который на продакшене (то есть у заказчика).

Вот смотри, допустим, мы выпустили сборку 3, идеально работающую. Спустя неделю Заказчик ее установил, а спустя месяц нашел баг. У нас за эти недели уже 30 новых коммитов есть и куча изменений.

Заказчику нужно исправление ошибки, но он не готов ставить новую версию ведь ее надо тестировать, а цикл тестирования занимает неделю. А баг то нужно исправить здесь и сейчас! Получается, нам надо:

• Обновиться на версию 3

• Исправить баг локально (на своей машине, а не в репозитории)

• Никуда это не коммитить = потерять эти исправления

• Собрать сборку локально и отдать заказчику

• Не забыть скопипастить эти исправления в актуальную версию кода 33 и закоммитить (сохранить)

Что-то не очень весело. А если нужно будет снова дорабатывать код? Искать разработчика, у которого на компьютере сохранены изменения? Или скопировать их и выложить на дропбокс? А зачем тогда использовать систему контроля версий?

Именно для этого мы и бранчуемся! Чтобы всегда иметь возможность не просто вернуться к какому-то коду, но и вносить в него изменения. Вот смотрите, когда Заказчик нашел баг, мы исправили его в бранче, а потом смерджили в транк.

Смерджили так называют слияние веток. Это когда мы внесли изменения в branch и хотим продублировать их в основной ветке кода (trunk). Мы ведь объединяем разные версии кода, там наверняка есть конфликты, а разрешение конфликтов это merge, отсюда и название!

Если Заказчик захочет добавить новую кнопочку или как-то еще изменить свою версию кода без проблем. Снова вносим изменения в нужный бранч + в основную ветку.

Веток может быть много. И обычно чем старше продукт, тем больше веток релиз 1, релиз 2... релиз 52...

Есть программы, которые позволяют взглянуть на дерево изменений, отрисовывая все ветки, номера коммитов и их описание. Именно в таком стиле, как показано выше =) В реальности дерево будет выглядеть примерно вот так (картинка из интернета):

А иногда и ещё сложнее!

А как посмотреть, в какой ветке ты находишься?

О, для этого есть специальная команда. Например, в Mercurial это hg sum: она показывает информацию о том, где ты находишься. Вот пример ее вызова:

D:\vcs_project\test>hg sumparent: 3:66a91205d385 tipTry to fix bug with devicebranch: default

В данном примере parent это номер коммита. Мы ведь можем вернуться на любой коммит в коде. Вдруг мы сейчас не на последнем, не на актуальном? Можно проверить. Тут мы находимся на версии 3. После двоеточия идет уникальный номер ревизии, ID кода.

Потом мы видим сообщение, с которым был сделан коммит. В данном случае разработчик написал Try to fix bug with device.

И, наконец, параметр branch! Если там значение default мы находимся в основной ветке. То есть мы сейчас в trunk-е. Если бы были не в нём, тут было бы название бранча. При создании бранча разработчик даёт ему имя. Оно и отображается в этом пункте.

Круто! Давайте тогда делать ветку!

*****

Git создал интерактивную игрушку, чтобы посмотреть на то, как происходит ветвление https://learngitbranching.js.org

*****

Отдельно хочу заметить, что бранчевание на релиз не единственный вариант работы с VCS. Есть и другой подход к разработке когда транк поддерживают в актуальном и готовом к поставкам состоянии, а все задачи делают в отдельных ветках. Но его мы в этой статье рассматривать не будем.

Итого

Система контроля версий (от англ. Version Control System, VCS) это dropbox для кода.

Популярные VCS и отличия между ними

Наиболее популярные это:

• SVN простая, но там очень сложно мерджиться

• Mercurial (он же HG), Git намного больше возможностей (эти системы похожи по функционалу)

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

Mercurial и Git распределенная система контроля версий. Внесение изменений двухступенчатое сначала коммит, потом push. Это удобно, если вы работаете без интернета, или делаете мелкие коммиты, но не хотите ломать основной код пока не доделаете большую задачу. Тут есть и автоматическое слияние разных бранчей. Больше возможностей дают системы.

У любой системы контроля версий есть консольный интерфейс. То есть общаться с ними можно напрямую через консоль, вводя туда команды. Склонировать репозиторий, обновить его, добавить новый файл, удалить старый, смерджить изменения, создать бранч... Всё это делается с помощью команд.

Но есть и графический интерфейс. Устанавливаете отдельную программу и выполняете действия мышкой. Обычно это делается через черепашку программа называется Tortoise<VCS>. TortoiseSVN, TortoiseHG, TortoiseGit... Часть команд можно сделать через среду разработки IDEA, Eclipse, etc.

Но любой графический интерфейс как работает? Вы потыкали мышкой, а система Tortoise составила консольную команду из вашего тык-тык, её и применила.

См также:

Что такое API подробнее о том, что скрывается за интерфейсом.

Вот некоторые базовые команды и форма их записи в разных VCS:

Тут хочу напомнить, что я тестировщик, а не разработчик. Поэтому про тонкости различия коммитов писать не буду, да и статья для новичков, оно им и не надо =)

Пример выкачиваем проект из Git

Выкачивать мы будем систему с открытым исходным кодом Folks. Так что вы можете повторить этот пример сами!

Для начала установите Git. Когда он установлен, можно выкачивать репозиторий на свой компьютер. Я покажу 3 способа (есть и другие, но я покажу именно эти):

1. Через консоль

2. Через IDEA

3. Через TortoiseGit

Исходный код мы будем в директорию D:\git.

1. Через консоль

1. Запустить консоль git:

2. Написать команду:

git clone Откуда Куда

git clone https://bitbucket.org/testbasecode/folks/src/master/ D:\\git\\folks_console

В консоли нужно писать простой слеш или экранировать обратный. Иначе консоль его проигнорирует!

Также НЕ НАДО использовать в названии папки куда клонируем русские символы или пробелы. Иначе потом огребете проблем на сборке проекта.

2. Через IDEA

1. Запустить IDEA

2. Check out from Version Control Git

3. Заполнить поля:

• URL https://bitbucket.org/testbasecode/folks/src/master/ (откуда выкачиваем исходный код)

• Назначение D:\git\folks_idea (куда сохраняем на нашем компьютере)

4. Нажать Clone всё! Дальше IDEA всё сделает сама!

А под конец предложит открыть проект, подтверждаем!

Если открывается пустой серый экран, найдите закладку Project (у меня она слева сверху) и щелкните по ней, чтобы раскрыть проект:

И вуаля и код скачали, и сразу в удобном и бесплатном редакторе открыли! То, что надо. Для новичка так вообще милое дело.

3. Через TortoiseGit

Еще один простой и наглядный способ для новичка через графический интерфейс, то есть черепашку (tortoise):

1. Скачать TortoiseGit

2. Установить его Теперь, если вы будете щелкать правой кнопкой мыши в папочках, у вас появятся новые пункты меню: Git Clone, Git Create repository here, TortoiseGit

3. Перейти в папку, где у нас будет храниться проект. Допустим, это будет D:\git.

4. Нажать правой кнопкой мыши Git Clone

Заполнить поля:

• URL https://bitbucket.org/testbasecode/folks/src/master/ (откуда выкачиваем исходный код)

• Directory D:\git\folks_tortoise_git (куда сохраняем на нашем компьютере)

5. Нажать Ок

Вот и всё! Система что-то там повыкачивает и покажет результат папочку с кодом!

Итого мы получили 3 папки с одинаковым кодом! Неважно, какой способ выберете вы, результат не изменится:

Итого

Пусть вас не пугают страшные слова типа SVN, Mercurail, Git, VCS это всё примерно одно и то же. Место для хранения кода, со всеми его версиями. Дропбокс разработчика! И даже круче =) Ведь в дропбоксе любое параллельное изменение порождает конфликтную версию.

Я храню свою книгу в дропбоксе. Там же лежит файл для художницы TODO Вике. Когда я придумываю новую картинку, тодобавляю ее в конец файла. Когда Вика заканчивает рисовать, она отмечает в ТЗ, какая картинка готова.

Мы правим разные места. Вика идет сначала, я добавляю в конец. Казалось бы, можно сохранить и ее, и мои изменения. Но нет, если файл открыт у обеих, то при втором сохранении создается конфликтная копия. И надо вручную синхронизировать изменения.

Гуглодок в этом плане получше будет, его можно редактировать параллельно. И если менять разные места, конфликтов совсем не будет!

Но сравнивать с гуглодокой тоже будет неправильно. Потому что гуглодоку можно редактировать параллельно, а в VCS каждый работает со своей версией файла, которую скачал с хранилища. И только когда разработчик решил, что пора он сохраняет изменения обратно в хранилище.

Когда вы приходите на новую работу, вам нужно выкачать код из хранилища. Это означает просто забрать из общего хранилища актуальную версию. Как если бы вы зашли в дропбокс и скопипастили себе последнюю версию файлов. Просто в VCS это делается при помощи командной строки или специального графического интерфейса типа Tortoise Hg.

Это нестрашно =) Посмотрите выше пример буквально 1 команда позволяет нам получить этот самый код.

А потом уже, если разрешат, вы сможете даже вносить свои изменения в основной код или код автотестов. Но если уж вы с этим справитесь, то с коммитом и подавно!

PS: больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале.

PPS: автор картинок этой статьи Аня Черноморцева, автор стиля Виктория Лапис =)

Если вы тестируете API, то должны знать про два основных формата передачи данных:

• XML используется в SOAP(всегда)и REST-запросах(реже);

• JSON используется в REST-запросах.

Сегодня я расскажу вам про JSON.

JSON (англ. JavaScript Object Notation) текстовый формат обмена данными, основанный на JavaScript. Но при этом формат независим от JS и может использоваться в любом языке программирования.

JSON используется в REST API. По крайней мере, тестировщик скорее всего столкнется с ним именно там.

См также:

Что такое API общее знакомство с API

Что такое XML второй популярный формат

Введение в SOAP и REST: что это и с чем едят видео про разницу между SOAP и REST

В SOAP API возможен только формат XML, а вот REST API поддерживает как XML, так и JSON. Разработчики предпочитают JSON он легче читается человеком и меньше весит. Так что давайте разберемся, как он выглядит, как его читать, и как ломать!

Содержание

• Как устроен JSON

  • JSON-объект

    • Как устроен

    • Ключ или свойство?

    • Итого

  • JSON-массив

    • Как устроен

    • Значения внутри

    • Итого

• JSON vs XML

• Well Formed JSON

  1. Данные написаны в виде пар ключ:значение

  2. Данные разделены запятыми

  3. Объект находится внутри фигурных скобок {}

  4. Массив внутри квадратных []

• Итого

Как устроен JSON

В качестве значений в JSON могут быть использованы:

• JSON-объект

• Массив

• Число (целое или вещественное)

• Литералы true (логическое значение истина), false (логическое значение ложь) и null

• Строка

Я думаю, с простыми значениями вопросов не возникнет, поэтому разберем массивы и объекты. Ведь если говорить про REST API, то обычно вы будете отправлять / получать именно json-объекты.

JSON-объект

Как устроен

Возьмем пример из документации подсказок Дадаты по ФИО:

{  "query": "Виктор Иван",  "count": 7}

И разберемся, что означает эта запись.

Объект заключен в фигурные скобки {}

JSON-объект это неупорядоченное множество пар ключ:значение.

Ключ это название параметра, который мы передаем серверу. Он служит маркером для принимающей запрос системы: смотри, здесь у меня значение такого-то параметра!. А иначе как система поймет, где что? Ей нужна подсказка!

Вот, например, Виктор Иван это что? Ищем описание параметра query в документации ага, да это же запрос для подсказок!

Это как если бы мы вбили строку Виктор Иван в GUI (графическом интерфейсе пользователя):

Когда пользователь начинает вводить данные в формочку, то сразу видит результат появляется список подсказок. Это значит, что разработчик прописал в коде условие делать некое действие на каждый ввод символа в это поле. Какое действие? Можно увидеть через f12.

Открываем вкладку Network, вбиваем Виктор Иван и находим запрос, который при этом уходит на сервер. Ого, да это тот самый пример, что мы разбираем!

Клиент передает серверу запрос в JSON-формате. Внутри два параметра, две пары ключ-значение:

• query строка, по которой ищем (то, что пользователь вбил в GUI);

• count количество подсказок в ответе (в Дадате этот параметр зашит в форму, всегда возвращается 7 подсказок. Но если дергать подсказки напрямую, значение можно менять!)

Пары ключ-значение разделены запятыми:

Строки берем в кавычки, числа нет:

Конечно, внутри может быть не только строка или число. Это может быть и другой объект! Или массив... Или объект в массиве, массив в объекте... Любое количество уровней вложенности =))

Объект, массив, число, булево значение (true / false) если у нас НЕ строка, кавычки не нужны. Но в любом случае это будет значение какого-то ключа:

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

Ключ ВСЕГДА строка, поэтому можно не брать его в кавычки.

По крайней мере, если вы работаете с простыми значениями ключей, а несколько слов записываете в верблюжьемРегистре или в змеином_регистре. Если вы хотите написать в ключе несколько слов через пробел, ключ нужно взять в кавычки.

И все же я рекомендую использовать простые названия ключей, или использовать snake_case.

См также:

CamelCase, snake_case и другие регистры подробнее о разных регистрах

Писать ключи можно в любом порядке. Ведь JSON-объект это неупорядоченное множество пар ключ:значение.

Очень важно это понимать, и тестировать! Принимающая запрос система должна ориентировать на название ключей в запросе, а не на порядок их следования. Ключевое слово должна )) Хотя знаю примеры, когда от перестановки ключей местами всё ломалось, ведь первым должен идти запрос, а не count!.

Ключ или свойство?

Вот у нас есть JSON-объект:

{  "query": "Виктор Иван",  "count": 7}

Что такое query? Если я хочу к нему обратиться, как мне это сказать? Есть 2 варианта, и оба правильные:

Обратиться к свойству объекта;

Получить значение по ключу.

То есть query можно назвать как ключом, так и свойством. А как правильно то?

Правильно и так, и так! Просто есть разные определения объекта:

Объект

В JS объект это именно объект. У которого есть набор свойств и методов:

• Свойства описывают, ЧТО мы создаем.

• Методы что объект умеет ДЕЛАТЬ.

То есть если мы хотим создать машину, есть два пути:

1. Перечислить 10 разных переменных модель, номер, цвет, пробег...

2. Создать один объект, где будут все эти свойства.

Аналогично с кошечкой, собачкой, другом из записной книжки...

Объектно-ориентированное программирование (ООП) предлагает мыслить не набором переменных, а объектом. Хотя бы потому, что это логичнее. Переменных в коде будет много, как понять, какие из них взаимосвязаны?

Вот если я создаю машину, сколько переменных мне надо заполнить? А если меняю данные? А если удаляю? Когда переменные разбросаны по коду, можно забыть про какую-то и получить ошибку в интерфейсе. А если у нас есть цельный объект, всегда можно посмотреть, какие у него есть свойства и методы.

Например, создадим кошечку:

var cat = {name: Pussy,year: 1,sleep: function() {// sleeping code}}

В объекте cat есть:

• Свойства name, year (что это за кошечка)

• Функции sleep (что она умеет делать, описание поведения)

По коду сразу видно, что у кошечки есть имя и возраст, она умеет спать. Если разработчик решит добавить новые свойства или методы, он дополнит этот объект, и снова всё в одном месте.

Если потом нужно будет получить информацию по кошечке, разработчик сделает REST-метод getByID, searchKitty, или какой-то другой. А в нем будет возвращать свойства объекта.

То есть метод вернет

{name: Pussy,year: 1,}

И при использовании имени вполне уместно говорить обратиться к свойству объекта. Это ведь объект (кошечка), и его свойства!

Набор пар ключ:значение

Второе определение объекта неупорядоченное множество пар ключ:значение, заключенное в фигурные скобки {}.

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

• client_fio (в коде это свойство fio объекта client)

• kitty_name (в коде это свойство name объекта cat)

• car_model (в коде это свойство model объекта car)

В таком случае логично называть эти параметры именно ключами мы хотим получить значение по ключу.

Но в любом случае, и ключ, и свойство будет правильно. Не пугайтесь, если в одной книге / статье / видео увидели одно, в другой другое... Это просто разные трактовки \_()_/

Итого

Json-объект это неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки { }. Ключ описывается строкой, между ним и значением стоит символ :. Пары ключ-значение отделяются друг от друга запятыми.

Значения ключа могут быть любыми:

• число

• строка

• массив

• другой объект

• ...

И только строку мы берем в кавычки!

JSON-массив

Как устроен

Давайте снова начнем с примера. Это массив:

["MALE","FEMALE"]

Массив заключен в квадратные скобки []

Внутри квадратных скобок идет набор значений. Тут нет ключей, как в объекте, поэтому обращаться к массиву можно только по номеру элемента. И поэтому в случае массива менять местами данные внутри нельзя. Это упорядоченное множество значений.

Значения разделены запятыми:

Значения внутри

Внутри массива может быть все, что угодно:

Цифры

[1, 5, 10, 33]

Строки

["MALE","FEMALE"]

Смесь

[1, "Андрюшка", 10, 33]

Объекты

Да, а почему бы и нет:

[1, {a:1, b:2}, "такой вот массивчик"]

Или даже что-то более сложное. Вот пример ответа подсказок из Дадаты:

[        {            "value": "Иванов Виктор",            "unrestricted_value": "Иванов Виктор",            "data": {                "surname": "Иванов",                "name": "Виктор",                "patronymic": null,                "gender": "MALE"            }        },        {            "value": "Иванченко Виктор",            "unrestricted_value": "Иванченко Виктор",            "data": {                "surname": "Иванченко",                "name": "Виктор",                "patronymic": null,                "gender": "MALE"            }        },        {            "value": "Виктор Иванович",            "unrestricted_value": "Виктор Иванович",            "data": {                "surname": null,                "name": "Виктор",                "patronymic": "Иванович",                "gender": "MALE"            }        }]

Система возвращает массив подсказок. Сколько запросили в параметре count, столько и получили. Каждая подсказка объект, внутри которого еще один объект. И это далеко не сама сложная структура! Уровней вложенности может быть сколько угодно массив в массиве, который внутри объекта, который внутри массива, который внутри объекта...

Ну и, конечно, можно и наоборот, передать массив в объекте. Вот пример запроса в подсказки:

{"query": "Виктор Иван","count": 7,"parts": ["NAME", "SURNAME"]}

Это объект (так как в фигурных скобках и внутри набор пар ключ:значение). А значение ключа "parts" это массив элементов!

Итого

Массив это просто набор значений, разделенных запятыми. Находится внутри квадратных скобок [].

А вот внутри него может быть все, что угодно:

• числа

• строки

• другие массивы

• объекты

• смесь из всего вышеназванного

JSON vs XML

В SOAP можно применять только XML, там без вариантов.

В REST можно применять как XML, так и JSON. Разработчики отдают предпочтение json-формату, потому что он проще воспринимается и меньше весит. В XML есть лишняя обвязка, название полей повторяется дважды (открывающий и закрывающий тег).

Сравните один и тот же запрос на обновление данных в карточке пользователя:

XML

<req><surname>Иванов</surname><name>Иван</name><patronymic>Иванович</patronymic><birthdate>01.01.1990</birthdate><birthplace>Москва</birthplace><phone>8 926 766 48 48</phone></req>

JSON

{"surname": "Иванов","name": "Иван","patronymic": "Иванович","birthdate": "01.01.1990","birthplace": "Москва","phone": "8 926 766 48 48"}

За счет того, что мы не дублируем название поля каждый раз surname surname, читать JSON проще. И за счет этого же запрос меньше весит, что при плохом интернете бывает важно. Или при большой нагрузке.

См также:

Инфографика REST vs SOAP

Well Formed JSON

Разработчик сам решает, какой JSON будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. Наш JSON должен быть well formed, то есть синтаксически корректный.

Чтобы проверить JSON на синтаксис, можно использовать любой JSON Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

Но учтите, что парсеры внутри кода работают не по википедии или w3schools, а по RFC, стандарту. Так что если хотите изучить каким должен быть JSON, то правильнее открывать RFC и искать там JSON Grammar. Однако простому тестировщику хватит набора типовых правил с w3schools, их и разберем.

Правила well formed JSON:

1. Данные написаны в виде пар ключ:значение

2. Данные разделены запятыми

3. Объект находится внутри фигурных скобок {}

4. Массив внутри квадратных []

1. Данные написаны в виде пар ключ:значение

Например, так:

"name":"Ольга"

В JSON название ключа нужно брать в кавычки, в JavaScript не обязательно он и так знает, что это строка. Если мы тестируем API, то там будет именно JSON, так что кавычки обычно нужны.

Но учтите, что это правило касается JSON-объекта. Потому что json может быть и числом, и строкой. То есть:

123

Или

"Ольга"

Это тоже корректный json, хоть и не в виде пар ключ:значение.

И вот если у вас по ТЗ именно json-объект на входе, попробуйте его сломать, не передав ключ. Ещё можно не передать значение, но это не совсем негативный тест система может воспринимать это нормально, как пустой ввод.

2. Данные разделены запятыми

Пары ключ:значение в объекте разделяются запятыми. После последней пары запятая не нужна!

Типичная ошибка: поставили запятую в конце объекта:

{  "query": "Виктор Иван",  "count": 7,}

Это последствия копипасты. Взяли пример из документации, подставили в постман (ну или разработчик API подставил в код, который будет вызывать систему), а потом решили поменять поля местами.

В итоге было так:

{  "count": 7,  "query": "Виктор Иван"}

Смотрим на запрос ну, query то важнее чем count, надо поменять их местами! Копипастим всю строку "count": 7,, вставляем ниже. Перед ней запятую добавляем, а лишнюю убрать забываем. По крайней мере у меня это частая ошибка, когда я кручу-верчу, местами поменять хочу.

Другой пример когда мы добавляем в запрос новое поле. Примерный сценарий:

1. У меня уже есть работающий запрос в Postman-е. Но в нем минимум полей.

2. Я его клонирую

3. Копирую из документации нужное мне поле. Оно в примере не последнее, так что идёт с запятой на конце.

4. Вставляю себе в конце запроса в текущий конец добавляю запятую, потом вставляю новую строку.

5. Отправляю запрос ой, ошибка! Из копипасты то запятую не убрала!

Я на этот сценарий постоянно напарываюсь при тестировании перестановки полей. А ведь это нужно проверять! Хороший запрос должен быть как в математической присказке: от перемены мест слагаемых сумма не меняется.

Не зря же определение json-объекта гласит, что это неупорядоченное множество пар ключ:значение. Раз неупорядоченное я могу передавать ключи в любом порядке. И сервер должен искать по запросу название ключа, а не обращаться к индексу элемента.

Разработчик, который будет взаимодействовать с API, тоже человек, который может ошибиться. И если система будет выдавать невразумительное сообщение об ошибке, можно долго думать, где конкретно ты налажал. Поэтому ошибки тоже тестируем.

Чтобы протестировать, как система обрабатывает плохой json, замените запятую на точку с запятой:

{  "count": 7;  "query": "Виктор Иван"}

Или добавьте лишнюю запятую в конце запроса эта ошибка будет встречаться чаще!

{  "count": 7,  "query": "Виктор Иван",}

Или пропустите запятую там, где она нужна:

{"count": 7"query": "Виктор Иван"}

Аналогично с массивом. Данные внутри разделяются через запятую. Хотите попробовать сломать? Замените запятую на точку с запятой! Тогда система будет считать, что у вас не 5 значений, а 1 большое:

[1, 2, 3, 4, 5] <!-- корректный массив на 5 элементов -->[1; 2; 3; 4; 5] <!-- некорректный массив, так как такого разделителя быть не должно. Это может быть простой строкой, но тогда нужны кавычки -->!

3. Объект находится внутри фигурных скобок {}

Это объект:

{a: 1, b: 2}

Чтобы сломать это условие, уберите одну фигурную скобку:

{a: 1, b: 2

a: 1, b: 2}

Или попробуйте передать объект как массив:

[ a: 1, b: 2 ]

Ведь если система ждет от вас в запросе объект, то она будет искать фигурные скобки.

4. Массив внутри квадратных []

Это массив:

[1, 2]

Чтобы сломать это условие, уберите одну квадратную скобку:

[1, 2

1, 2]

Или попробуйте передать массив как объект, в фигурных скобках:

{ 1, 2 }

Ведь если система ждет от вас в запросе массив, то она будет искать квадратные скобки.

Итого

JSON (JavaScript Object Notation) текстовый формат обмена данными, основанный на JavaScript. Легко читается человеком и машиной. Часто используется в REST API (чаще, чем XML).

• JSON-объект неупорядоченное множество пар ключ:значение, заключённое в фигурные скобки { }.

• Массив упорядоченный набор значений, разделенных запятыми. Находится внутри квадратных скобок [].

• Число (целое или вещественное).

• Литералы true (логическое значение истина), false (логическое значение ложь) и null.

• Строка

При тестировании REST API чаще всего мы будем работать именно с объектами, что в запросе, что в ответе. Массивы тоже будут, но обычно внутри объектов.

Правила well formed JSON:

1. Данные в объекте написаны в виде пар ключ:значение

2. Данные в объекте или массиве разделены запятыми

3. Объект находится внутри фигурных скобок {}

4. Массив внутри квадратных []

См также:

Introducing JSON

RFC (стандарт)

Что такое XML

PS больше полезных статей ищитев моем блоге по метке полезное. А полезные видео намоем youtube-канале

Есть мнение, что войти в айти легче через тестирование. Будучи на третьем курсе, я part-time подрабатывала асессором. Тогда я впервые попробовала себя в тестировании, увидела первые чек-листы (я еще не знала, что они так называются). Войти в айти не было моей целью, потому что я уже и так училась на программиста, но сама идея тестирования меня очень увлекла. Так на последнем курсе я устроилась на стажировку в Kolesa Group.

Месяц подготовки: чтение пресловутого Романа Савина Тестирование дот ком, просмотр роликов на YouTube и практика в создании тест-кейсов. Этого мне хватило, чтобы начать свой джедайский путь в тестировании.

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

0. Не просить помощи

Когда я была стажером, мне очень хотелось показать себя, потому что от этого зависело, возьмут ли меня на работу. Но даже после успешного прохождения испытательного срока я взяла свои стажерские наклонности в junior-позицию. Я могла работать над парой задач в то время, когда еще парочка висела в бэклоге. И в тот же момент я частенько пыталась решить какие-то сторонние вопросы и проблемы. Итог: несколько висящих в воздухе задач, ожидающих меня, в то время как другой тестировщик мог быть свободен.

Я не говорю, что стараться и делать больше, чем нужно, это плохо. Плохо неразумно оценивать свои возможности и строить из себя героя в попытках сделать все. Не сделаешь. А если и сделаешь, то не так качественно, как мог бы. Просить помощи не зазорно. Грамотно делегировать нагрузку и задачи круто. Своевременные релизы и тщательно проверенные фичи лучшее, что может быть для продукта и бизнеса.

Вывод: проси помощь. Все мы люди и иногда нуждаемся в ней. Не успеваешь делегируй, но не злоупотребляй. Грамотно оценивай свои возможности и время.

1. Бояться задавать вопросы или задавать слишком много вопросов

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

В большинстве случаев так и есть, ответы на какие-то вопросы легко можно найти после пары минут гугления или поиска в stack overflow. Вопросы, связанные с бизнес-логикой, особенностями архитектуры и различными workflow, можно найти в документации (если в компании она, конечно же, ведется). Но сейчас я говорю о специфических вопросах, ответы на которые можно узнать лишь у коллег. Я могла тратить до 30 минут своего времени на гугл-поиски, поиски в документации компании, просмотр кода и даже иногда пыталась сама додумать ответ на свой вопрос (кстати, так делать не стоит). Итог: много потраченного на поиски времени и, возможно, так и не найденный ответ. Помочь избежать этого могли 510 минут общения с коллегами.

Но у этой медали есть обратная сторона задавать слишком много вопросов. Даже не так. Задавать вопросы без предварительно проведенного самостоятельного исследования. Бывают случаи, когда человеку легче подходить каждые пять минут с новыми вопросами, в то время как ответы на них можно было бы найти самому.

Вывод: иногда действительно продуктивнее просто спросить у коллег то, чего ты не знаешь. Но перед этим всегда нужно самому провести небольшой поиск ответа на вопрос и собрать все вопросы, которые возникли по ходу.

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

2. Не брать на себя ответственность

Когда ты джун, ты получаешь простые задачи и несешь меньше ответственности. Ты понимаешь, что есть более опытные коллеги, которые в случае чего придут на помощь и решат проблему. Например, при релизе забаганной фичи ты знаешь, что откат к предыдущей версии сделает кто-то другой. И так во многих вещах.Но для роста нужно научиться брать на себя ответственность и решать проблемы самому, брать инициативу и просить более сложные задачи, быть в эпицентре и помогать во время факапов. При совершении ошибок признавать их и искать пути решения. Брать ответственность не только за свои задачи, но и за качество продукта в целом.

Вывод

Через принятие ответственности можно выйти на новый уровень задач и новые челленджи, которые помогут в твоем профессиональном росте. Не бойся ответственности она твой друг.

Это были ошибки, которые я совершала не раз. Если быть честной на 100 %, я даже сейчас их иногда совершаю. Но это абсолютно нормально. Осознание проблемы первый шаг на пути к ее решению.

17 июня в 18:00 состоится Online LoGeek Night QA. На нем наши тестировщики расскажут о плюсах и минусах разных способов хранения данных в автотестах с примерами на Java, а также об автоматизации высокоуровневого тестирования ПО в авионке.

Также у вас будет возможность задать вопросы нашим специалистам, а также принять участие в розыгрыше призов в режиме online за лучшие вопросы.

Программа

18:00 18:50 Александр Гвоздев

Автоматизация высокоуровневого тестирования ПО максимального уровня безопасности для авионики (приборы первичной индикации, уровни A и B).

В докладе Александр рассмотрит:

Категории критичности отказных состояний бортового ПО и их влияние на аспекты сертификации;

Особенности верификации ПО максимального уровня безопасности;

Реализацию тестирования ПО первичной индикации;

Автоматизацию высокоуровнего тестирования ПО первичной индикации

О спикере: тестировщик по призванию. С 2000 года занимаюсь тестированием бортового ПО авиационного, аэродромного, автомобильного и даже подводного, и жизни многих людей зависят от качества моей работы. Рад, что внёс (пусть даже относительно крошечный) вклад в прогресс всего человечества.

18:50 19:40 Максим Власов

Способы хранения тестовых данных.

В докладе Максим расскажет о:

Двух способах хранить данные в авто тестах: данных в виде хардкода в файлах (json, xml, csv) и модуле внутри фреймворка, который данные генерирует;

О минусах и плюсах этих подходов с примерами на Java.

О спикере: большой опыт тестирования web приложений. В роли автоматизатора QA 5 лет. Два самых крупных проекта Yandex, реклама и Luxoft, банковская сфера. Прошёл путь от ручного тестировщика до тест лида. Любит рассказывать про сложные вещи простым языком.

19:40 20:00 Розыгрыш призов

Как принять участие

Митап пройдет онлайн 17 июня, 18:00 (МСК).

Чтобы принять участие, нужно:

• Зарегистрироваться насайте;

• Перейти по ссылке в ZOOM, которую вы получите за сутки и за час до начала митапа на почту.

Будем рады вас видеть!

Пофилософствуем на тему, как QA может влиять на разработку фич. Поделимся мыслями и наработками о том, что тестировщик может предложить команде помимо своих мануальных способностей проверки задач.

А в чем собственно проблема? Зачем тестировщику проявлять еще какие-нибудь качества помимо качеств мануального тестировщика?

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

Так зачем переделывать задачу и факапить сроки, если можно предотвратить большинство ошибок? Есть один вариант: QA-инженер. Специалист который будет влиять на качество процессов и продуктов на каждом этапе работы над фичей и служить связующим звеном между всеми этапами и подразделениями. В итоге вы получите качественный результат.

*Что мы подразумеваем под качественным результатом?

1. Мы смогли решить проблему конечного пользователя и закрыли его потребность вовремя.

2. Мы добились адекватного соотношения затраченных ресурсов и пользы, которую принесли бизнесу.

Чтобы прийти к качественному результату, нужно, чтобы QA участвовал на каждом этапе разработки фичи при:

• поиске оптимального подхода к реализации функционала;

• утверждении дизайна интерфейса;

• выставлении сроков.

Почему этим связующим элементом гипотетически должен стать QA?

Приведем несколько аргументов:

• У QA хорошо прокачаны софт-скиллы.

• QA это адвокат пользователя в продуктовой команде, мост между продуктом и пользователем и самый частый пользователь в одном лице.

• QA последний оплот перед релизом, поэтому именно в его интересах минимизировать количество недоработок на ранних этапах. Получается, чем больше багов он предотвратит на старте, тем легче будет его жизнь на финишной прямой, и, как следствие, дешевле обойдется разработка бизнесу.

• Если этого всего недостаточно, есть еще один аргумент: QA достаточно хорошо знаком как с технической стороной продукта, так и с интерфейсной. Короче говоря, он может подружить аргументы программиста, дизайнера и менеджера, если они не будут матчиться.

Давайте рассмотрим гипотетический процесс, на каждом этапе которого, предположим, участвует QA.Ремарка: это состояние идеального газа. Конечно, может быть много вариаций, в зависимости от специфики продукта, структуры компании и много чего еще.

История разработки одной фичи

Шаг 1. Знакомство команды разработки с новой фичей

На этом этапе фича еще может не иметь никаких очертаний. Задача QA включить одну из своих субличностей пользователь, чтобы осознать всю его боль и неудобства и контрибьютить идеями совместно с другими членами команды. QA будет предлагать идеи на стыке дизайна, разработки и пользовательского опыта, чтобы помочь команде увидеть картинку чуть более цельно.

Зачастую это может поменять видение менеджера на то, как нужно решать проблему. Фича может приобрести совершенно другой вид.

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

Шаг 2. Обсуждение UX/UI-решения

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

Когда перед глазами у тестировщика есть UX/UI-решение, он может увидеть все белые пятна в пользовательских сценариях. Этот вклад QA позволяет выявить те места, где в будущем появятся дополнительные требования. Те самые "доп.требования", из-за которых часто сдвигаются сроки релиза. Надо зарелизить фичу в срок и минимизировать затраты бизнеса.

Будьте готовы к тому, что UX/UI-решение возможно придется переделать. Это может быть кнопка, текст на кнопке или вся фича целиком. Этап может повториться несколько раз, пока команда не придет к лучшему возможному решению.

Совет: Чтобы к QA начали прислушиваться, покажите пример улучшения фичи, которую сделали без QA на этом этапе и расскажите, что история могла сложиться иначе. Найдите, как можно улучшить какой-нибудь user story в какой-нибудь уже реализованной фиче или задаче, которую вы тестируете сейчас.

И еще один совет: разберите базовые вещи об UX/UI науке. Изучите простейшие критерии качественного интерфейса.

Шаг 3. Декомпозиция задачи и оценка сроков

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

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

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

Роль QA проговорить еще раз каждую подзадачу с разработчиком и пропустить все это через тест-кейсы и user story. Найти оставшиеся подводные камни. Отловить нотки неуверенности в голосе разработчика, которые показывают, достаточно ли изучили задачу, чтобы выставлять срок.

Также QA нужно определить глубину и объем затронутого новым функционалом кода, который предстоит тестировать перед релизом.

Часто на этом этапе приходят всякие озарения по саб-таскам, а сроки становятся более предсказуемыми. Бросать такую огромную работу на разработчика нечестно, и круто, если он это делает в паре с QA, который дополняет картину мира и смотрит с другого ракурса.

Совет: QA надо качать технические скилы, чтобы лучше понимать разработчиков и быть с ними на одной волне. И в целом не помешало бы выстраивать дружеские отношения с разработкой, чтобы было к кому обратиться за более глубокими разъяснениями о том, как работает фича под капотом.

Шаг 4. Обсуждение подводных камни и поиск компромиссов

Команде из QA и разработчика нужно рассказать менеджеру обо всех найденных технических проблемах. Например, если поняли, что функционал не удастся реализовать в том виде, в котором предлагают дизайнеры, или если на это потребуется гораздо больше времени, чем предполагалось. А потом уже всем вместе (разработчик, QA, менеджер и дизайнер) прийти к решению, как поступить в этой ситуации:

• увеличить ресурсы, например, выделить больше времени или добавить разработчиков в команду;

• упростить функционал;

• ну, или смириться с реальностью.

Гипотетический результат от гипотетического внедрения этого подхода:

1. Сроки становятся более предсказуемыми.

2. Качество продукта повышается.

3. Стоимость разработки снижается за счет устранения ошибок и возможных доработок еще до начала процесса разработки.

Ну и несколько тривиальных советов QA-специалисту, который хочет быть полезен на каждом этапе работы над фичей:

• Знать идею продукта, фичи.

• Иметь представление о пользователе.

• Иметь понимание, что бизнес хочет от пользователя.

• Иметь понимание, что пользователь хочет от продукта.

• Иметь понятия об UX/UI.

• Иметь базовое понимание в программировании.