LO1: Prepare for test

Introduction

Testing is a process of executing or validating and verifying that a software program or application or
product meets the business and technical requirements that guided its design and development.

Testing allows developers to deliver software that meets expectations, prevents unexpected results, and
improves the long term maintenance of the application.

Reason & Importance of Testing

It is very important to have decent quality software’s /project. Having this means the quality should
match many requirements. Testing is one of the most important parts in quality assurance especially in
the development stages. As the development of the program comes to an end it becomes harder to fix
errors, in fact becomes harder to spot errors. This would mean, perhaps, to check each section during the
development so that the errors can be spotted and fixed before progressing to the next stages.

Testing should be done during the development stages and if it is not done during the development
stages then it is more than likely that there will be a lot of bugs and errors. Some problems which may
not have been seen during the development stages, without testing at the end, could be something like a
function being used whilst the stack is empty. This could lead to a system crashing. However, if testing
is done this could be spotted before proceeding to the next stage.

Humans are prone to make mistakes and so if they do everything then it may not be as efficient. Some
code may be missed out with humans and so this could cause errors in the system.
Test Environment
Once a database has been designed, it is implemented, & made available to the end user. Three vital
environments exist for a database that has been designed.
 Development environment
 Test environment
 Production environment
After the database has been fully designed and created in the development environment, it is time to
migrate all development structures into the test environment. During testing, the database and database
application interface are tested for overall functionality and accuracy. The database should also be tested
for performance, especially if it was a key concern to the customer when the system requirements were
established.
After all database structures have been created in the test environment, test data must be loaded into the
database to simulate the use of the database application in production. The data used during the test
might be a percentage of the data that will actually be used in production, or might consist of a duplicate
copy of production data. It is important to work with real data while testing to ensure that the database
acts as expected, and that all modules of the end-user application function properly.
It is important to expose and correct system problems before the customer or end user has a chance to do
so. If it is determined that corrections must be made, they are made in the development environment
before being applied to the test environment. No changes are to be made directly to the test environment
without first existing in the development environment. It is usually better to spend more time testing,
making changes in development, and then testing again, than to give the end user a system that does not
function as promised.
To conduct the test; you should have to prepare evaluation checklist which enables you to determine the
modules or parts of database and application that has to be tested. For example:
• Duration of time required to test the system. (How much?)
• Is that the database designed according to predefined business rule?
• is that the database application interface perform?
• is that the test data is real data?
• What is the volume of test data? , Etc.
Database Life Cycle
The database life cycle starts with a requirement to have information available for the operation of a
business.
Various methodologies might be used when designing a relational database. A design methodology is
the thought-process and steps taken during the design of a database system. Methodologies that are used
during database design are driven mainly by the knowledge and experience of developers, as well as
automated design (AD) products that are available.
The actual design of a database system (system development process) involves several steps. The steps
involved will vary depending on the methodology used.
Test plan

Test plan is a document that lists all the activities in a QA project, schedules them, defines the scope of
the project, roles & responsibilities, risks, entry & exit criteria, test objective and anything else that you
can think of.

This is also a deliverable and also a document at that. Test strategy outlines the testing approach and
everything else that surrounds it. It is different from the test plan, in the sense that a Test strategy is only
a sub set of the test plan. It is a hard core test document that is to an extent generic and static. There is
also an argument about at what levels test strategy or plan is used- but I really do not see any discerning
difference.

Example: Test plan gives the information of who is going to test at what time. For example: Module 1
is going to be tested by “X tester”. If tester Y replaces X for some reason, the test plan has to be
updated.

On the contrary, test strategy is going to have details like – “Individual modules are to be tested by test
team members. “ In this case, it does not matter who is testing it- so it’s generic and the change in the
team member does not have to be updated, keeping it static.

Test Tools
Modules

Unit testing is a software testing method by which individual units of source code, sets of one or more
computer program modules together with associated control data, usage procedures, and operating
procedures, are tested to determine whether they are fit for use. It is the smallest testable part of an
application. In object-oriented programming, a unit is often an entire interface, such as a class, but could
be an individual method. Unit tests are short code fragments created by programmers or occasionally by
white box testers during the development process. It forms the basis for component testing. The goal of
unit testing is to isolate each part of the program and show that the individual parts are correct

