Спасибо за статью! Концепция очень привлекательна, и очень актуальна для многих. Оч ждем продолжения, особа хочется, чтобы была рассмотрена часть подготовки тестовых данных и реализация хранения локаторов.
Из нюансов хотел бы обратить внимание, что Junit 4 и java 8 устарели, а проблем с переходом на новые версии быть не должно. Возможно Вам понравятся некоторые рюшички junit 5 и новая модульная система java более поздних версий.
Простите, возможно не до конца проникся Вашему трактованию о «полезном коде». Если так, то да. А что касается времени и качества, то услышьте меня, не надо входить в крайности про «Hello, world!». Зачастую менеджеры в основном далеки от разработки. Они видят потребность бизнеса и стремятся во что бы то ни стало реализовать ее максимально быстро, полагая, что внутренняя архитектура проекта — пустая трата времени. И это именно то, с чем я имею дело. И вот этот вот и приводит к обратному Вами трактованию полезного кода и всем прилагающим. У меня есть собственные примеры командной работы, когда из-за таких гонок, итоговый проект выходил на несколько месяцев позже срока. И подобный ущерб очень существенен, он перекрывает все — потеря прибыли за пол года, разработка длилась больше на пол года. В ТЗ же упор обычно делается именно на новую функциональность, и на моей практике, как я уже сказал, в нем никогда не просчитываются все нюансы текущей функциональности, которая развивалась и менялась годами. Не знаю степень сложности Ваших систем, но с тем с чем работаю я — определить все нюансы невозможно до начала ее реализации функциональности. Хоть и ТЗ смотрят несколько человек, перед реализацией. Вот тут и встает вопрос о степени вовлеченности разработчика в процесс и его мотивации — собственно это играет основополагающую роль. Итого — «гонки» менеджеров и пофигизм разработчиков ведут к колоссальным затратам. Возможно наша команда не умеет работать, а Вы умеете, но мы имеем то что имеем. И примеров у меня, к сожалению, много
Он получает задачи, в виде очень подробного ТЗ, которое должно исключить какие-либо варианты двойного толкования.
Все должно быть строго регламентировано в рамках ТЗ.
Должно-то оно должно, но проблема в том, что в крупных проектах таких ТЗ не существует (я искренне хотел бы в это верить, но факт есть факт — их нет). При интеграциях, при пересечениях логики — на каждом шажке в крупных проектах есть куча нюансов и подводных камней. В своей практике часто вижу как разработчик-пофигист делает все строго по ТЗ, а шаг влево шаг вправо и упало. И ведь с такими и спорить невозможно — они никогда ни в чем не виноваты. Мозговой центр разработки — это разработчик, а не менеджер. И качество делают разработчики. А «максимум полезного кода за минимальный промежуток времени» на практике почти всегда с течением времени приводит к большим затратам бюджета, нежели экономии здесь и сейчас
Да все верно подмечено. Как тестировщик, работающий с разными проектами и разными разработчиками уже не первый год, могу сказать что так и есть. Если прогеру пофиг на продукт, то он ВСЕГДА получается говном. А вот кому это заявление кажется странным, тот скорее всего и делает говно.
Спасибо что оценили! Было очень приятно читать Ваши замечания) По большей части я с Вами абсолютно согласен, особенно касательно стороны тестовых фреймворков. Обязательно возьму в фокус при дальнейшей работе!
А вообще странная штука получается. Никому не нравится XML. Весьма странно, тем более что большую часть времени автоматизаторщик занимается тем, что вытаскивает пути Xpath из веб-страниц. Если проще — ковыряется в XML.
Да я бы и сам не пользовался, если количество типов было уже больше 20 (хоть и проблему ифов можно решить нехитрой манипуляцией с функциями и хэшмапом))
А про orderNumber ситуация интересней. В далекой первоначальной версии его не было. Это скорее не костыль а такая неприятная издержка. Решил в пользу нее т.к. это немного развязывает руки при манипуляциях в коде и дает стойкое чувство спокойствия за порядок следования.
Отвечу по пунктам:
1. Мои ивенты — это не конвертация параметров в команды веб-драйвера. Ивент — это целый сценарий, который может быть любым и любого объема и любой сложности. В моем случае это не только селениум — это еще и часть БД. Согласен, что количество типов ивентов может расти, однако я не считаю, что выделение стабильных сценариев и разрастание их количества стоит считать костылем — при грамотном подходе это как рас ведет к уменьшению объема работ при описании теста.
2. Предлагаю Вам все же попробовать мой подход в точности как он описан — я не набираю вручную xml разметку вообще — все что мне нужно сделать — это открыть тег или выбрать параметр из списка доступных — структура строится автоматически + в xml editor наглядно видно всю структуру теста как на ладони — на мой взгляд все же удобнее.
3. Собственно xml — потому что это самый распространенный тип разметки, и о том, как автоматизировать набор структуры xml я имел представления. О наличие подобия XSD схем для YAML я не слышал (возможно они и есть — но я просто взял то что мне ближе — т.е. не выбирал)
4. Полностью согласен, могу лишь оправдаться — условия в компании я описывал, и в настоящий момент мой инструмент — это просто попытка автоматизировать мануальный тест — прога в помощь тестеру.
Я не знаю прямых альтернатив, и скорее сам не пытался рассматривать все. Но лично если бы я искал альтернативу из готовых решений, то это Katalon Studio
Отличное описание работы флинка
Из нюансов хотел бы обратить внимание, что Junit 4 и java 8 устарели, а проблем с переходом на новые версии быть не должно. Возможно Вам понравятся некоторые рюшички junit 5 и новая модульная система java более поздних версий.
Должно-то оно должно, но проблема в том, что в крупных проектах таких ТЗ не существует (я искренне хотел бы в это верить, но факт есть факт — их нет). При интеграциях, при пересечениях логики — на каждом шажке в крупных проектах есть куча нюансов и подводных камней. В своей практике часто вижу как разработчик-пофигист делает все строго по ТЗ, а шаг влево шаг вправо и упало. И ведь с такими и спорить невозможно — они никогда ни в чем не виноваты. Мозговой центр разработки — это разработчик, а не менеджер. И качество делают разработчики. А «максимум полезного кода за минимальный промежуток времени» на практике почти всегда с течением времени приводит к большим затратам бюджета, нежели экономии здесь и сейчас
А по поводу ада… Ну я же не в блокноте работаю — у меня выглядит примерно так:
А про orderNumber ситуация интересней. В далекой первоначальной версии его не было. Это скорее не костыль а такая неприятная издержка. Решил в пользу нее т.к. это немного развязывает руки при манипуляциях в коде и дает стойкое чувство спокойствия за порядок следования.
1. Мои ивенты — это не конвертация параметров в команды веб-драйвера. Ивент — это целый сценарий, который может быть любым и любого объема и любой сложности. В моем случае это не только селениум — это еще и часть БД. Согласен, что количество типов ивентов может расти, однако я не считаю, что выделение стабильных сценариев и разрастание их количества стоит считать костылем — при грамотном подходе это как рас ведет к уменьшению объема работ при описании теста.
2. Предлагаю Вам все же попробовать мой подход в точности как он описан — я не набираю вручную xml разметку вообще — все что мне нужно сделать — это открыть тег или выбрать параметр из списка доступных — структура строится автоматически + в xml editor наглядно видно всю структуру теста как на ладони — на мой взгляд все же удобнее.
3. Собственно xml — потому что это самый распространенный тип разметки, и о том, как автоматизировать набор структуры xml я имел представления. О наличие подобия XSD схем для YAML я не слышал (возможно они и есть — но я просто взял то что мне ближе — т.е. не выбирал)
4. Полностью согласен, могу лишь оправдаться — условия в компании я описывал, и в настоящий момент мой инструмент — это просто попытка автоматизировать мануальный тест — прога в помощь тестеру.