Database testing example

A vast majority of business applications store and retrieve data. Many applications use databases for this purpose, owing to a variety of reasons such as a standard and methodical way of storing information, performance and security. In addition to testing the application software, we should also be testing the database. You can avoid a number of bugs if the database schema used by your application is created correctly. What is more, a correct database schema prevents having to implement a complex logic in your application to handle the different scenarios that can lead to data problems, and consequently application bugs affecting its users. First, view my video, Database testing and SQL tutorial for beginners.

Second, view my video, SQL Queries Tutorial. Now, work with another example below.

Now let us look at a simple database that may be used by a school to store its student information. Since the number of rows and columns is small, we can inspect the data and look for problems manually. Of course, when testing tables with a large number of rows, you need to design and execute SQL queries, but let us not worry about that right now. The intention is to look for database issues, both existing and potential.

Here are the problems with this database:

1. Missing tables

One can see that the Grades (Classes) exist just as a column in the Students table. Grades are really a different entity. This school may have a Grade 3 even if there were no students enrolled in it yet. And this is not apparent from the current data. There should be another table for Grades and each row in the Students table should point to the corresponding Grade via a foreign key.

2. Missing or incorrectly named columns

The Fees table has an ID column. But what ID is this? Is it the Fees ID or the Student ID? If it is the Fees ID, then there is no linkage between the Students and Fees table. If it is the Student ID, it should be named as such to avoid confusion for the developers.

3. ID columns

The Students ID column is has a text datatype. This means that every query reading this column will have to parse the value to rid the leading zero or zeroes. A more severe problem is that text based indexes are slower than numeric indexes leading to slower performance.

4. Dates

One cannot make out the date format from the Date of Joining column values. It could be mm/dd/yyyy or dd/mm/yyyy. This means that every query on the Date of Joining column has to know the date format before it can parse and process the value.

These are not the only problems with the data presented. There are more. Can you spot them?

I hope that this analysis would have piqued your interest in database testing and you would show this interest in your own software testing.

How to write a resume that is selected?

If you are looking to change your job in software testing, the first challenge facing you is to write an effective resume. That is, a resume that would get short-listed. In this post, I will share with you tips that will increase your resume's success rate. I have divided these tips among three sections - Preparation, Execution and Post-Execution.

Preparation

Going by the number and frequency of new job postings on popular job sites, you may have too many choices. However, you should not start chasing all. There isn't enough time to do so. You need to realize that the recruitment activity is a process with the following steps. The next step is taken only if the prior step is successful.

a. Sharing details of the job and the candidate

b. Review of these details

c. Interview

d. Verification and decision-making

e. Joining

Take the time to visualize your ideal job. Use the following questions to clarify your thoughts and be as realistic as you can.

a. What role would you like to play?

b. What kind of organization (small or large, product-based or service-based or hybrid, conservative or modern and so on) would you like to work with?

c. What location(s) would you prefer?

d. What kind of salary you would like to draw?

e. What working conditions (shifts/ hours, organization culture, benefits and working culture) do you prefer?

Once you have a good handle on the kind of job you would like to have, it is time to move to Execution.

Execution

By Execution, I mean the actual task of writing the resume that would be selected. Let us say that you have come to know about a job vacancy that is similar to the job that you are looking (see the Preparation phase above). Now, you should take the following steps:

a. If the job posting is in writing, read it carefully. If you received a call, jot down notes from that call. Note down each keywords in the job posting. Keywords are the essence of the job posting. For example, if you are looking to be a Software Test Engineer, the job post may contain keywords like "Test Plan", "Bug Reports", "QC processes" and so on.

b. The next step is to gather more information about this job. There are several ways to do this.

  1. Browse the organization's website. If you read the relevant sections, you will have a better idea of the work they do and the vocabulary they use. Add more keywords to your existing list.

  2. If you know someone working in the organization, give him or her a call.

  3. Talk to the poster. They may just highlight the main points of the profile they are looking or provide extra information. Let the poster know that you are interested in the job and would be sending them your resume.

c. By now, you should have a very good idea of the job. It is time to go through your list of keywords and ensure that the keywords applicable to you are included in your generic resume. Adding a keyword once may not be sufficient. For example, if "Automated Testing" is a keyword and you have experience in automated testing, you may include it in the following ways:

  1. In the summary section, mention Performed Automated Testing in XYZ project

  2. In the Tools section, include the automated testing tools e.g. QTP, WinRunner that you worked with

  3. In the project responsibilities in XYZ project, mention Created automated test scripts

d. Review the major sections of your resume and ensure that they are structured. The Summary section, the Organization/ Projects section and Qualification sections should be clearly separated. Follow a uniform order within each section e.g. list the organizations you have worked with in reverse chronological order and do the same for your qualifications.

e. Make sure that your resume is current. If should include your latest organization/ projects.

f. Ensure that you have provided all relevant information within each section. For example, if the job posting mentions Bachelor's degree in Engineering as a requirement, you may want to include details like College/ University/Year of Passing/ Grade if you are comfortable and it is legally acceptable to share this information.

g. If your resume does not already mention your achievements (awards/ recommendations/ recognition) during work or college, ensure that it does so now.

