Testing a new application can be a challenge and a little bit daunting.
Below are a few useful tips that will hopefully help your testing, should you find yourself having a test an application that you have never used before. (These tips assume that you know about the applications main purpose and that maybe you have seen a demo of it.)
Tip 1 - Talk to the developers
Talking to the developer is a valuable resource of information about the application that you are testing. When talking to the developers you should do the following:
Who's using the system? How are they using it? Now to get this information may require you to speak to a Business analyst or someone who know the end user, but this information can help focus your testing. If you know who is using the system you can use this information to be a little more specific in your testing approach. The same goes for finding out about how users are using the system. For example, if you find out that all of the users never use keyboard shortcuts then testing these would be low on your priority list. You could then focus your testing on using the mouse and keyboard.
Tip 3 - What value is the system adding
By finding out what value the system is adding your testing approach can change to suit this value add. So, for example, if the systems main value add is that it can notify you when cheap flights to Europe are available then you can prioritise your testing around that. Yes you should test when cheap flights to the US are available but making sure the main value add of the application is covered is more important. After all your users probably care more about flights to Europe than ones to the US.
Tip 4 - Raise all bugs
By raising everything you are going to (potentially), learn about the system. Now yes this may be a waste of time (in the short term) but when the developer/BA/Product owner looks at these issues and tells you it is not a bug, they can explain to you why. You will be amazed about how much you can learn about a system when you raise an issue that is not a bug.
Tip 5 - Don't plan too much testing
"If you fail to plan then plan to fail" - A famous (ish) quote that does hold true but not always when you are testing a system that is new to you. If you don't know the system why would you plan your testing? How do you know what to test? What are the key risk areas? You are on a learning curve and as with some things in life just jumping in is the only way to go. Now you could plan things like tours to get familiar with the system, this is fine, but initially don't plan. Just familiarise yourself with the system.
Tip 6 - Create a model of the system
By creating a model of the system (and ideally documenting it) is a great way to aid your understanding of the system you are testing. Now your model may be wrong but you modify it and change it as you gather more information. When you have a model show it to people who know the system very well. They can help correct your model, this in turn will help you identify other testing avenues.
Tip 7 - Look at the bug tracker/Support system
Look at all of the bugs that have been raised. By looking at this you can gain an insight into the types of bugs that gets raised. Knowing the types of bugs that get raised can help you choose which areas you can focus testing on. Are there types of bugs that constantly frustrate the user? Do bugs gets raised that are not usually bugs? Is there a particular developer whose code always seems to have bugs raised against it?
The most important thing about testing a new system is gaining knowledge and trying to gain that knowledge as quickly as possible. In order to do it quickly you need to used
all the resources available - whether they be actual documents, people or something else.
Below are a few useful tips that will hopefully help your testing, should you find yourself having a test an application that you have never used before. (These tips assume that you know about the applications main purpose and that maybe you have seen a demo of it.)
Tip 1 - Talk to the developers
Talking to the developer is a valuable resource of information about the application that you are testing. When talking to the developers you should do the following:
- Find out how the application works
- Developers are going to know better than most about how the application works. They will know things like the following
- What technologies the application is built on
- What is the architecture
- Does the application have any configuration options
- Areas of the code that caused them problems
- Talk through bugs you raise with the developers
- Going through a bug with a developer can give you insight into how the system works and also will allow the developer to explain the behaviour of the system when the bug manifested itself.
- Ask questions
- The developers are the people who wrote the software so they know better than anyone how it works, so......... ask questions. Whether they are about the UI or about how the code behind the scenes works, it doesn't matter. What matters is finding out as much as you can about the application that will help you with your testing.
Who's using the system? How are they using it? Now to get this information may require you to speak to a Business analyst or someone who know the end user, but this information can help focus your testing. If you know who is using the system you can use this information to be a little more specific in your testing approach. The same goes for finding out about how users are using the system. For example, if you find out that all of the users never use keyboard shortcuts then testing these would be low on your priority list. You could then focus your testing on using the mouse and keyboard.
Tip 3 - What value is the system adding
By finding out what value the system is adding your testing approach can change to suit this value add. So, for example, if the systems main value add is that it can notify you when cheap flights to Europe are available then you can prioritise your testing around that. Yes you should test when cheap flights to the US are available but making sure the main value add of the application is covered is more important. After all your users probably care more about flights to Europe than ones to the US.
Tip 4 - Raise all bugs
By raising everything you are going to (potentially), learn about the system. Now yes this may be a waste of time (in the short term) but when the developer/BA/Product owner looks at these issues and tells you it is not a bug, they can explain to you why. You will be amazed about how much you can learn about a system when you raise an issue that is not a bug.
Tip 5 - Don't plan too much testing
"If you fail to plan then plan to fail" - A famous (ish) quote that does hold true but not always when you are testing a system that is new to you. If you don't know the system why would you plan your testing? How do you know what to test? What are the key risk areas? You are on a learning curve and as with some things in life just jumping in is the only way to go. Now you could plan things like tours to get familiar with the system, this is fine, but initially don't plan. Just familiarise yourself with the system.
Tip 6 - Create a model of the system
By creating a model of the system (and ideally documenting it) is a great way to aid your understanding of the system you are testing. Now your model may be wrong but you modify it and change it as you gather more information. When you have a model show it to people who know the system very well. They can help correct your model, this in turn will help you identify other testing avenues.
Tip 7 - Look at the bug tracker/Support system
Look at all of the bugs that have been raised. By looking at this you can gain an insight into the types of bugs that gets raised. Knowing the types of bugs that get raised can help you choose which areas you can focus testing on. Are there types of bugs that constantly frustrate the user? Do bugs gets raised that are not usually bugs? Is there a particular developer whose code always seems to have bugs raised against it?
The most important thing about testing a new system is gaining knowledge and trying to gain that knowledge as quickly as possible. In order to do it quickly you need to used
all the resources available - whether they be actual documents, people or something else.
Comments
Post a Comment