Modern Testing Principles (Alan Page & Brent Jensen)
Все уже давно сформулировано и обсосано со всех сторон, повторяться не вижу смысла. Вкратце, тестирование — да, тестировщики — не факт.
Самоодаптирующийся ИИ думаю высосали из последнего опуса ISTQB, не самый уважаемый ныне источник. А так, почти все известные широкой публике "ИИ" это переучивающиеся локаторы (не спорю, есть другие разработки, но очень нишевые).
У меня проблемы выбора нет: либо английский, либо французский (то бишь — английский =)
Но даже при работе с русскоязычными коллегами мне бы было тяжело писать style guide на русском. Просто потому что пытаешься ориентироваться на опубликованные гайды всяких Адидасов и Заландо, и мозг почти невозможно переключить на режим "а давайте теперь попытаемся это все перевести не птичьим языком".
JSON Schema Draft 2019-09 has been published for a while, and after much deliberation we got the folks at OpenAPI to merge #1977 for v3.1. This will make OpenAPI a small superset, and no longer a subset/superset/sideset. Of those five keywords, two are deprecated (nullable and example).
Phil Sturgeon
В качестве интрументов можно еще добавить Spectral, легко настраивать правила под свои гайдлайны.
Вообще, DX очень клевая область, но важно иметь возможность вести технофашизм и buy-in со стороны менеджмента, потому что люди имеют тенденцию игнорить это все по аналогии с UI (хотя в отличии от UI, пофиксать APIшку гораздо тяжелее).
Тестирование — не столь изученная область, как программирование. Если у вас есть талант и трудолюбие, вы сможете сказать своё слово миру (написать книгу, создать методологию, преподавать и т.д.)
Эм. Инноваций именно со стороны тестировщиков с гулькин нос. Матаппарат и техники анализа пришли от аналитиков и рисковиков, технические штуки — вещь всеобщая. Остается только философия, которую развивать особенно уже некуда. Бах&Болтон затерли до дыр context-driven и RST, MT по сути уже о пост-тестировании… ну вот ISTQB недавно выдало маловразумиельное видение того, как AI всех спасет (видать, новые сертификаты рисуют).
Новье сейчас приходит со стороны разрабов и девопса. Так что те, кто не вайтишник, а хочет быть в тестировании: не надо питать иллюзий. Ибо для того, чтобы не оставаться кнопкожмакателем, нужно в первую очередь постоянно мониторить и поглащать информацию от НЕтестировщиков.
Я бы добавила, что не ограничивайтесь тестированием вообще. Изучайте разные дисциплины и технологии, тестировщик — это как универсальный дженералист, никогда не знаешь, какой кусок информации понадобится на следующем проекте.
Ну и самое главное, валить как только понимаешь выгорание. Скорее всего не поймешь, нужен какой-то контроль снаружи. Я вот поняла только после вынужденного отпуска, после которого абсолютно не хотелось на работу. И тем не менее, по возвращению отработав еще месяц-два, я опять чуть не осталась.
Да хоть обложись этим тест-дизайном, от выгорания это не поможет. Статья-то вообще про другое. Про культуру. Никому этот тест-дизайн не сдался если "нет фидбека", "работа в стол", "нет команды".
Вот любит наш брат трястись над священной коровой дизайна, когда по факту это (а) ничего уникального и используется теми же БА (в кои автор не хотела переходить), (б) часто далеко не самый важный фактор влияния на качество.
Мы тоже используем этот отчет. Причина такая: аналог (фиговый) аллюр сервера написан уже давно и все тулзы генерят отчеты под него. Переделывать очень трудозатратно (помимо тестов на pytest есть еще большая куча других, большинство самописных). Добавить отображение одной HTMLки в общий отчет на сервере всяко проще чем тащить весь аллюр. Да и по факту говоря, эту HTMLку обычно смотрят ради скриншотов.
Взгляд с той стороны баррикад: в принципе все неплохо и приятно, но хочу предостеречь насчет вопросов про "самые интересные/сложные баги." Не все смогут ответить. Способность восхищаться найденной проблемой — очень зависит от личностных характеристик, проектов, времени. Знаю по себе и другим коллегам, некоторым скорее всего ничего в голову даже не прийдет, хотя на старте карьеры такие примеры бы вспомнились. У меня был период, когда один фейспалмно-обалденный баг сменялся другим почти ежедневно, и в какой-то момент я просто перестала их запоминать надолго как нечто особенное. Некоторые начинают записывать на память, мне лень. Да и вообще, поиск багов для меня — наименее эффективная деятельность по влиянию на качество продукта, больше фрустрации чем пользы.
К вашему списку вопросов я бы добавила банальный про "как развиваетесь?". Т.е. про книжки, конференции, слаки, форумы, вышеупомянутый SO. Вероятно, что не всё, что кандидат ответит, вы знаете\поймете, но по степени "яркости" ответа уже можно составить впечатление. А потом и загуглить ради интереса =) Каюсь, когда я была на стороне собеседующего, давала рекомендации по найму в 80% случаев именно по ответам на этот вопрос.
Хочешь сделать запрос? Вот тебе request step узел. Хочешь написать скрипт? Вот тебе script узел. Нужны тесты? Пожалуйста — Assertion узел. Ах да, вы ещё можете завернуть все это дело в folder узел.
Аж прослезилась от флэшбэков SoapUI. После которого я всячески избегаю любой UI-тыкательной автоматизации; Insomnia более чем хватает для исследовательского тестирования.
Тем не менее, интересно, как вы решаете (или собираетесь ли решать) проблему обновления исходных файлов описания (aka OpenAPI description docs). В том же SoapUI была возможность обновления WSDL и криво-косо можно было обновить реквесты под текущую схему. Есть ли какой-то похожий механизм у вас? Не обновлять, но хотя бы глянуть дифф.
Вторая часто встречающая задача, это валидации реквестов и респонсов относительно схемы. Умеете из коробки или нужно скриптами выкручиваться?
Мастер-класс "Как первым предложением отбить всякое желание даже пытаться читать".
Я не понимаю, зачем подобное вообще на хабре публиковать. Убедить местное мужское население, что девушки ого-го могут? Попытка так себе, эффективней будет статьи по делу писать. Убедить девушек? Спасибо, мы уже тут. Привлечь новых? Так они хабр не читают!
Сейчас конечно скажут "не нравится — проходите мимо", но задолбало уже. То в линкедине приглашают на "women-only tech meetup", то вот такие интервью, то фейсбук фейспалмит хреново таргетированной рекламой курсов "girls in code". Ну никак вот блин нельзя просто развиваться и становиться уважаемым специалистом, надо обязательно гендером пихать. Я не спорю, что нужно бороться со стремными стереотипами типа "неженское дело" (почему-то забывают про "немужские дела"), но не такими методами же — они вызывают исключительно раздражение.
Для этого обычно элементы делают пропертями.
Я спрашиваю, т.к. из статьи непонятно, как вы развиваете паттерн дальше. Возможны ли в вашем подходе методы, которые будут возвращать PO? Если да, то как решаете проблемы с циклическими импортами?
Мы вообще для PO используем PyPOM, вроде почти довольны, но в целом на джаве этот паттерн с меньшими костылями реализуется.
Не хотелось бы обидеть, но эта реализация напомнила первую картинку из мема про "как рисовать сову". Туториолов этого уровня хватает, а вот как эту самую сову в питоне дорисовать — мало информации.
В том же выше упомянутом курсе на Stepic говорят, что обычно выбирают одну из двух концепций:
1) каждый метод PO возвращает self или другой PO
2) методы ничего не возвращают
Первый способ упрощает автокомплит, но в соединении с аннотациями типов выглядит уродско (все эти импорты посреди модуля).
У вас же в примере используется третий вариант: возвращать элементы. Расскажите, почему?
Наша команда сравнивала pytest и робот параллельно, дабы постепенно перейти с цирка на баш+c#+python+java. И вот как раз по поводу лога, всех сильно удивило, что робот не умеет показывать строку, где тест упал. Ну то есть можно подключить стектрейс руками, но очень странно, что это issue на гитхабе до сих пор висит открытым.
Для расчета покрытия я написал утилиту, которая берет из Swagger список API бэкенда и сопоставляет его с тем, что было протестировано.
Интересно было бы почитать про это. Просто сравнение по вызываемым эндпойнтам или какие-то тонкости?
А какие инструменты вы используете при работе?
Мы попробовали робот чуть меньше года назад и ушли на pytest с чистой совестью. Интеграция с PyCharm через энное место и стабильно крашится, дебажить неудобно.
Никакого противоречения. Активность "я руками потыкал" с разной степенью интеллектуальности проводится абсолютно всеми. Ну кроме тех исключительных товарищей, которые коммитят вслепую.
А по поводу "ручных тестировщиков" можно начать препарацию типа "отдельный специалист-тестировщик" или "тестировщик, который владеет исключительно навыками ручного тестирования". По обоим пониманиям существует интересная позиция, вытекающая из принципов Modern Testing (если кратко, оба варианта — вымирающие, ибо будущее за unified engineering и test coaches). Есть и другие позиции, как писала, споров валом на эту тему))
Ну вот и до хабра дошла эта тема. Правда вопрос-то обычно стоит немножно по-другому.Не "заменит ли автоматизация ручное тестирование", а "заменит ли автоматизация ручных тестировщиков". И если первая формулировка имеет очевидный ответ "нет", то вот вторая рождает мильон споров.
Modern Testing Principles (Alan Page & Brent Jensen)
Все уже давно сформулировано и обсосано со всех сторон, повторяться не вижу смысла. Вкратце, тестирование — да, тестировщики — не факт.
Самоодаптирующийся ИИ думаю высосали из последнего опуса ISTQB, не самый уважаемый ныне источник. А так, почти все известные широкой публике "ИИ" это переучивающиеся локаторы (не спорю, есть другие разработки, но очень нишевые).
У меня проблемы выбора нет: либо английский, либо французский (то бишь — английский =)
Но даже при работе с русскоязычными коллегами мне бы было тяжело писать style guide на русском. Просто потому что пытаешься ориентироваться на опубликованные гайды всяких Адидасов и Заландо, и мозг почти невозможно переключить на режим "а давайте теперь попытаемся это все перевести не птичьим языком".
Сообщество уже эту проблему недавно как раз решило. https://github.com/OAI/OpenAPI-Specification/pull/1977
Spectral, как и все остальное связанное с Phil Sturgeon, это самый сок. Если что, у него есть слак, можно там задавать вопросы по дизайну.
Я по линтерам делала мини-митап у себя в компании, если кому интересно, вот заметки.
В качестве интрументов можно еще добавить Spectral, легко настраивать правила под свои гайдлайны.
Вообще, DX очень клевая область, но важно иметь возможность вести технофашизм и buy-in со стороны менеджмента, потому что люди имеют тенденцию игнорить это все по аналогии с UI (хотя в отличии от UI, пофиксать APIшку гораздо тяжелее).
Эм. Инноваций именно со стороны тестировщиков с гулькин нос. Матаппарат и техники анализа пришли от аналитиков и рисковиков, технические штуки — вещь всеобщая. Остается только философия, которую развивать особенно уже некуда. Бах&Болтон затерли до дыр context-driven и RST, MT по сути уже о пост-тестировании… ну вот ISTQB недавно выдало маловразумиельное видение того, как AI всех спасет (видать, новые сертификаты рисуют).
Новье сейчас приходит со стороны разрабов и девопса. Так что те, кто не вайтишник, а хочет быть в тестировании: не надо питать иллюзий. Ибо для того, чтобы не оставаться кнопкожмакателем, нужно в первую очередь постоянно мониторить и поглащать информацию от НЕтестировщиков.
Я бы добавила, что не ограничивайтесь тестированием вообще. Изучайте разные дисциплины и технологии, тестировщик — это как универсальный дженералист, никогда не знаешь, какой кусок информации понадобится на следующем проекте.
Ну и самое главное, валить как только понимаешь выгорание. Скорее всего не поймешь, нужен какой-то контроль снаружи. Я вот поняла только после вынужденного отпуска, после которого абсолютно не хотелось на работу. И тем не менее, по возвращению отработав еще месяц-два, я опять чуть не осталась.
Да хоть обложись этим тест-дизайном, от выгорания это не поможет. Статья-то вообще про другое. Про культуру. Никому этот тест-дизайн не сдался если "нет фидбека", "работа в стол", "нет команды".
Вот любит наш брат трястись над священной коровой дизайна, когда по факту это (а) ничего уникального и используется теми же БА (в кои автор не хотела переходить), (б) часто далеко не самый важный фактор влияния на качество.
Мы тоже используем этот отчет. Причина такая: аналог (фиговый) аллюр сервера написан уже давно и все тулзы генерят отчеты под него. Переделывать очень трудозатратно (помимо тестов на pytest есть еще большая куча других, большинство самописных). Добавить отображение одной HTMLки в общий отчет на сервере всяко проще чем тащить весь аллюр. Да и по факту говоря, эту HTMLку обычно смотрят ради скриншотов.
Все, свершилось, теперь это просто суперсет https://phil.tech/2019/09/07/update-openapi-json-schema/
Взгляд с той стороны баррикад: в принципе все неплохо и приятно, но хочу предостеречь насчет вопросов про "самые интересные/сложные баги." Не все смогут ответить. Способность восхищаться найденной проблемой — очень зависит от личностных характеристик, проектов, времени. Знаю по себе и другим коллегам, некоторым скорее всего ничего в голову даже не прийдет, хотя на старте карьеры такие примеры бы вспомнились. У меня был период, когда один фейспалмно-обалденный баг сменялся другим почти ежедневно, и в какой-то момент я просто перестала их запоминать надолго как нечто особенное. Некоторые начинают записывать на память, мне лень. Да и вообще, поиск багов для меня — наименее эффективная деятельность по влиянию на качество продукта, больше фрустрации чем пользы.
К вашему списку вопросов я бы добавила банальный про "как развиваетесь?". Т.е. про книжки, конференции, слаки, форумы, вышеупомянутый SO. Вероятно, что не всё, что кандидат ответит, вы знаете\поймете, но по степени "яркости" ответа уже можно составить впечатление. А потом и загуглить ради интереса =) Каюсь, когда я была на стороне собеседующего, давала рекомендации по найму в 80% случаев именно по ответам на этот вопрос.
Аж прослезилась от флэшбэков SoapUI. После которого я всячески избегаю любой UI-тыкательной автоматизации; Insomnia более чем хватает для исследовательского тестирования.
Тем не менее, интересно, как вы решаете (или собираетесь ли решать) проблему обновления исходных файлов описания (aka OpenAPI description docs). В том же SoapUI была возможность обновления WSDL и криво-косо можно было обновить реквесты под текущую схему. Есть ли какой-то похожий механизм у вас? Не обновлять, но хотя бы глянуть дифф.
Вторая часто встречающая задача, это валидации реквестов и респонсов относительно схемы. Умеете из коробки или нужно скриптами выкручиваться?
Мастер-класс "Как первым предложением отбить всякое желание даже пытаться читать".
Я не понимаю, зачем подобное вообще на хабре публиковать. Убедить местное мужское население, что девушки ого-го могут? Попытка так себе, эффективней будет статьи по делу писать. Убедить девушек? Спасибо, мы уже тут. Привлечь новых? Так они хабр не читают!
Сейчас конечно скажут "не нравится — проходите мимо", но задолбало уже. То в линкедине приглашают на "women-only tech meetup", то вот такие интервью, то фейсбук фейспалмит хреново таргетированной рекламой курсов "girls in code". Ну никак вот блин нельзя просто развиваться и становиться уважаемым специалистом, надо обязательно гендером пихать. Я не спорю, что нужно бороться со стремными стереотипами типа "неженское дело" (почему-то забывают про "немужские дела"), но не такими методами же — они вызывают исключительно раздражение.
Для этого обычно элементы делают пропертями.
Я спрашиваю, т.к. из статьи непонятно, как вы развиваете паттерн дальше. Возможны ли в вашем подходе методы, которые будут возвращать PO? Если да, то как решаете проблемы с циклическими импортами?
Мы вообще для PO используем PyPOM, вроде почти довольны, но в целом на джаве этот паттерн с меньшими костылями реализуется.
Не хотелось бы обидеть, но эта реализация напомнила первую картинку из мема про "как рисовать сову". Туториолов этого уровня хватает, а вот как эту самую сову в питоне дорисовать — мало информации.
В том же выше упомянутом курсе на Stepic говорят, что обычно выбирают одну из двух концепций:
1) каждый метод PO возвращает self или другой PO
2) методы ничего не возвращают
Первый способ упрощает автокомплит, но в соединении с аннотациями типов выглядит уродско (все эти импорты посреди модуля).
У вас же в примере используется третий вариант: возвращать элементы. Расскажите, почему?
Наша команда сравнивала pytest и робот параллельно, дабы постепенно перейти с цирка на баш+c#+python+java. И вот как раз по поводу лога, всех сильно удивило, что робот не умеет показывать строку, где тест упал. Ну то есть можно подключить стектрейс руками, но очень странно, что это issue на гитхабе до сих пор висит открытым.
Интересно было бы почитать про это. Просто сравнение по вызываемым эндпойнтам или какие-то тонкости?
А какие инструменты вы используете при работе?
Мы попробовали робот чуть меньше года назад и ушли на pytest с чистой совестью. Интеграция с PyCharm через энное место и стабильно крашится, дебажить неудобно.
А как насчет LibraryThing?
Никакого противоречения. Активность "я руками потыкал" с разной степенью интеллектуальности проводится абсолютно всеми. Ну кроме тех исключительных товарищей, которые коммитят вслепую.
А по поводу "ручных тестировщиков" можно начать препарацию типа "отдельный специалист-тестировщик" или "тестировщик, который владеет исключительно навыками ручного тестирования". По обоим пониманиям существует интересная позиция, вытекающая из принципов Modern Testing (если кратко, оба варианта — вымирающие, ибо будущее за unified engineering и test coaches). Есть и другие позиции, как писала, споров валом на эту тему))
Ну вот и до хабра дошла эта тема. Правда вопрос-то обычно стоит немножно по-другому.Не "заменит ли автоматизация ручное тестирование", а "заменит ли автоматизация ручных тестировщиков". И если первая формулировка имеет очевидный ответ "нет", то вот вторая рождает мильон споров.