I know some of you wonder "how exactly do we test Solid Edge" and I came across this note today from my testing manager to her team on some "best practice" items when doing manual testing (obviously automatic testing is a different beast).
I thought you might find it interesting how we attempt to unearth issues before you find them -- and we are also interested in your constructive suggestions (besides "test everything") of one-liners we could add to this list to catch something important...
I think the "best tester" is the user.
For me the function and feature consistency is very important. The same feature should work on the same way in all environments.
Some bugs can be depend on language...
There are at least 4 ways of doing everything (hot key, menu, right click, left click ect.). Test all of them.
Look at the dialogues and tips. Do they really tell you what to do if you have never done it before and don't know what it does?
What happen when something is wrong? For example you have to zoom out, activate, rotate the view, turn hide or show something, or go back a step and change the selection.
Test existing commands in a new version on older parts known to be having critical areas where a command has failed earlier or was not working as desired.
With the API, first check the What's New list to see if the desired method/property has been added and replace your existing code to see if it does a better job than the workaround you wrote.
My suggestion is to do test with files that reside not locally but on a server.
When I use Solid Edge with local files it fly as a F1 car, when I use it on network it became much slower. I think programmer should think to access files data only when really needed.
@Tushar FYI, we have literally HUNDREDS OF THOUSANDS of customer files we test against. We have automated tests of part recompute, and drawing view update and other such stuff. I'd bet in total we are approaching a million customer files in our DB.
I have been working with Solid Edge since pre-ST times and have noticed a lot of problems when it comes to hatching/fill patterns in the draft environment, particularly with assembly drawing views. I get a lot of instances where hatching overlaps parts when it shouldn't and instances where hatching disappears when converting a view from 3D to 2D. I don't particularly know how this would be implemented into the testing of new programs, but since these problems have been carried over from version to version, it would be nice to have some focus devoted to this area of the draft environment. Adding hatching with draw-in-view and removing hatching in the part properties can be very time consuming and down right annoying with large assemblies haha. Just my thoughts.
My way of working does not tend to be covered.
1. Im using planes to control theoriedical box's
2. The box's control sheet metal sides of box's
3. Everything updates automatically from moving a single plane.
Trying making whatever you work in re-sizable.
@Dan, that's an astronomical number by any standard and only reflects the trust that users show with Siemens by sharing their proprietory data for testing - this sure must be helping both users and the testing team make Solid Edge even robust and stable.
@ImiI have been a programmer almost all my career and also was obligated to double up as a tester. The developer is the one who knows well in advance where his algorithm will fail if he tries to see beyond the specifications provided. Of course, as you mentioned the user is the ultimate tester who will put the given functionality to acid test.
@Dan, do you have such style of testing internally within Siemens development where the coder also tests his own work. I have little or no visibility on this, hence my earlier remarks which perhaps sounded novice.
Some day I would like to be a beta or alpha tester for Solid Edge.
I think the most effective testing would be having testers that are Experienced Engineers, Designers, Drafters, etc. They are going to do things the way they have for years, and if it is not easy to do, or doesn't make sense the way it is programed, they can provide the input to correct the issue.
Problem: I created a text field today using "Text" in a draft. In that note, I wanted to add a special character such as the degree symbol "°". In all other programs I have used in the past 15 years, I would select the symbol, then select "OK" and it would insert it. Today I had to select the character, then select copy, then use ctrl=V (to paste, at which time it comes in at a different scale than the text in the text field I just created and must be edited). That is more steps than an average user wants to make.
Fix: I would relay that info to a programer, who would then say ..."of course they want to insert that special character, why else would they have selected that option" His solution would then be "how about if they select the character they want to insert, then they pick "OK" or "Done" and it then inserts that character (or characters), at the same pitch as the rest of the text in the field."
Those are the types of issues that a person using it as their job might come across, vs. what a programer may think of trying during a test.
I hope these types of anwers will help in enhancing the product, and reducing bugs.