есть вопрос про тестовое задание (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, я не хочу отдавать свои код чтоб они потом его использовали на своем проекте, или части кода, что им понравились, хотите нанимайте меня и я буду вам делать такие вещи, с другой стороны я хотел бы показать но что я способен и выделиться среди других кандидатов.
Что нужно включать в подобное тестовое задание? какие технологии стоит включить а какие не стоит.
Тестовое задание на реальном сайте или чисто абстрактный пример?
Удаленное или на собеседовании?
Лично я бы при формулировке подобного задания подразумевал бы некий абстрактный тест. Т.е. проверка понимания структуры (DSL). Ради интереса можно было бы еще показать маленький пример пейджи, которая содержит всю использованную в тесте логику. Полномасштабная имплементация - нонсенс.
Если же описывается реальная задача, то проще будет взять какой-то готовый фреймворк по типу Selenide, и описать пару пейджей и тестов, используя стандартные паттерны.
Вряд ли кто-то в здравом уме требовал бы описывать реальный фреймворк.
да, есть реальный сайт в интернете, дают егo url
есть четкий dead line, дают время хх часов потом нужно выслать тестовое задание на рассмотрение. Обычно 48 часов, выходные, и к понедельнику 9-00 выслать задание
Какие технологии туда включить? Делать полноценный webdriverFactory или достаточно захардкодить в @BeforeClass new FirefixDriver()
Напишите раннер, который будет создавать / убивать инстанс драйвера под аннотированным методом. Но опять-таки, чтобы сильно не заморачиваться с имплементацией компонентов фреймворка, проще взять какую-нибудь готовую фабрику. Тут акцент все же лучше сделать на пейджах / DSL и тестах.
Хотя, такие задания настораживают, если честно. Особенно на высокие позиции. Джун понятно что не напишет сложных архитектурных решений. А сеньор / лид просто плюнет на подобное, понимая, что если делать по-хорошему - это займет много времени, а по-плохому - нет смысла.
Если уж на то пошло, после такого они сразу должны давать офер без собеседований. Ну разве что можно попросить объяснить, что написали, дабы понять, кто автор.
А еще лучше - давать линк в CV на github аккаунт. Пусть изучают код, и никаких тестовых заданий не понадобится.
Я бы выслал вариант 1. Потому, что чем проще, тем лучше! Это моя философия. Если они меня не возьмут из-за того, что слишком просто, то нахрен они мне сдались.
я понимаю всю иронию вопроса но вопрос не об этом.
получается вариант №2 с такими технологиями:
PageObject, PageFactory, TestNG(в нем есть простой репорт) возможно ReportNG, т.к. он сильно простой в конфигурации. Возможно propertie file добавить.
Недавно был подобный случай. Проходил собеседование с тестовым заданием типа “логин и сайнап”.
Сделал по варианту 1, попроще, с подстановкой единоразовых тестовых данных. Пришел фидбек, еще добаить это и это. Сделал. Подключился еще один товарищ, который спросил - а почему это не выложено на гитхаб, и код не рабочий, так как к нему нет requirements.txt, и вебдрайвер ему пришлось устанавливать вручную.
Добавил все, что хотелось, выложил на гитхаб со всеми требованиями. Сделал рефакторинг, довел до “вариант 2+”, выслал.
На последнем этапе уже от третьего человека услышал следующее “ну код чистый, претензий нет, а почему в методах не использовали доктест? И вообще нет никакой доукментации”.
Поэтому иногда бывает сложно понять, что все таки требуется от тестового задания.
Возможно больше - лучше.
Почему же? Ваша цель сделать задание за ХХ часов максимально качественно и правильно с вашей точки зрения. Есть наработки, которые не жалко “слить” - используйте; остается лишнее время - добавляйте новые, необходимые с ВТЗ, фичи.
[quote=“Funker, post:8, topic:7467”]
получается вариант №2 с такими технологиями:PageObject, PageFactory, TestNG(в нем есть простой репорт) возможно ReportNG
[/quote]Не стоит этим инструментам так льстить - называя их технологиями
Дело в том, что если на “той” стороне сидит опытный человек, он определит ваш уровень “на раз”, и ему будет все-равно какие third-party либы вы используете.
Я голосую за 2- (то есть упрощенный п.2). Я считаю, что важно в тестовом задании показать именно правильную архитектуру - разбиение на “слои”, как я их называю (тест, бизнес-логика (DSL), PageObject, Elements). А всякие плюшки типа ReportNG - это вторичное. Второй аргумент в пользу (2-) - это то, что после тестового задания всё равно будет устное собеседование, где можно будет более подробно выяснить твои знания.
А тестовое задание нужно для понимания, что ты не просто умеешь языком чесать технически грамотно (бывают такие специалисты), но и реально можешь что-то делать
Очень правильное замечание, я считаю. И большой минус кандидату, который об этом моменте не подумает. Вполне себе такой негласный пункт тестового задания - показывает уровень опыта командной работы (насколько человек заботится о том, чтоб коллегам было просто с ним работать)
Тогда собственно можно сделать вывод и дать ответ топикмейкеру, если это все негласные пункты, и эти пункты могут быть разные, то длеать ТЗ надо по максимуму из своих возможностей.
Тоесть пункт 3?
На самом деле наверное грамотное совмещение технической реализации и продуманных мелочей как раз покажет уровень кандидата лучше, чем навороченный фреймворк, в котором хрен разберешься. Ещё подумают, что “мега-звезда” на вакансию клюнула, испугаются
testomat.io управление авто тестами