h. Review the job posting and your list of keywords again and read your resume. Expand the relevant phrases and sentences. Do not highlight the keywords by making them bold (this looks desperate). Reduce or summarize the non-relevant phrases and sentences.

i. After final review of your resume, you should be ready to send it to the job poster.

Post-Execution

If you get the call to schedule an interview, congratulations. If not, wait for 2 or 3 business days and call the job poster. Maybe they received too many resumes and did not go through your resume (carefully). You should the reasons due to which you are suitable for this job. Use your list of keywords to your advantage. Follow up is very useful in securing an interview if your resume is not selected automatically. If your resume is not selected even after follow-up, it is likely due to some information not shared in the job posting e.g. the organization wanted only candidates experienced in a particular industry domain. Ensure that you ask questions to unearth such information in future.

If you have made the effort to understand the job well, presented your resume in line with the organization's expectations and/or followed-up, chances are high that your resume would get short-listed and you would get a call to schedule an interview. The next challenge is to be selected in the interview. Watch this space for tips on that topic.

Planning and execution problem solved

I like doings my testing tasks really well. In fact, I prefer not starting a task to doing it in a sloppy way. Now, this created a problem whenever I was working on a project. There were many tasks to perform every day. In the past, it used to take a lot out of me in taking the actions related to my task. First, I used to understand the task and then estimate its priority (to schedule it accordingly). Then, I planned the approach to perform my task and identified each sub-task that required to be done. I performed each sub-task and tracked my progress frequently. After completing each sub-task, I reviewed it. Then, I reviewed the entire original task first with respect to each sub-task and then with respect to the original objectives. Finally, I communicated my task completion to the relevant people.

Why did I end up expending a huge mental and physical effort in performing each task? Other than my desire to really shine at the task, I found that I repeated a lot of planning that I had done in the past on similar tasks. Attempting to excel at my task is welcome. It gives me the satisfaction that I am not doing the task mechanically. However, re-thinking everything is definitely overkill. Not required in a majority of tasks. Definitely not desirable in every iteration of the task.

I needed to solve this problem. That is, I had to balance my wish to do really well with my need for speedy execution. Here is how I created my solution to this problem. First, I identified a couple of non-trivial tasks that I had to repeat. In my case, I selected 1) Review of test cases and 2) Creation of the monthly test results. Later on, I realized that this solution can be applied to any other repeated non-trivial tasks such as 1) Design test cases, 2) Execute test cases and 3) Log bug reports. Second, I made available to myself an ample time slot when I would work on nothing else but this selected task. Third, I started working on the task. But there was an important difference to the prior executions this time. I documented my approach making notes as I went along the task. For example, starting the test cases review, I listed each item that I had to plan e.g.Whether to do a high-level or detailed review or a hybrid review, Sequence in which to review the test cases, Level of detail in my review comments. While actually performing the reviews, I listed each sub-task as I remembered it e.g. Check if each requirement in scope of the test case is covered, Check if each design is covered in the test case, Check if there is an incompleteness in steps or expected results or test data, Check for duplicity within a test case or among two or more test cases.

Finally, I ended up with a nice long list of sub-tasks (with comments) that I needed to perform to do justice to my original task. Some sub-tasks were linked to the understanding of the task, some to the planning, several to the execution and the others to the own review. Now, every time I faced this task, I did not go about it in my earlier way. I got my list out, looked at the list of sub-tasks and started executing them. Whenever I remembered a missing sub-task, I just inserted it in the appropriate place in the list. This practical list was really my own task execution procedure.

How does this help you? If you are like me and want to perform due diligence on your important tasks, your own procedure will help you do just that. You will no longer need to rely on your memory alone. The second benefit is that it will reduce the planning effort required. You will just look at each sub-task in your procedure, decide if it is relevant to the current situation and if so, perform it. The third benefit is that your procedure will keep you focused and on track. If you enhance your procedure with every iteration of your task, you get the fourth benefit, which is improving execution ability. You will get the fifth benefit when you share your procedure with your team members. Your team members will improve their execution ability by benefitting from your procedure. In turn, they are likely to give you feedback that will help you enhance your procedure even more. Your procedure will also be a good means to transfer execution knowledge to new team members.

If you are excited about creating your own procedures in order to excel at tasks, you should take a few pre-cautions:

1. Do not get over-ambitious and try to create procedures for every task that you perform. If you do, your work will slow down to a crawl and you may be overwhelmed quickly.

2. Choose to write the procedures for only regular AND non-trivial tasks. Do not spend hours writing a procedure for a task that you will perform once in six months (and the project situation may be quite different at that time). Do not write a procedure with obvious steps e.g. you know that you have to fill up each relevant field in the bug report form before you submit a bug report.

3. Once you have a procedure ready, do not delete a sub-task even if you find that it is not required in the current task iteration. This sub-task may very well turn out to be important in a subsequent iteration.

If you work with a process-oriented organization, you will find that documented procedures are available for only the major software testing tasks. In other organizations, you will find that you only have high-level industry guidelines and standards to follow. In both cases, you will find your own procedures very helpful. How else do you think high performers are able to produce substantial results in half the time that you take?