Introduction
The basic intention of every tester would be “To break the code” for which the tester will carry out various types of testing such as Functional, Regression, Performance, Adhoc and End to End testing etc. over the application to find defects. But at the same time, developer of the application also will work with the intention to “Save the code from the Tester and make a bug free application”. Hence the development team nowadays is concentrating more on these aspects and infact they are also carrying out one round of these testing along with Unit testing.
This creates a big challenge to every tester and testers are now looking for new ways of approach of testing to find more defects. Following chapters will discuss one of such new way of approach that would yield good number of defects. No doubt, after release of this document, when development team come to know about this approach, again testers need to look for some other approach, giving room to a never ending learning process in finding newer testing approach.
Normal Approach
In this approach, a tester will design his test cases and test data based on the Requirement Specifications, Use Case documents and other Supplementary specification documents.
He/She will carry out various types of testing such as “System” / “Regression” / “Adhoc” / “End to End’ but all these testing mainly concentrate on the functionalities.
Alternate Approach
Apart from the traditional approach (since it is mandatory to confirm that the application delivers the expected functionalities), a tester have to confirm that the application works as expected on the technical aspects. The technical aspects will vary depending on the technology that the application uses. For eg Technical aspects of Datawarehousing application will vary from a Web application. When a tester puts more efforts on technical aspects, definitely he will discover a lot of defects. For each catchability, we can call this approach as Technical testing. You may like to call it as “Negative testing”
The below some thoughts on technical testing for Web as well as Datawarehousing application since most of the State Street applications currently using either web or Datawarehousing or both technologies.
Technical Testing for Data Warehousing Applications
For Data warehousing application, following technical test scenarios/cases can be tested in addition to the functionality testing. Test cases were written for ETL environment that have Load Driver functionality. Suitable modification can be made to these test cases according to the current test environment considering DWH tool is being used.
|
Test Description
|
Execution Method
|
Expected Result
|
| To check for correct load process status in the load driver table before the load starts. |
Run a query to verify the process status in the load driver table before the load process. |
Load process status of the loaded table should be updated with correct status in load driver table. |
| To check whether load process status in the load driver table is correctly updated at the end of the successful load process. |
Run a query to verify the process status in the load driver table after the load process. |
Load process status of the loaded table should be updated with correct status in load driver table. |
| To check if the number of records extracted from the source is equal to the number of records loaded into the staging table. |
Count records in source using SQL query [for relational sources] or from Unix shell [for files sources.Count records in staging table using SQL query. |
The counts from source and staging table should match. |
| To check the staging table column values match with source column values. |
Run a MINUS SQL query between the source and staging tables in case of relational sources.In case of files sources select 10 sample records from source and staging table and inspect manually. |
The MINUS query should return zero records in case of relational sources.In case of files sources the manually inspected records should match. |
| To check that the specific reference columns in staging table only contain values from the corresponding specific lists. |
Run a query to select count of records from staging table where the values for the particular column are in specified list or range. |
This count should match the total count of records in the table. |
| To check if the values of the Surrogate keys in the staging table are in sequence. |
Run a query to select the values of the surrogate key from the staging table. Manually check that the values are in sequence. |
The values should be in sequence. |
| To validate uniqueness of assumed business keys in the staging table. |
Run a query to select the count of distinct combinations of the columns that constitute the business key from the staging table. |
This count should match the total count of records in the table. |
| To check if the maximum sized field values (full value check) are extracted from the source and loaded into the staging table properly. |
Run query to select 10 sample records from source with maximum sized column values.Run query to select corresponding records from the staging table. |
The records should be identical. |
| To check NULLABLE columns in Target are loaded correctly (Null value Check). |
Before running the mapping, insert a record in the source table with null values for the fields which are not mandatory.
After running the mapping run an SQL query to select the record from the stage table. |
The corresponding fields should have NULL value in the Staging table. |
| To check for correct last update date and time value during Insert in to the tables |
Run a query to select the STG_LAST_UPDATE_DATE_ TIME from staging table for inserted records.
Run a query to select the EXTRACT END DATE TIME from the Load Driver table for the corresponding Function group and Function name. |
The STG_LAST_UPDATE_DATE_TIME for inserted records should be same as LOAD END DATE TIME. |
Technical Testing for Web Applications
For Web Application, following various testing can be carried out (in addition to the functional testing) to find more defects
Test to ensure that links provided in the application, upon selection, is directed
to the correct page.
Test to ensure that navigation among different pages are proper. Also to
ensure navigational buttons (Previous, Next, First, Last etc.) are working
properly
Test to ensure that the application is compatible with various versions of
Operating System, Browsers etc. as mentioned in the installation guide.
Test to find how the application is user friendly. Testing will be concentrated
on Screen Appearances, colour combination, meaningful error messages etc..
Test to ensure the authentication process of the application. Since scope of
testing is very vast (such as hack testing, accessing directly the IP address of
the given URL etc..), we can select few features applicable to the current
testing.
- Other general testing which check for
Test to ensure that when parent window is closed, child window also gets closed. Also to ensure that none of the application page gets displayed when the application itself is closed.
Test to ensure that the web page has the overall weight (may be
between 60 to 70KB – depends on the custom design specifications)
To know the web page weight, right click on the current web
page and select Properties. Page weight going beyond the
recommended range may takes more time in loading the entire page
thereby hindering the performance.
Test to ensure that the application is not timed out before the given time range when no activity was carried out. This time range may be available with the design document or with the development team.
Test to ensure that the content in Dynamic pages are refreshed properly on the specified interval without affecting the performance. Also to ensure that this refresh feature does not affect static pages.
- Auto Refreshing mechanism
Test to ensure that refreshing mechanism (wherever is applicable) is functioning properly on the specified interval without affecting the performance.
