Friday, September 23, 2016

Checklist for Database testing


I prepared this awesome checklist that you can use when testing any software that contains a database, just take what you need and add your own ideas if necessary. 

תוצאת תמונה עבור ‪best quotes about computers‬‏

Why using a checklist for testing?

  • In my opinion, there are a few major benefits that you achieve when using checklists:
  • Checklists can ensure that all the client requirements will be covered in the testing process.
  • Checklists can ensure that the software is tested with the needed coverage.
  • Checklists can reduce the tester “Forgetting” errors.
  • Checklists can help to ensure the testing accuracy.
  • Checklists can help to see the testing coverage.
  • Checklists can help to see the testing progress.
  • Checklists can increase the coordination between different teams that involved in the testing process.

Checklist for Database testing

Database testing is used to test the main aspects of the integration between our tested software and the chosen database platform (SQL, Oracle Etc.). The main aspects that we want to validate are:

  • Synchronization between the database and the values displayed in our client/web.
  • Query results, views, stored procedures, indexers Etc.
  • Data manipulation (Update, Delete, insert Etc.).
  • Database performance.
  • Data maintenance.
  • Table’s structure.
  • Data recovery.
  • Data integrity.
  • Etc.

I selected few criteria for tests, every criteria contain few examples that may help you to perform a better database testing.


Database system-level tests

  • Validate the DB behavior of any case of service failures (recovery, error handling Etc.).
  • Validate that all indexes are created when it can increase the system performance.
  • Validate that appropriate events are created ad sent to the EventVwr/trace log.
  • Validate that DB tables are created with informative and reasonable names.
  • Try to work when the storage is ‘0’ and the e database is in running state.
  • Perform your tests on different versions (SQL 2005, 2008, 2012 etc.).
  • Validate the software security model (User roles, permissions etc.).
  • Validate the connection strings against SQL/Win authentications.
  • Validate data migrations (Different Database, Cluster, etc.).
  • Validate the behavior of the system against SQL injections.
  • Validate date to DB when the server is loaded.
  • Try to work when the database server is down.
  • Try to work with difference instance.
  • Validate restore and backup plans.


Data integrity tests

  • Check that all columns are set with the relevant data type (Bigint, int, string Etc.)
  • Check that all data is logically organized in the relevant DB tables.
  • Check that each data item is located under the relevant column.
  • Is there any irrelevant data in the software dedicated tables?
  • Check that each table contains the relevant data.
  • Try to insert invalid database values.
  • Verify the data encryption (if any).


Data field tests

  • Validate that “Allow Null” condition is not allowed in a place that result a software failure.
  • Validate that all tables are created with logical structure (Primary, foreign keys.)
  • Validate that “Allow Null” condition is set when you need to allow it.
  • Validate that mandatory fields are created, this issue is very important when you work with multiple tables that depends on each other.

Procedures tests

  • Validate that the data the affected by the procedure is changed as expected.
  • Validate that all procedures are triggered when they supposed to run.
  • Validate that all the conditions receive an appropriate date inputs.
  • Validate that all procedures are created with the relevant code.
  • Is there an appropriate error handling for a failed procedure?
  • Validate that all the loops receive an appropriate date inputs.
  • Validate the procedure's parameters (types, names, etc.).
  • Test the SP while executing the code manually.
  • Validate important code with SQL profiler.
  • Validate that all procedures names
  • Run tests with missing parameters.

Database and software integration (Client, web Etc.)

  • Validate that the user data is saved when the user “Apply” or “Submit” the changes.
  • Try to insert “NULL” values on fields that doesn’t supposed to receive it.
  • Validate that the user receives the current result when pulling data.
  • Validate that transaction the data type boundaries (Minima Etc.)
  • Validate that empty spaces are not committed to the database.
  • Validate that the values displayed based on the database data.
  • Try to insert UNICODE on Unicode character strings.
  • Try to insert values that exceed the field boundaries.
  • Validate that transactions the negative data values.
  • Insert invalid date format on Date and time fields.
  • Validate that the data integrity is not affected when the “Apply” or “Submit transactions are failing during the process.
  • Validate that the “Roll Back” option is available when the DB transaction is failed in the middle.

