Saturday, November 26, 2016

Compatibility Testing | David Tzemach


In the world of testing, the term 'Compatibility' means to determine whether the application that under test, is compatible with a different set of objects such as: Operating systems (OS), Hardware, Devices, and any other applications that coexist on the same architecture. 

What are the main goals of compatibility testing?

  • To Ensure that the application is Compatible/Capable to run on different objects based on the requirement and specifications
  • To Ensure that the application behavior is not affected when used with some different objects (software Or hardware).
  • To ensure that the application will not cause any problem with the corresponding object. 
  • To ensure that the user can use the software with different configurations without any issues. 

Why use Compatibility testing?

As you know, the current technology world poses too many types of hardware and software’s that enable users to execute a verity set of applications. Compatibility testing is a test that allowing us to validate that our application is supported by those objects in the same way as it intended to be. 

When do we run compatibility testing?

We can perform this type of test when we have a working version of the application, and after we reviewed the requirements and specifications that will determines the set of objects (software or hardware) that our application can interact and support.

List of software compatibility testing

Operating system (OS)

We will validate if the application can run as intended on different operating systems:

Operating System 
OS distributions
Windows server 2012/6.
Red-hot/ Ubuntu. 
Android 5/6
OS Service packs 
Windows server 2012 Sp1 , Sp2 , without any service pack 
Version backward testing 
The application is tested against an old version of the supported operating system 
Version forward testing 
The application is tested with a new versions of operating systems. 

Mobile Devices 

We will validate if the application can run as intended on different phones and phone versions, such as:
  • Samsung Galaxy 
  • Motorola Play 
  • Iphone 7
  • LG G5 
  • Android version 'x'
  • iOS version 'x'

3rd party software's

The application is tested with 3rd applications that may affect the application functionality

  • Malware apps
  • Anti-Virus Apps
  • Monitor Apps
  • Backup Apps


We will run the application on different hardware configurations and topologies 
  • Distributed vs Consolidate environments
  • Virtual Vs Physical servers
  • Memory 
  • Capacity 
  • Storage 
  • Cpu’s


We will test many parameters of the application (Bandwidth, Data transferring…) with different communication networks 
  • Fiber channels 
  • Bluetooth 
  • 3G/4G
  • Wi-Fi 


We will test the application with different devices  
  • Physical Machines 
  • Virtual Machines 
  • Watches 
  • Phones
  • Tablets 


We will validate if the application can run as intended on different browsers and browser versions
  • Internet explorer.
  • Chrome. 
  • Firefox 
  • Edge. 
  • Safari 

Tuesday, November 22, 2016

Black-box vs White-box Testing | David Tzemach

תוצאת תמונה עבור ‪black box vs white box testing‬‏

Black Box Testing (BBT)

White box testing (WBT)


A software testing approach that is used to validate the software based on the preliminary requirements and specifications (There is no need to access the source code of the application).

This testing approach does not require the tested to be familiar with the internal code, design and code structure of the application that's being tested.  

In white box testing, we will need to understand the internal architecture of the software, this knowledge should include the methods, code design, code integrations and many other components that may help during the tests.

As such, the person who runs the tests should have the relevant permissions to access the code.
Performed by
Test teams, developers, end-users, and any other resource that can work with the application and report for an incident.

Usually made by developers, but in some cases, there is a dedicated QA team that can handle this type of tests.
Programming knowledge
In my personal opinion, every tester should know at least a single coding language, but for this theoretical post, the answer Is no.

Must have, that’s the main reason why it’s made by developers J.
Testing level
Used on the later phase of the testing effort (System, End-to-End and Acceptance).

Run on the earlier phases of the testing effort (unit, Component, and integration).
Test Flow
We will test the End-to-End flow of the system.

We will test a single function each time.
To run this type of tests, we will need to use a running application, that will allow us to run the test flows.

There is no need to use a running application, the tests are created in earlier phases of the application lifecycle
Defect reporting
Each bug is reported in a dedicated bug reporting system.

Defects are not reported; the developer will remove them instantly.
Defect Complexity
In some cases, the defects are very complex and involve many integrations between the code parts, but in some cases, it will be an easy UI defect.

Remember that we test a small part of the code (UNIT), therefore when a defect is found it will be easier to remove it.
Test Design
Bases on requirements and specifications

Based on the detailed design of the internal structure
Test Techniques
  • Error guessing
  • Boundary value analysis
  • Equivalence partitioning
  • Exploratory testing
  • Decision tables
  • Loop Testing
  • Data Flow Testing
  • Condition testing
  • Statement coverage
  • Path Coverage Branch coverage

Black Box Testing (BBT)

White box testing (WBT)

  • Conduct by many types of resources that may have different perspectives (Testers, Developers, etc.).
  • There is no need to access the internal code.
  • Easy to design and execute. 
  • Involve the entire flows of the application. 
  • Allow the testers to test large complex applications.
  • The method involves both manual and automated test execution.

  • Very efficient in finding defects and logical errors.
  • Allowing the developer to concentrate on a small part of the code.
  • Will optimize the code structure and performance.
  • Allow the Developer to re-run the tests over and over again.
  • Uncover errors in the earliest phases of the SDLC.
  • Unit tests provide both the reliability and stability in the code. 

  • Does not allow to run all test scenarios (Limited tests are performed). 
  • The testing quality can be inefficient due to the resource-limited knowledge in the internal structure of the application.
  • Very hard to maintain the tests during the time. 
  • Regression tests are the worst enemy of tester happiness. 

  • Limited view on the code integrations.
  • Requires the deep and high level of knowledge of the application design and structure.
  • Time-consuming and Expensive. 
  • Unit tests are very fragile in any case of code modifications. 

Saturday, November 19, 2016

SDLC vs STLC | David Tzemach

