IT-рекрутмент. Как найти лучших специалистов, когда все вокруг горит

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

Разработка frontend-части состоит из HTML, CSS и JavaScript (естественно, как было сказано выше, могут применяться и другие технологии — мы делаем упор на эти как на наиболее распространенные).

Логически фронтенд-разработку можно разделить на верстку и логику (скрипты).

JavaScript («ДжаваСкрипт») — скриптовый, строго не типизированный язык. С его помощью разработчик может добавлять интерактивные элементы на сайт (например, игры, динамические стили, анимацию). Возможности JavaScript позволяют создавать много интересного, вплоть до серьезной 2D— и 3D-графики.

Как и любой язык программирования, JavaScript меняется и обрастает своими фреймворками, библиотеками и платформами, среди которых можно упомянуть Angular, React|Redux, Vue.js и Node.js.

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

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

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

● с помощью языка HTML размечает элементы на странице;

● через язык CSS (Cascading Style Sheets) придает им внешний вид: задает цвета, шрифты, расположения отдельных блоков и т. д.

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

Глава 11 Тестирование

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

За этот этап работы отвечают Quality Assurance Engineer (специалисты/инженеры по качеству, сокращенно QA), или попросту тестировщики.

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

Manual Testing (ручное тестирование) происходит следующим образом: QA-специалист «изображает» поведение пользователя и регистрирует, где и что именно пошло не так.

Как QA узнает, что именно ему делать? С помощью системного аналитика или продакт-менеджера. Как правило, системный аналитик предполагает, как поведет себя пользователь, попав, например, на новый веб-сайт. На основе этого он составляет Use-case — пользовательский сценарий. Двигаясь по этому сценарию, тестировщик «прокликивает» продукт и описывает поведение программы в тест-кейсах и чек-листах.

У ручного тестирования есть неоспоримые плюсы:

● Это сравнительно недорогой способ найти самые грубые ошибки, причем сделать это максимально быстро: разработчики оперативно получат обратную связь и устранят все баги.

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

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