Опенсорсного софта мало, который можно потестить на публику? Если уж у кого-то находится время его пилить, должны же хоть изредка появляться люди, которые его тестят? :)

Чтобы потестить оупен морс надо знать как его локально установить и запустить. Во многих проектах это не простая задача.

Скажем так не для мануального тестировщика. Нужны скиллы.

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

Плюс для контрибьюта чего-то, кроме опечаток в документации, надо с проектом разобраться.

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

Ну вот пример практически полезного чеклиста я приводил выше. Можно спорить с его корректностью и полнотой, но в целом идея годная. Можно было бы похожие документы для тестов на  REST или GraphQL накатать.  Протоколов всяких и стеков очень много, чтобы нормальное покрытие сделать - нужна экспертиза, прям на уровне разработчика софта знать как парсятся данные на выходе, выходе, подводные камни всякие. И если в таком ключе рассматривать документацию, то даже тестирование относительного простого вебсервиса на пару десятков эндпойнтов могло бы вырасти серьезный проект с поддержкой комьюнити.

Ты как-то мануального тестировщика на уровень обычного пользователя опустил. Все же спикеры конференций по 8-10 лет тестируют, неужели не научились за это время?

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

>Так этих чеклистов по рестам и графкуэлям итак в интернетах как г-на за баней

Поделитись примером, хотя бы парочку? Сходу только от кулхацкеров что-то гуглится.

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

Ну то есть тестим хеллоуворлд? :) Если это действительно уровень продакшена, то как-то несерьезно. Мне лично ничего стоящего не попадалось.

Тестировать не равно разбираться в куче языков программирования)

Не понял, откуда такой вывод?
По идее - для тестирования апи нужно 1) знание как работает апи (это как раз рассказывается в видосах и статьях) 2) общая теория тестирования.
Потому что все те же пограничные значения, классы эквивалентности, пайрвайз и прочая прочая - это так же применимо к апи, как ко всему остальному. Генерируем тесткейсы, реализуем в виде апи тестов.
Вот и всё.
И чтобы понять, что человек сможет это сделать - это позадавать вопросов минут 15 (если у него знания хороши, если плавает, то больше, чтобы определить уровень), а читать составленные им чеклисты по какой-то опенсорс тулзе - это оверкилл. На такое просто не захочется тратить время.

Я видел и собеседоаал людей, которые тестили по 12 лет игры в EA, и вообще не шарили код. Им кидали билд и они играли.

И, опять же, повторюсь - это не только в тестировании так. Я бы сказал, что очень мало где можно просто предъявить результаты своих трудов и этого было бы достаточно. Везде собеседования в том или ином виде.

Чтобы увидеть граничные случаи  неплохо бы знать как работают, к примеру, парсеры. Иначе часть кейсов будет пропущено. Нужно учитывать стек, на котором работает бэк. Для питона это будет один набор тестов, для плюсов - другой.  Можно учитывать всякие конвертации типов данных, потенциальные баги при сериализации-десериализации.  Много всякого может вылезти, что потенциально сказывается на стабильности и безопасности системы. Если тестировать на уровне "один позитивный кейс, один негативный, имя не может быть пустым символом" - ну далеко не везде прокатит.

С одной стороны согласен, с другой стороны опять же - оверкилл. Ибо тогда надо знать особенности всех языков и технологий, на которых может быть написан сервис, а это как-то звучит жестковато. К тому же вот например написал ты тесты на пограничные значения, в одном тесте грубо говоря отправил нолик, вдругом единичку - увидел, что фактический ответ и ожидаемый ответ не сходятся, сходил к разработчику и узнал о специфике конкретно вашего парсера.

И чем отличается на входе в бек стандартный примитив sint_64 для питона или крестов? 🤔

Доброй ночи. Вопрос по Selenium + python. Как можно скопировать текст с адресной строки браузера?