In this article, I will review the fundamental concepts of Software Development Life Cycle (SDLC) and Software test life Cycle (STLC) throughout the traditional development methodologies. 

תוצאת תמונה עבור ‪quality assurance funny images‬‏

Software Development Life Cycle (SDLC)
Software Test Life Cycle (STLC)
Requirements gathering and analysis
In the first phase, the team members (Usually by the PM/Analyst) collect and document all possible requirements and specifications of the application to be developed based on the client demands and expectations.

Each requirement definition must be detailed as possible to remove any misunderstanding in the later phases.

Once all the customer specifications are gathered and documented, there is a meeting with the client that should provide his approval.

In the first part, the testing team will review and analyze the customer requirements and specifications.

In the second part, the testing team will determine the types of testing that they will use during the testing cycles.

In the second phase, the team will review and study the requirements and specifications that were gathered in phase 1 that they need to use during the preparation of the plan and design of the application to be developed.

  • Design the Application Architecture.
  • Determine the software and hardware that will be used per model.
  • Determine the development schedule.
  • Determine the process that the team will use during the coding phase.
  • Determine the applications components and integrations.
  • Determine the coding languages and platforms.

In this phase, the test lead/architect will design the High-level testing plan that will be carried out in the Testing phase (Software Test Plan).

  • Determine the testing methodology.
  • Determine the testing types to be used by the testing teams.
  • Determine the testing tools.
  • Determine the test environments.
  • Determine the test resources.

In this phase, a development team will use the system design to develop the application (Units, modules and integrations).
The testing team will use the STP from the previous step to create a detailed test plan (STD).

  • Test Scenarios
  • Test cases
  • Expected test inputs and outputs.
  • Time estimations per test.
  • Test configuration.
  • Test prioritization.
Once the development phase is done, the testing team has a working system that they can use to execute the tests and validate that all requirements are implemented based on the client expectations.

The testing team will execute the tests (Manual & Automated) as planned, report for defects and retest as needed.
Once all tests are done, the application is ready to be implemented on real production environments(GA)
The testing team will review the test results and test artifacts, based on this analysis the test team can determine/improve the testing strategy for future projects.

In addition, the testing team will generate the final test report.

After the product deployment, the company will provide support and technical assistance to the clients.

  • Technical assistance.
  • Bug Fixes.
  • Patches releases.
Test plans are updated based on the analysis results in addition to testing the enhancements and support requests.

Friday, November 11, 2016

What is Software Risk Management (SRM)?


Software risk management (SRM), is a process that combines a set of tools, processes and methods for managing risks in the software development life cycle.

 In the SRM process, we want to make a productive decisions about the things that can go wrong in different levels (Business, project and software), understand the importance of each risk and his severity, create a dedicated strategy to handle it, and finally implement the strategy to remove it.

תוצאת תמונה עבור ‪risk management best quotes‬‏

The 5 phases of Software risk management 

Risk identification
The first and probably the most crucial stage of the entire process, in this step we want to search and identify the risks that may come up during the SDLC and affect the project.

Risk Analyze
In this stage we need to determine the level of risk for each item in the list we prepared on stage one, the level of risk is determined by the likelihood of the risk to occur and on the impact that he has on the project.

Based on the analyzed information, a plan is created and implemented (this plan is set to handle each risk with the corresponding set of actions).

Tracking the set of decision and actions that issued.

Fixing any deviations that occurred at the implantation stage.


What data should be included in the Risk report? 

Any risk report should contain the following components:

Trigger – The reason that will cause the occurrence of the risks.

Probability – What is the “Likelihood” of this risk to append?

Consequences – What will be the effect of the risk?

Solution – What solution/Tasks should be performed to eliminate the risk or prevent it from happened.


The main goals of the SRM process

  • Develop an efficient test plan that will cover the areas that has the higher risks.
  • Learning the cause of risks and remove them from future projects.
  • Minimize the impact on different levels of the SDLC.
  • Monitor the changes made based on risk removal.
  • Anticipate and identification of the hidden risks.
  • Understand the location of the risks.
  • Provide confidence in the software.
  • Remove the risks.

The main benefits of the SRM process

  • Help to improve the current business strategy and project planning.
  • Help to answer the question “How much testing is enough..?”
  • Help to remove potential risks on earlier stages of the project.
  • Create a better communication between the business units.
  • Reduce the probability to encounter unwelcome surprises.
  • Provide an effective way to use the available resources.
  • Help to reduce the number of risks in a software.
  • Increase the chances to finish the project in time.
  • Help to design a productive testing matrix.
  • Help to design an efficient SDLC process.
  • Protecting the reputation of the business.
  • Promoting continues improvement.
  • Lower the project costs.

The environmental keys that build a successful SRM process

  • Realistic demands of the process and his outcomes (Technical, schedules Etc.).
  • The Management should review the SRM activities and add their input.
  • The SRM process should be supported with an appropriate budget.
  • The SRM process should be supported with dedicated timeframe.
  • Management should endorse and support the SRM process.
  • Management and workers' commitment to the process.
  • Working together to achieve a common goal.
  • Corporation between all resources involved.
  • Define a Clear project scope.
  • Project personnel are being trained both in the processes to be carried out and in the methods that going to be involved.
  • The project owners received the required training that should help them to identify and remove the risks.


The questions that you need to answer in advance:

  • What is the set of skills and knowledge that needed from the SRM resources?
  • What is the set of tools that we are going to use in the process? 
  • What are the actions that would be conducted at each step?
  • On which criteria we prioritize the identified risks?
  • What are the available timelines for the process? 
  • What we want to achieve in the SRM process?
  • What are the steps that need to be constructed?
  • What are the success/failure criteria?
  • How can we monitor the process?
  • How often we need to report?
  • Who is going to be involved?

My Presentations