Зависит от многих факторов: способа организации фреймворка, типа тестов, логической составляющей и т.п. Тут нет однозначного ответа - что лучше.
Вы можете объединить тесты в пакеты по логической составляющей. К примеру, пакет авторизации, в котором будут классы на тестирование логина, логаута, негативные тесты и т.п. Причем классы будут называться по типу LoginTest, LogoutTest и т.п., а пакет - Authorization. В целом, при таком подходе некоторые тесты можно как объединить в 1 класс, так и оставить строгое разбиение 1:1. Т.е. по сути, такой вариант будет являться отражением вашего чеклиста. Открыв тесты, вы будете видеть, к какому логическому блоку функционала они относятся, сможете определить покрытие, проблемные области и т.п.
Либо вы можете создать пакеты с объектной привязкой. По типу UserOperations, а внутри 1 класс, содержащий в себе все манипуляции с юзерами - создание, редактирование, удаление.
Можно вообще запихнуть все классы в 1 пакет tests и идентифицировать функционал по имени класса, но при разрастании тестов сложно будет все это дело поддерживать.
В зависимости от выбора того или иного подхода возникает вопрос в типе запуска - как вы хотите, чтобы testng запускал тесты? По классам, по методам и т.п., при этом, сохраняя независимость самих тестов друг от друга.
В общем случае я бы рекомендовал использование первого варианта. Но тут еще есть нюанс в подходе к самому тестированию. Если ваши тесты строго ориентированы на проверку конкретных объектов с ограниченным набором функционала, и вы точно знаете, что ничего более вы проверять не собираетесь в будущем, то второй вариант будет выглядеть логичней.
Исходя из того, что полная картина нам не видна, то выбор нужного подхода, как говорится, - It's up to you.