Каким должен быть ответ на тестовое задание по Selenium/WebDriver?

selenium
webdriver
web
тестовоезадание
Теги: #<Tag:0x00007fedc75f09d0> #<Tag:0x00007fedc75f07c8> #<Tag:0x00007fedc75f0660> #<Tag:0x00007fedc75f04f8>

(Funker) #1

есть вопрос про тестовое задание (Selenium, Web).
Каким его хотят видеть с той стороны?

Пример тестового задания:
напишите автотесты типа login(positive, negative), logout, сортировка на странице очень простые тесты.

Вариант 1 (простой)
- "голый", "чистый" Selenium API чистая Java JUnit/TestNG, усе тесты написаны и работают как ожидается
Результат ожидаемый, что тестовое задание провалено.

Вариант 2 (продвинутый)
- Selenium, PageObject, PageFactory, logging, JUnit/TestNG, multi browsers, и куча других простых фич.
Результат возможно что вы прошли, но нужно еще с вами поговорить детально.

Вариант 3 (гуру)
- все тоже самое что и вариант 2 но еще + свой крутой опыт, полноценный крутой фреймворк, webdriverfactory, custom elements(buttons, inputs etc), возможно, Spring Framework, куча всяких утилит и хелперов, поддержка Selenium Grid, Proxy...
Короче крутой-крутой фреймворк.

Вопрос: какой варант высылать 2 или 3?
Но у меня двойственное чувство по поводу варианта №3, я не хочу отдавать свои код чтоб они потом его использовали на своем проекте, или части кода, что им понравились, хотите нанимайте меня и я буду вам делать такие вещи, с другой стороны я хотел бы показать но что я способен и выделиться среди других кандидатов.
Что нужно включать в подобное тестовое задание? какие технологии стоит включить а какие не стоит.

А также будет полезным почитать:


(Руслан) #2

я думаю всё-таки 2
оставь изюминку, если пройдёшь smile


(Sergey Korol) #3

Уточняющие вопросы:

  • Тестовое задание на реальном сайте или чисто абстрактный пример?
  • Удаленное или на собеседовании?

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

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

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


(Funker) #4

да, есть реальный сайт в интернете, дают егo url
есть четкий dead line, дают время хх часов потом нужно выслать тестовое задание на рассмотрение. Обычно 48 часов, выходные, и к понедельнику 9-00 выслать задание

Какие технологии туда включить? Делать полноценный webdriverFactory или достаточно захардкодить в @BeforeClass new FirefixDriver()


(Sergey Korol) #5

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

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

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

А еще лучше - давать линк в CV на github аккаунт. Пусть изучают код, и никаких тестовых заданий не понадобится.


(vmaximv) #6

Давайте определимся сначала с этим. У вас действительно есть ФВ, который был успешно "обкатан" на 3-4 больших проектах и все были от него в восторге?


(asolntsev) #7

Я бы выслал вариант 1. Потому, что чем проще, тем лучше! Это моя философия. Если они меня не возьмут из-за того, что слишком просто, то нахрен они мне сдались.


(Funker) #8

я понимаю всю иронию вопроса но вопрос не об этом.

получается вариант №2 с такими технологиями:
PageObject, PageFactory, TestNG(в нем есть простой репорт) возможно ReportNG, т.к. он сильно простой в конфигурации. Возможно propertie file добавить.


(Виталий Коряков) #9

Недавно был подобный случай. Проходил собеседование с тестовым заданием типа "логин и сайнап".
Сделал по варианту 1, попроще, с подстановкой единоразовых тестовых данных. Пришел фидбек, еще добаить это и это. Сделал. Подключился еще один товарищ, который спросил - а почему это не выложено на гитхаб, и код не рабочий, так как к нему нет requirements.txt, и вебдрайвер ему пришлось устанавливать вручную.
Добавил все, что хотелось, выложил на гитхаб со всеми требованиями. Сделал рефакторинг, довел до "вариант 2+", выслал.
На последнем этапе уже от третьего человека услышал следующее "ну код чистый, претензий нет, а почему в методах не использовали доктест? И вообще нет никакой доукментации".
Поэтому иногда бывает сложно понять, что все таки требуется от тестового задания.
Возможно больше - лучше.


(vmaximv) #10

Почему же? Ваша цель сделать задание за ХХ часов максимально качественно и правильно с вашей точки зрения. Есть наработки, которые не жалко "слить" - используйте; остается лишнее время - добавляйте новые, необходимые с ВТЗ, фичи.

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


(Funker) #11

тогда возникает вопрос, зачем им вообще нужно мой ответ на тестовое задание.

У вас еще хорошо получилось, что вам дали возможность исправить и отправить снова, у других просто ответ - failed


(vmaximv) #12

Что то я вас недопонимаю. Ну ок - добавим конкретики:


(Александр Таранков) #13

Я голосую за 2- (то есть упрощенный п.2). Я считаю, что важно в тестовом задании показать именно правильную архитектуру - разбиение на "слои", как я их называю (тест, бизнес-логика (DSL), PageObject, Elements). А всякие плюшки типа ReportNG - это вторичное. Второй аргумент в пользу (2-) - это то, что после тестового задания всё равно будет устное собеседование, где можно будет более подробно выяснить твои знания.

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


(Виталий Коряков) #14

Согласен, что гитхаб - это неоспоримый плюс, но когда это стало обязательным для ТЗ?


(Александр Таранков) #15

Очень правильное замечание, я считаю. И большой минус кандидату, который об этом моменте не подумает. Вполне себе такой негласный пункт тестового задания - показывает уровень опыта командной работы (насколько человек заботится о том, чтоб коллегам было просто с ним работать)


(Виталий Коряков) #16

Тогда собственно можно сделать вывод и дать ответ топикмейкеру, если это все негласные пункты, и эти пункты могут быть разные, то длеать ТЗ надо по максимуму из своих возможностей.
Тоесть пункт 3?


(vmaximv) #17

У ТС пункт 3 лежит немного в другой плоскости.


(Funker) #18

и да и нет. На этом не стоит акцентировать внимание, как мне кажется. Встречался с такими вариантами:
- ответ в zip архиве вышлите на такой-то адрес (большинство случаев)
- ответ выложите на gitHub в лучших традициях commit + "comment"
- ничего не сказано, вот тут то и можно применить свою фантазию. Но таких вариантов практически нет.


(Виталий Коряков) #19

Вот как раз и был такой вариант )))


(Александр Таранков) #20

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