Unit tests are typically written and run by software developers to ensure that code meets its design and
behaves as intended.

Logs and result sheets

Test Schedule
 Test scripts

A set of instruction (code) that will be performed on the system under test to test that the system
functions as designed (expected). Test script will be performed on the system under test to test that the
system functions as expected. It can be executed either by using manual testing or automated testing. A

Manual testing. These are more commonly called test cases.

Automated testing

Short program written in a programming language used to test part of the functionality of a software
system. Automated testing is advantageous for a number of reasons: tests may be executed continuously
without the need for human intervention, they are easily repeatable, and often faster. Automated tests are
useful in situations where the test is to be executed several times, for example as part of regression
testing.

Disadvantages of automated testing are that automated tests can like any piece of software be poorly
written or simply break during playback. They also can only examine what they have been programmed
to examine. Since most systems are designed with human interaction in mind, it is good practice that a
human tests the system at some point.

Review results against acceptance criteria

Who conducts testing?
LO2: Conduct test
After test data has be loaded into the database to simulate the use of the database and database
application in production database; the designed database can be tested by different teams that have been
good understanding of business and data. Most of the time; a team of end users and development team
might be designated to conduct the test because they are the individuals who understand the business
and data the best.
During testing, scenarios and checklists that were established pre-test and all aspects of the system are
tested accordingly. The scenarios focus on the usability, accuracy, and performance of the database. The
following test evaluation checklist might help to determine if a database and application has been
properly tested:
 How much time has been allocated to test the system and was it enough for tests?
 Do any data relationships need to be modified?
 Are business rules being followed?
 How did the database application interface perform?
 Was the system tested with real data?
 Was the system tested with a realistic volume of data?
 Was data integrity compromised during testing?
 Were all changes tested thoroughly?
 Was the database queried after changes were made to data using the application interface (using
a combination of the application and manual transactions and queries to ensure that the
application is working properly)?
 Have all requirements for the system been checked for completeness?
 When is the system expected in production?
 Was the tests conducted according to test scripts?
 Have the design satisfies the required quality benchmarks?

Acceptance testing
Actual results to expected results are compared on completion of each system unit, and completed result
sheets.
The final level, Acceptance testing or User Acceptance Testing, is conducted to determine whether the
system is ready for release. During this final phase, the user will test the system to find out whether the
application meets their business’ needs. Once this process has been completed and the software has
passed, the program will then be delivered to production. Normally this type of testing is done to verify
if system meets the customer specified requirements. User or customers do this testing to determine
whether to accept or reject the application.
If testing runs smoothly and the end users (testers) are satisfied that the test was successful; then full
steam ahead to production.

Production Environment
Production is the point at which the database and application are made available to the end user. Real
tasks are accomplished in the production environment that directly affects the way the business operates.
Real users are working with real data, and interfacing with real customers.
Now is not the time for the company to be embarrassed when it finds that the customer cannot be
properly served. Now is the time to impress the customer with a system that works well and enhances
the company’s relationship with the customer by making life easier for all parties during real-world
business transactions.
Although the production environment is considered to be the finished product, it is still subject to
changes and improvements. Few systems, if any, are ever implemented into perfection in round one.
Few systems ever actually see perfection. There is a difference between a perfect system and making the
customer think you have a perfect system. It is a great practice to routinely search for ways to improve
the new system because room for improvement inevitably exists.
The following production evaluation checklist might assist in the evaluation of a recent implementation,
as well as the decision to make modifications in attempt to improve the system:
 Were there any errors during implementation?
 Does the end user have any complaints?
 How does the system seem to perform?
 Was all live data loaded or converted successfully?
 What is the average number of concurrent users?
 Are any areas for immediate improvement in database functionality or performance recognized?
 Are any areas for immediate improvement in application functionality or performance
recognized?