Правила Well Formed XML

Это выдержка из моей статьи «Что такое XML»

Разработчик сам решает, какой XML будет считаться правильным, а какой нет. Но есть общие правила, которые нельзя нарушать. XML должен быть well formed, то есть синтаксически корректный.

Чтобы проверить XML на синтаксис, можно использовать любой XML Validator (так и гуглите). Я рекомендую сайт w3schools. Там есть сам валидатор + описание типичных ошибок с примерами.

В готовый валидатор вы просто вставляете свой XML (например, запрос для сервера) и смотрите, всё ли с ним хорошо. Но можете проверить его и сами. Пройдитесь по правилам синтаксиса и посмотрите, следует ли им ваш запрос.

Правила well formed XML:

1. Есть корневой элемент.
2. У каждого элемента есть закрывающийся тег.
3. Теги регистрозависимы!
4. Соблюдается правильная вложенность элементов.
5. Атрибуты оформлены в кавычках.

Давайте пройдемся по каждому правилу и обсудим, как нам применять их в тестировании. То есть как правильно «ломать» запрос, проверяя его на well-formed xml. Зачем это нужно? Посмотреть на фидбек от системы. Сможете ли вы по тексту ошибки понять, где именно облажались?

См также:
Сообщения об ошибках — тоже документация, тестируйте их! — зачем тестировать сообщения об ошибках

Что такое VCS (система контроля версий)

Система контроля версий (от англ. Version Control System, VCS) — это место хранения кода. Как dropbox, только для разработчиков!

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

А потом я подробнее расскажу, как VCS работает — что значит "создать репозиторий", "закоммитить и смерджить изменения", и другие страшные слова. В конце мы пощупаем одну из систем VCS руками, скачаем код из открытого репозитория.

Что это такое и зачем она нужна

Допустим, что мы делаем калькулятор на Java (язык программирования). У нас есть несколько разработчиков — Вася, Петя и Иван. Через неделю нужно показывать результат заказчику, так что распределяем работу:

• Вася делает сложение;

• Петя — вычитание;

• Иван — начинает умножение, но оно сложное, поэтому переедет в следующий релиз.

Исходный код калькулятора хранится в обычной папке на сетевом диске, к которому все трое имеют доступ. Разработчик копирует этот код к себе на машину, вносит изменения и проверяет. Если всё хорошо — кладет обратно. Так что код в общей папке всегда рабочий!

Что такое бранч (отдельная ветка в коде) и зачем она нужна

Это выдержка из моей статьи «Что такое VCS (система контроля версий)». Нужна именно как напоминание «что такое бранч», если с самой системой контроля версий вы уже знакомы

— Бранч — это отдельная ветка в коде. Вот смотрите, мы сейчас работаем в trunk-е, основной ветке.

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

Потом разработчик добавляет новый функционал и коммитит его — это версия 1 кода.

Телеграмм-канал от Testbase

 

Я таки доросла до канала в телеграмме =) Буду туда скидывать свои полезные материалы (видео, статьи) — от портала Testbase и меня)

https://t.me/links_from_testbase

Мои 12 недель в году. Часть 15 (костная пластика и Консоль)

Первый опыт, второй, третий, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14

 

Что это за техника

Вы собираетесь с друзьями в группу и ставите себе цели на 12 недель (3 месяца). Это могут быть как рабочие, так и личные задачи. Такие, которые вы вроде как хотите сделать, но вечно откладываете, так как «некогда, потом, щас, вот только мелочевку разгребу и тот пожарчик потушу».

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

Я комбинирую с магией утра.

Результаты кратко

У нас появилась кошка!! Знакомьтесь, это (на фото чуть выше) — Консоль =))) Главная радость цикла )))

А вообще, бомбический получился цикл по содержанию бесплатных полезняшек! Я написала 11 хабра-постов. 11 !!!! Это вместо запланированной ОДНОЙ, максимум двух =))) И столько же видео опубликовала на ютубе. Вообще стремлюсь к «1 видео в неделю», но где-то не срослось.. Ну и ладно, всё равно много!

Основные цели:

— книга: найти еще художников

— курсы: сделать 1 урок курса по регуляркам

— статья на ХАБР!

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

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

Но в этот раз ближе к концу цикла я решила вновь заняться своими зубами (у меня 2 дырки, вырвали 2 года назад последние молочные, коренных под ними нет). Врач сказал, что десна тонкая и нужна костная пластика. Что же, сделала её. Лицо попухло и пару недель о записи вебинара и речи быть не могло. А потом заболели с ребенком, а запись "в нос" тоже не ахти. Так что курс переехал в летний цикл!

Но зато вон сколько всего получилось:

1. Сделали 400 картинок к книге ＼(〇_ｏ)／ 
2. Посты из книги, пополняя бесплатный онлайн-вариант —  15 штук ٩(◕‿◕｡)۶
3. Улучшалки по текущим курсам — они небольшие, но набирается прилично! 
1. Улучшалки по ШНАТ — 30 штук
2. Постман  — 11 штук
3. Рест —  6 штук
4. Логи — 3 штуки
5. Локализация — 1
4. Пополняю раздел «работы студентов» — 2 штуки
5. Пополнила свой youtube-канал — 11 штук! ＼(〇_ｏ)／ 
6. Статьи на Хабр — 11 штук! ＼(〇_ｏ)／ ＼(〇_ｏ)／ ＼(〇_ｏ)／ 
7. Testbase — 7 улучшалок
8. Прочитала 3 книги ¯\_(ツ)_/¯
9. Прошла курс по фидбеку! 
10. Инструменты 12 недель — продолжаю вести файлик DONE, это все еще очень круто
11. Завели кошку!!
12. Купила Владу санки с колесиками, очень удачно, катались всю зиму
13. Отказались от соски!!!
14. Ходила в кино — в том числе в 4дх!
15. Играли в настолочки )))
16. Выбралась на ДР компании!
17. Встретилась с Юлечкой (1.5 года не виделись)
18. Встречалась с друзьями другими
19. Ходила в СПА 3 раза ^_^
20. Занималась ремонтом
21. Забрала исполнительный лист и отнесла в банк (зря, надо было приставам)
22. Сделала костную пластику на деснах
23. Мне сорвало батарею на новой квартире, жестокий опыт)))

Визуализация ТЗ — диаграммы, схемы, картинки

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

Как же сделать ТЗ понятнее? Можно улучшить текст — вместо скупого текста составить вариант использования. А можно использовать визуализацию. То есть добавить в требования картинки, диаграммы, таблицы...

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