some error cases will cover similar code path in playback, we can group them to make sure, we will cover this area of playback.
sanity test should have a list related with specific feature change; sanity test is not ad-hoc testing, right?
low priority UI bugs should not be filed before UI is finalized;
high priority and regression bugs should be filed;
In an interactive-prone application, you should separate the action and status, especially when new feature is added. This is very helpful for you test case design, sanity testing;
before you do a presentation, you need to talk to participants to solve most of the problems. If they support you, then it will be smoothly, otherwise, you may hit the hidden-agenda;
you need declare you are not familiar with specific topic;
not familiar with content and audience are the biggest risk for presentation;
there is no surprise when you are presenting something
verify a hard-repro bug: let dev provide a method to easy hit this issue,then repro it with this method;
if you use a developing test framework, how do you handle the bugs in the test framework, such dependency will block your work! please do not think bugs will never happen.
Why crash is so important? no chance to tell user what have happened?data lose? or something.
No everything need repeating. something can be done and solve all following problems;something can be done to get some experience about similar things and you can just do a little thing to make sure no big change as before you have done;
So you need to know which things need do many times, while some other things need be done only once;
check whether the previous operation have done before you go into next steps;
Log exception may cause serious problems. so, exception when logging should be omitted and should not affect other component;
such as, if the system has some warning or error need to be logged, the detailed information maybe user`s data, these data can cause FormatException since these data are very random.
In Playback, some player is reused,such as when content session end, and another using same player begins; when the recording is restarted. We need make sure before reuse, the status of player has been reset correctly.