Risk Analysis (RA) in software Testing | David Tzemach


Risk analysis is the second phase in a “Risk Management” process, in Risk Analysis we will determine the level of risk that involved in different aspects of both the software and the project, The analysis is made on the identified risks that were described in the first step of RM (Risk Identification).

In the Risk Analysis process, we will need to review each identified risk in the software and prioritizing them in a way that the testing teams will test and remove the most critical risks first.

Risk Analysis techniques

  1. Compare the Risk against the requirements and specification of the tested software, and determine how the risk is affecting them.
  2. Consulting with the technical experts that can tell the technical effort that is needed to remove the risk.
  3. Brainstorming with the Key players that involve in the removal of the risks(Testers,Developers, Managers,etc.).

When should you use “Risk Analysis”?

The answer is “Always”, Risk analysis is a continues process, and should be used on a daily basis, but the main key for success is to start performing it early as possible, early start will highlight the potential risk and may provide the potential to handle it when the impact is still tolerated.

What questions should be asked in RA process? 

How this risk impact the project timelines

  • There is enough time to handle the risk (Coding and Testing).
  • Does this risk affect the timelines of other projects?
  • How the Risk will affect the resource allocation(Working H)?
  • In case we decide to remove the risk, what are the consequences on the project timelines?

What are the reasons that created this risk?


  • Unspecified/unclear/Missing user requirements?
  • Wrong technical Design?
  • Technology limitations.
  • Logical error?

How this risk impact the project/software/business etc.?


Business Level: 

  • The risk may impact the company early commitments.
  • The risk may impact the company share price.
  • The risk may impact the company reputation.

Project Level:

  • Additional resource allocation is needed
  • Removing the risk will need an additional testing cycle.

Software Level:

  • Fixing one risk may lead to additional risks.
  • Fixing the risk may reduce the performance in some functionalities.

What’s the potential for occurrence (Probability) that the Risk will occour ?


Potential level
Almost certain that the risk will not happen
Can happen in very specific circumstances
The chances are 50:50(May happen or not)
Will happen on known terms of use
Certain fact
Almost certain to happen

What’s the impact of fixing this risk?

  • is there any Impact on other areas of the application?
  • Additional development?
  • Additional testing?
  • Changes in design?

What’s the ROI of removing this risk?

The company can handle the risk in a way that the removal the risk will be worth the time and effort.

The company cannot handle the risk at the current time, removing the risk doesn’t worth the invested time that will take to remove it.

Prioritization level

After you answered the list of questions, you now have all the information that you need to see the  “Big picture” and decide how to prioritize the Risks based on skillful decision, the basic priority levels are shown in the following table.

Prioritization level
Tolerable Risk
The risk as a minor or no effect on the project objectives, there is a minor chance of occurrence, the level of concern is almost doesn’t exist.
Low potential
Minor effect , low chance of occurrence, should cause minor concern
Med potential
The risk has the possibility to affect the project, there is a good chance of occurrence
High potential
High probability of occurrence , the risk will have a significant effect on the project, the risk should be under control until removal
Very High probability of occurrence, major impact on the project

Sunday, September 11, 2016

How can you Improve yourself as a software tester | David Tzemach


The internet is flooded with many articles and posts that telling you how to become a ‘Better’ tester and how to improve yourself, some of them are really great and useful, but some of them build without any relevance to the real world and how things that really occur on companies that has pressure and narrow timelines.

תוצאת תמונה עבור ‪become great‬‏

The main target for this article is to provide few thinking points that may help other QA Engineers to improve themselves and transformed from “Good” testers into “Great” testers, I hope you all find at least few points you can use and implement at your daily work.

Learning, Learning and Learning…!

Learning is not a suggestion, it’s simply must! Just like any field in life (And Testing not different) learning is everything, you cannot be good tester without continually improve yourself and your knowledge base.

Learning could be divided into four levels that when combined together create a great and powerful tester, my levels are: 

