- Rule of system level test
- How about our system test environment?
- What miwa's team can get by testing as system level
- We should make our simulator's structure simpler
- We should correlate test cases to development history
- Trying to test by another procedure except planned test case
I have been studying how to do software test effectively these days. When I was searching how to improve my test skills, I found the following blog.
This blog was written by a software tester for medical equipment, miwa.
As she said in this blog, all of programmer in her team is good at testing very well and the main reason is "they test their software as system level for a hour every day."
In addition, she described what the rule of her system test is and what they can learn by testing every day.
I tried thinking how my software team and I can improve our test skills by reading the above blog and wrote memo about it in this article.
Rule of system level test
All of member in miwa's test team use a test PC and test by following "today's recommended test case" per a hour every day. This test PC has a almost real environment and they test the system with the PC same as a customer uses the system. And then, "today's recommended test case" is selected by a recommendation system depending on the current development status.
How about our system test environment?
Our team doesn't have any rules that we test our system as system level test every day. We have a bench simulator system and we use it for confirming the software's behavior. The simulator system sometimes causes a problem because of hardware failure or software version mismatch. It is not easy for us to manage the simulator, so we don't want to touch with it if it's possible.
What miwa's team can get by testing as system level
- They can know a product or function which any other people except them don't develop.
- They can know how a customer uses the system.
- They can feel a real process speed.
- They can know a background process as a system level.
- They can know how is a almost real environment of user data.
- They can see debris of worst case scenario tests.
- They can know development histories.
We should make our simulator's structure simpler
We should make more opportunities to test our system as system level and should like testing it. Why do we dislike testing? The reason is why our test environment is very complex. If we can improve our system test environment and make it simple, we will like using the system more.
We should correlate test cases to development history
When we use our system test environment, sometimes we want to know "Who did use the test environment before me?", "Who is a developer of the function I'm testing now?" "How should the function work correctly depend on specification or design?". In our team, all of source code, specification/design documents and test cases/results documents are manged independently. We need to take some time to get an information about them. It is very bothered... If we can correlate them each other, we will be able to test effectively.
Trying to test by another procedure except planned test case
We usually do only planned test cases, but all of member like testing by another procedure which is not planned. By doing that, they can find a bug more. It is not duty but habit for them.