Несмотря на колоссальные возможности современных табличных редакторов, для многих команд разработки рано или поздно встает вопрос о внедрении специализированных инструментов (систем) для управления процессом тестирования в своих проектах. Какой же из них выбрать?
Такой вопрос в моей практике задавался не раз. Это подтолкнуло меня на создание этой обзорной статьи. Чтобы в будущем сэкономить немного времени себе и всем тем, кто также столкнется с этим вопросом. И пусть даже в конце статьи на него не будет ответа (извините за спойлер), но ваше подсознание, скорее всего, определится уже сейчас и в нужный момент на определенном проекте подскажет ответ.
В своих поисках я натыкался на множество аналогичных статей (в одной из которых я позаимствовал структуру сравнительной таблицы), но все они скупо перечисляют функции с сайтов этих систем и 1-2 скриншота интерфейса и зачастую содержат скрытую или открытую рекламу одного из таких инструментов. Мне же захотелось испытать каждую систему “на себе” и непредвзято поделиться увиденным, рассказать о своих ощущениях.
Посоветуйте, как еще можно покрыть следующий случай?
Есть компонент, позволяющий отслеживать изменения текста (https://nytimes.github.io/ice/demo/). Фрилансеры, выполняющие заказ на составление html-разметки, вводят ее в текстовое поле. Но у данного текстового поля существует валидация: не пропускать html теги. Под тегами подразумевается: < набор символов, содержащий хотя бы одну английскую букву >. По правилам сайта, фрилансеры должны заменять треугольные скобки в тегах на квадратные. Делается это потому что компонент преобразует текст, содержащий html теги, в разметку и выдает заказчику готовую страницу, а ему необходимо видеть именно чистый html.
Мои кейсы:
1) <h1> text </h1>
2) <!DOCTYPE> text
3) <img src="/images/branding/googlelogo/2x/googlelogo_color_272x92dp.png" ">
4) <!-- <p> text </p> -->
5) <<p> text </p>>
6) < <p> text </p> >
Система не должна пропустить такие варианты.