Interesting topic with a different perspective.
Here is what my little experience with this tab; rearely have to go that tab and look at the properties.
I would think, that is designed and kept there like that after a thought process only.
Here are the use cases for the same and I practice:
1. Usually I do not have to set them manually / edit the values any time.
2. These properties are set automatically by:
a. Groovy Script Test step
b. Script Assertions
c. Setup / Tear Down scripts
3. Rarely use them manually if there are any static values either for case / suite / project level and still being flexible and not hard-coded values.
4. At times, also use property file and load all of them in one go.
So, basic idea, I assume, is for automation & no hard-coded scripts, flexibility.
Would love to hear your use cases.
But... the core of the problem isn't the fact that we use the tab too often (it was created for a reason, right ?). It's that the way we use the UI is not persisted in a flexible way.
In fact this tab is the only place where we can get a quick view access to values stored during tests at different scopes (step, case, suite, project). It's also the only place we can check our environment variables are properly set on the project properties.
We are a team of developers and this tab is more or less equivalent to any debugging interface giving the state of the data. This is why it is of primary importance for our team.
By the way thanks msiadak, I will explore the Properties steps you talked about... but I'm afraid this would be a workaround.
Sbu: You may want to consider raising this as a feature request then. Ready API Feature Request.
