Have you ever been in an interview where you were asked the question “As a tester, how do you learn a new system?” Was your response “I will read the requirements and or system documentation”? Your response to the question should be: “Is this a new or existing system?”
This distinction is what can make all the difference between marginally knowing and fulling understanding the system. If it’s a new system, you should respond with, “I will ask for all of the requirements and functional specifications available and start reading and creating test cases based on this documentation.” However, if it is an existing system, your best response would be, “If there are no existing artifacts I would go into each page/screen of the system and create a baseline regression test.”
Here, I will try to cover the many ways in which you can learn any system that is “new” to you, with little or no documentation.
First things first
System access: You will need access to the system(s). If there is a website, do you need to have a user id created for you, or can you sign up for one yourself? Depending on the company, you may need to be supplied with a user id and password. If the system is internal and unique to the company, what do you need to access the system, icons, and logins? What other system(s) interact with the one you will be testing? You will need to ensure that any other systems that interact with your system are not affected by changes, so requesting access to all system(s) that link to yours is a must.
Database access: Where is the data kept that is displayed in your system? You will need read/write access to the database and table structure.
Is there a subject matter expert that you can speak to? This can be done while you are learning the system. You should attempt to talk to as many users as possible to understand how each one interacts with the system and what their roles are. I remember speaking to many users about a system I was learning and most of them kept telling me that there was a piece of the system that no one used and that it should be removed. Eventually, I found the one person in the company that did use that function, and as it turned out, it was the only way she could do her job.
Acronyms: Each company has a set of acronyms that they alone use. Having a list of these acronyms can help you quickly understand the company lingo. I always ask if there is an existing list. If the answer is no, I then try to find what I can by doing research and start creating my own list.
Learning the existing system
So, this is an existing system. You now have your access and hopefully a person or two that you can speak to.
You will need to find out if there are any artifacts that you can use as a guideline by asking, “Is there any existing documentation or test cases that I can review to help me learn the system?” Sometimes having no documentation can actually be more beneficial as you do not have to sift through documents that are old and no longer of any relevance. Most of the time there are no requirements that are remotely up to date, or as is the case when I went to work for a company with a home grown system, no documentation of any kind.
Documentation and test cases for a system that is pre-existing could be helpful depending on its age. I have seen test cases created for existing systems that I could not even run. The person that wrote these tests was not a tester, but was a business analyst, who used criteria that only someone that knew the business would know how to execute. These sorts of tests will not help a new person understand the system as they would first need to understand the business rules and processes. You do not want business process tests in your initial regression suite.
The first rule of thumb is to get into the system and click a button to see what happens, otherwise known as “exploratory testing.” These are the sorts of tests that will teach you the system and how it really works. During this “exploratory” testing, you can create your baseline regression test and learn the system at the same time by going down every rabbit hole there is. You might be amazed at how many bugs you uncover.
Database Mapping
Mapping out the system is extremely important from a testing perspective because you need to ensure that you know what fields on your GUI map to which database tables.
Each field in the system should have a corresponding database table column name that you need to locate in order to ensure that the data displayed in the system is valid. I use an Excel spreadsheet to map out each page/screen of my system to the correct table and column. This is helpful information that can be shared with the developers, if needed, as sometimes they need to know where the data is pulling from or where it needs to be saved.
This will help you with testing as you will be able to generate SQL scripts in the database to create, read, update, and delete test data. Verify that tests have passed by looking in the database instead of the GUI. When you have a lot of data to review, the database can be the most efficient way to test.
Business Processes
Make sure that your baseline regression tests to contain no business processes or rules, since these are the tests that can be automated if your project requires automation.
Once you have your regression tests stable, you can add in business process tests that are based on certain data and rules. When you get to this point in the process, you should know enough about the system that adding in the rules and processes should be a piece of cake!
You’re now well on your way to learning the new system. Following these steps will ensure you unlock the proper access, documentation, and processes to enable you to reliably test it.