Level 1: Learn from your Own Mistakes

We are humans, humans make mistakes, and the testing field is not different. Learning from your own mistake is must, in our field you cannot make the same mistake twice, think about two different version that same bug occurred because you failed to find it on the first place (Mistake 1: You failed to find something that you should cover) and then you failed to update your STD documentation (Mistake 2: Every bug that found must be documented for future testing) and failed again. 

Author Example:
For me, my first six months as a tester was simply catastrophic, I come from the IT field without any real knowledge about the testing field. As a result, I made few mistakes that provide me with the Key Stones to become a really great tester. The difference for me was that I learn from my mistakes. And when I say “Learn” I intend to say that I investigate the reasons that led me to make the mistakes, analyze them and come with conclusions that prevent me to repeat those mistakes.

Level 2: Learn from the Mistakes of others 

Learning from your own mistake is a must thing to do (Previous paragraph explains the reasons...), learning from the mistakes of others  is different, the main reason is that when you make your own Mistakes it’s your direct responsibility to provide answers without the privilege to ignore your mistake. 

To learn from other mistakes, you must have discipline, don’t tell yourself the story that your colleague's mistake will not happen to you OR that it’s not your responsibility. For me learning from others is the best way to gain knowledge and improve myself without paying the price.

A great example for this section will be the general review that I make once a while on the Bug tracking system, I read bugs that opened by different teams and ask myself a few questions: 

  • Bug relevant to my team?
  • Can I add new test cases?
  • Reasons for failure?
  • Should I add a new testing data?
  • Environmental issues that may be relevant to my team?  
  • What can I learn from the solution?

Level 3: Learn the testing environment

I come from the Software Testing field, usually I test enterprise products that installed on highly complex architectures that involved different Operating Systems, integrations with 3rd party software and multiple environmental variables that affect my tests.

Remember this, you cannot tests anything like a professional without deeper understanding of your testing environment. Yes, I understand that sometimes its waste of time and in some cases the environment is very basic and predefined for the entire testing process, but in my world you cannot run any test without a real understanding of your environment.

You always need to remember that tests can and in most cases will be affected based on your environment. Therefore, you must learn the environment variable (There are a million examples depend on the testing software…I’m sure you can find the once that relevant for your tests…).
Basic Examples: 

  • Directory services (UNIX vs. Microsoft).
  • Permission architectures (SQL vs. Oracle).
  • Performance testing with different RAID types (Raid 0, Raid 1, and Raid 5).
  • Java/Html behavior on different web browsers.
  • File system tests (NFS Vs NTFS).
  • Threads tests for crawlers (1 core vs. 20 cores).

Level 4:  Learn your product

Well, it’s the natural thing to declare, you need to learn something before you can start to and use it, the main question is how deep your knowledge need to be..? For me there is only one answer, you must master your product, it’s your responsibility to test the product and lower the risks, this target cannot be accomplished without a deep investigation and learning procedures.

For me, mastering a software should be achieved only after the following criteria accomplished:

Master the flow from the start and until the End, and don’t be confused, the full flow includes the User interface operation vs. the exact code part that is written behind it. In addition, Understanding the code and Stored Procedures, can help you design great test cases and uncover the missing requirements in spec that has effect on the written once.

Master the requirements (Software/Hardware) of the software is really important, just think about a software that support single OS against software that supported 10 OS. This case may affect the entire testing design process. You always need to remember that different OS is completely different when executing different testing methods (compatibility and performance is a great example). In addition, understanding the requirements should also cover (you will see that each bullet has direct influence on your testing design and coverage.): 

  • Supported Hardware for integration.
  • Integration with 3rd party applications.
  • Supported operating systems.
  • Minimum requirements for installation.
  • Software limitations.
  • Known issues for specific scenarios.

Master the software Architecture of the software, understanding the architecture and integrations between components are really helpful when testing a software, just think about bugs you find in one place that fixed for a specific scenario, but as a tester you know that additional components interact with the same code and may be affected by the change.

My Presentations