Documenting 3scale-adapter pod quick check should be a must but not a sufficient condition to check the integration.

Configuring a service and perform requests to it while checking for activity in the mixer and 3scale-adapter logs is important and could be documented here if you said it add very little things to the documentation.

Regarding troubleshooting section, it could be a nice to have in case of unsuccessful smoke tests. This guidelines you mentionned are more pertinent for me
????

Forgot to label the service workloads with the service-mesh.3scale.net/credentials key.
Forgot to label the service workloads with service-mesh.3scale.net/service-id when using handlers that don't contain a service_id so they are reusable per account.
The Rule custom resource points to the wrong handler or instance custom resources or the references lack the corresponding namespace suffix.
The Rule custom resource match section can't possibly match the service you are configuring, or it points to a destination workload that is not currently running or existing.
Wrong access token or URL for 3scale's admin portal in the handler.
The Instance custom resource's params/subject/properties section fails to list the right parameters for app_id, app_key or client_id, either because they specify the wrong location (ie. query param vs headers vs auth claims) or the parameter names do not match the requests used for testing.
Trying and failing to use the configuration generator without realizing that it actually lives in the adapter container image and needs oc exec to invoke it.
????
YAML edition/update issues are more general issues we can have in OpenShift so it does not make sense to document these YAML editiion related issues here.