June 22, 2015 // By Michelle Miller
This is part 3 of a 3-part series. You can read part 1, “What is Tested,” here and part 2, “How is it Tested,” here.
Data is the most valuable asset of most business applications. Serious issues can arise if the data is overlooked during the development of the application. There are many methods and types of database testing that can be performed on a project, but which ones are the best depends entirely on the project’s deliverables and the resources available which is a topic in and of itself. But there are some factors that can be applied to any project to ensure success.
We must identify the right resources for the tasks required. Testing activities are not necessarily owned by testing resources. Depending on the skills and expertise required for a task and where those skills reside on the team, influences who performs those tasks. Due to the nature of database testing, many of the more technical tasks are done in unit testing by developers. Reviews may include Business analysts or other Subject Matter Experts (SME). Who performs the testing tasks, isn’t as important as the fact that the tests are done, and appropriate checkpoints capture their state of progress.
Reduce redundancy to increase velocity. With so much that can be covered in testing, schedules do not often align, and prioritization occurs. It is important to be aware of what tasks are taking place and when, so that they aren’t repeated unnecessarily in other areas. For instance, if functional testing of the user interface will exercise most of the stored procs and triggers and must be done to test the UI functionality– it may not be a good return on investment to create stubs for execution of all stored procs. Conversely, however, the creation of those stubs may be the first step in automating a regression, which could allow for less future UI regression testing of all code paths.
Re-use what you have to save time. Often, tools and scripts are created to simplify a process that is thought to be a one-time only thing. More often than not, these are useful for testing as well, and testing resources should be included in the development of those tasks to provide input.
Automate where you can. There are opportunities for automation at every step of database testing. Environment initialization, data seeding, procedure or trigger invocations, database comparisons, results analysis, results reporting – all can benefit from automation. This could be a full-out automation of the entire process or selecting areas which provide the highest return of investment; utilizing or customizing something that may already exist. The opportunities are present, but the project’s needs and constraints will drive what should be done.
Communication is vital. Visibility within the project’s team pertaining to the activities that are being performed, proper reporting of the project’s progress, and issues that arise within the project, are all key factors in ensuring success.
Keeping these factors in mind as you are putting together your testing strategies and project implantation plans, will help your team identify and prioritize deliverables related to the nuances of database testing. This will also increase confidence in test coverage and reduce time spent in testing and rework.
To contact us directly, email us or call us at 877-277-1044.