After lots of investigation I finally got workaround for the issue, and it seems like bug\issue in SF.
I have trigger that querying dynamically all fields from Quote, it uses other class to get the all fields using describe method. The trigger was failing due to exception: "System.QueryException: No such column 'billingaddress' on entity 'Quote'. " (later also shippingaddress/additionaladdress/quotetoaddress)
Those fields available in soql query from API 30+, while the trigger and class that uses it are API 18.
Currently I added code inside the quote to exclude those fields while constructing the soql.
What is still not clear, is why it happen only when running several tests? I add debug log while running validate process: -If validate only the problematic test it is not failing as the describe method doesn't return the quote *address fields. -If running several tests during validate (while the first test class is API 30+), the describe does return those fields and they causing exception in the problematic test. -If running several tests during validate (but the first test is API 18), the describe method does not return those fields, and it's working.
Can only estimate that due to validate implementation by SF, the class that use the describe run in higher API version, probably as it being used by other test class with higher version. Sounds weird, as any test should run independently, but I cannot find other explanation.
UPDATE I was able to deploy the changes to prod. After deployment I debug the test run, and strangely it's not retrieving the addresses fields from Quote. I found following documentation in SF
When you describe sObjects and their fields from within an Apex class,
custom fields of new field types are returned regardless of the API
version that the class is saved in. If a field type, such as the
geolocation field type, is available only in a recent API version,
components of a geolocation field are returned even if the class is saved
in an earlier API version.
Per this document, I understand that the address fields should be retrieved, regardless the API version used in the class, however I cannot notice this behavior. It was happen only in specific cases. Weird....