In Business to Business companies, junior test engineers test features. Experienced engineers test solutions.
A soda can’s tab is a feature. Opening the can is a feature. Drinking out of the can is a feature.
Quenching thirst is a solution.
A feature is part of the solution but is not the solution.
A feature is one component. The solution incorporates the feature in context, to solve a problem.
What is that problem?
Let's say your team is testing the scheduling of an email job to run in the early morning, summarizing the overnight automated verifications.
Three test engineers proceeded differently:
One verified the system accepted the scheduling, including the appropriate handling of leap years.
Another, verified the system accepted the scheduling and that for every accepted scheduling an email was sent at the correct time.
The third engineer, verified the system allowed scheduling, the email was sent at the correct time, and the email received adequately informed the recipient on the automated verifications from that overnight run. Also this engineer explored the phrasing in the email when the overnight verification were still running.
Who of the three is testing a feature, who is testing a solution, and who is testing something in-between?
To test the solution, seek the context surrounding the feature.
Ask:
#1 What problem does this feature solve...
#2 ...and for whom?
Take that answer and continue: and to what end would that be helpful... and to whom? Etc.
Thirst is a problem. A can's tab is a feature. Quenching thirst is a solution.
#3 Alternatively, ask "If we don't implement this feature, who (amongst our customers) loses, and what is the nature of their loss?"
Then iterate.
Conclusion
When you tie a feature to the business objective from the customer's perspective, you will be testing, learning, and reporting on the very thing that affects a business' bottom line: solving problems for customers.