Friday, April 21, 2017

The complete guide for Software integration testing | David Tzemach

Overview

Integration testing is a testing approach that we use to test the integration among two or more objects that should work and interact together. During the software development life cycle, we will see that integration tests are done on different objects that are not directly related to the system components.

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

Examples:
  • Integration tests between systems and OS.
  • Integration tests among the system modules (Testing the interface and communication among modules).
  • System integration testing (interfaces with external organizations, integration of system packages, etc.).
Another term that I will use in this article is “Interface”, an interface is a connection that connects two modules and the testing of this connection called “Interface Testing”.

Integration testing process

There is a basic process that you can use in an integration testing project, the process contains a few basic phases that are relevant to almost any other testing project.
  1. Analyze the requirements and specification of each module.
  2. Make sure that the person/team that run the tests are familiar with the technical details of each module and the overall system architecture.
  3. Now that you acquire the technical data, Review the Risks and determine the approach to remove them.
  4. Determine the testing strategy with a corresponding test plan (Test Scenarios, Test cases, expected results, test priorities etc.).
  5. Test execution (Executing the tests and open the relevant defects).
  6. Review of the test execution results and re-test if necessary.
  7. Review and approval of the testing phase before preceding to the next testing level (System Tests).

When to start integration testing?

Integration testing is performed after component tests and before system tests.

[Unit Testing] -> [Component Testing] -> [Integration Testing] -> [System testing]

Why do we need to use integration tests?

There are many reasons that can explain the need for this type of tests, let’s examine three of them:

  • Integration tests can lead to many situations that can trigger defects that will appear only in specific situations such as conflicts and dependencies between two modules.
  • Although each component is tested and approved (Prior to the integration phase), there is always a chance that the interface that allowing the communication between the modules contain defects that may trigger further defects in the integrated modules.

Example:

Module A should be integrated with Module B, both modules are tested and ready to interact one with each other, now let’s assume that the interface that should pass that output from Module A into module B has a defect that does not allow him to encrypt/Decrypt the data.

As a result, the two modules will fail to interact and sometimes, Module B will receive a corrupted and unexpected data that will lead to a massive failure.

One major thing that you should remember is that usually, each team/developer is assigned to develop a specific component and therefore in some cases he does not have the knowledge about neither the technical nor logic that is used to build the other module.

 Integration testing will allow us to test this “Uncertainty” and to validate that the gap is appropriately tested to allow the modules to work together. 


Integration test techniques

There are many techniques that we can use to successfully run this type of test, I will review them, but when the Hour comes, it’s your job to understand what is the most relevant technique for your testing project.

The Big Bang technique

This technique is actually very simple…. Before performing the tests, Development team will integrate ALL components/Modules at once (simultaneously) and then tested as one big system, once done, the integration tests will start for specific components/modules.

תוצאת תמונה עבור ‪Big Bang integration testing‬‏

Advantages
Disadvantages
Make sense when you need to test small systems
Consumes the integration testing time (the integration tests can start only when the whole system is tested)
All integrations are done before starting the integration tests
This technique is not relevant to large and complex systems.

Very difficult to trace the root cause of failures (Interfaces are not isolated during the tests)
Increases the chance to miss the small interfaces that need to be tested (All modules are integrated and tested at the same time)


The incremental testing technique

In this testing technique, the testing is done when modules that are logically related are integrated one by one and tested, this approach will continue until the last module is integrated and tested.

To use this test technique, we will need to use Stubs and Drivers that will help us to run the tests without the need to implement the entire module (Simulate the communication and data transferring between the modules).

When using the incremental approach, we can use two different methods called “Top-Down” and “Bottom-Up”.

Top-down integration testing 

When using the Top-Down technique, we will make the tests starting from the top higher module to the last module (Each module is integrated separately) based on the control flow hierarchy and the software architecture structure (we will use the top module and progress towards the lower modules that existing in the hierarchy).

תוצאת תמונה עבור ‪Top-down integration testing‬‏
Due to the nature of this technique, we will always have a TOP module that can interact with a lower module, the problem begins when the lower module is still not developed or just not ready for integration, as a result we cannot run the tests which affect the project timelines.

To overcome this problem and reduce the waste of time while waiting to the readiness of the lower module, we will use “Stubs”, stub is a term that represents a code snippet that can be used to accept the request from the top module and return a result similar to a real module.

Advantages
Disadvantages
It’s easier to find the Root cause of defects (A Single integration is tested each time)
Although stubs are similar to the real module, we will still need to make further tests once the module is ready, which consume more time.
This approach will allow the team to rank the major flows first, as a result, the most important defects will be found and removed before other defects that are less important.
In complex systems that built with many modules, we will need to develop multiple stubs
Comparing to the “Big-bang” approach, we can save time because we do not need to wait for all modules to be developed
In real world testing scenarios that involve complex design logic, you may have trouble to predicting how the stubs will react during the tests.  
often, you will find that the development of stubs will cost more than the actual module development

Bottom-up integration testing 

Based on the logical name of this technique, we can understand that we will start the tests from the lowest module of the application and gradually progresses towards the Top modules of the application until all modules are integrated and validated as a whole system.

תוצאת תמונה עבור ‪Bottom-up integration testing‬‏

The problem with this technique is similar to the problem that we had in the “Top-down” technique when you start to test the integration between two modules that one of them is still not ready to be integrated and tested (The higher module in our case).

To overcome this problem in the “Top-Down” technique, we used “Stubs” that are not relevant to our approach were you need to use another simulator called “Driver” that will allow you to use the driver to trigger/call the functions from the lowest module and to simulate the test inputs to the tested module.

Advantages
Disadvantages
Defects that are found in the lowest modules are easier to detect
The whole system is not built until the creation of the last Top module
It’s easier to find the Root cause of defects (A Single integration is tested each time)
The critical design flows are tested at the end which, increases the risk to find critical defects in this flow
Comparing to the “Big-bang” approach, we can save time because we do not need to wait for all modules to be developed



Entry and Exit Criteria

Like any other testing phase, integration tests should start and end based on a few basic criteria

Entry Criteria

  • There is a technical document that describes the expected behavior of each interface.
  • All major/critical defects from the early testing phases are closed and verified.
  • The test environment is ready to support the test scenarios.
  • The modules are integrated together and ready for testing.
  • There is a document that contains the test strategy.
  • Each component is tested and approved.
  • Each component has a list of Unit tests.
  • All risks are analyzed and removed.
  • All modules are identified.

Exit Criteria

  • All test cases from the test plan are executed and approved.
  • All major/critical bugs are re-tested, fixed and verified.
  • The test plan is signed –off.
  • A test review is done.

Best practices

  • Make sure that each component is tested and approved before executing the integration tests.
  • Make sure that you have a detailed technical document that explains how the interactions between each two modules (interfaces and how they should work).
  • In any case that it’s possible, automate your tests, otherwise, you will run each test manually per the integration of each module.
  • Make sure that you familiar with the modules to be integrated (Especially the design and architecture of the modules).
  • Determine the integration test strategy, this strategy should allow you accomplish the testing goals. 

Thursday, April 13, 2017

Execute JavaScript based code using Selenium Webdriver

We can use the Selenium WebDriver API to design and execute javascript code on the browser session. 

To execute JavaScript code, we will use the " IJavaScriptExecutor" interface that provides us the capability to execute the code and control it on a given browser session.
תוצאת תמונה עבור ‪selenium webdriver  javascript‬‏


Knowing the important keys!

1.     Prior to using the IJavaScriptExecutor interface, we first need to cast the WebDriver instance to an IJavaScriptExecutor instance.

Example:
IWebDriver Firefox = new FirefoxDriver();
IJavaScriptExecutor Execution = (IJavaScriptExecutor)Firefox;


2.     The JS code execution is performed with the ".executeScript()".
3.     When using the above method, we will need to use the "return" keyword and cast the returned valued from the script execution into the relevant type (int, string etc.).

Example:
String returnedJSvalue = (string) Execution".executeScript("code that return string")".
Code
[TestMethod]
public void RunningJavaScript(){
//Phase 1: Casting the WebDriver instance to a IJavaScriptExecutor interface

//Phase 2: Creating a new Driver instance
IWebDriver Firefox = new FirefoxDriver();

//Phase 3: Navigate to a web location
Firefox.Navigate().GoToUrl("http://www.machtested.com");

//Phase 4: Casting the WebDriver instance to a IJavaScriptExecutor interface
IJavaScriptExecutor JsExecution = (IJavaScriptExecutor)Firefox;

//Phase 5: Using the JsExecution.ExecuteScript() to execute the JS code
string URLName = (string)JsExecution.ExecuteScript("return document.URL");

//Phase 6: Validation
Assert.AreEqual("http://www.machtested.com/", URLName);
}

Friday, March 31, 2017

Product owner in scrum team | David Tzemach


The product owner (PO) role was established once the scrum framework was created to address issues that engineering teams faced during a product development, the main and most important activity that is expected from the PO, is to provide a single point of information that can remove obstacles during the development process.

תוצאת תמונה עבור ‪Product owner in scrum funny‬‏

In addition, the traditional role of the product owner(PO) in scrum contains some additional responsibilities and activities that are involved in different phases of the scrum process, based on the theoretical approach we can divide them into tree main categories:

Product owner (PO) & Scrum backlogs

  • Splitting user stories which are too big for a single iteration (Epics).
  • Determine the stories DoD and approve it in the review meeting.
  • Determine the stories acceptance criteria.
  • Prioritize user stories based on ROI.
  • Maintain the product backlog
  • Writing user stories.


Product owner (PO) & Scrum Team

  • Provide the user stories and targets for the next iteration (Planning meeting).
  • Help the team to remove any obstacles that any affect their performance.
  • Help the team to improve by taking real actions (Retrospective meeting).
  • Measuring the team progress based on commitment and velocity.
  • Communicate the product vision to the team.
  • Provide feedback to the team and determine the quality of the iteration deliverables (Sprint review).
  • Participating in daily scrum meetings to be able to adapt and inspect the current progress.


Product owner (PO) & Core Activities  

  • Make real business decisions that can affect the entire project.
  • Communicate the project status to external resources.
  • Provide the vision and goals for the project.
  • Have the final authority when needed.
  • Determine the project release dates.

Product owner Vs Task Manager

Take a few minutes and think about the list above, can you see the problem? There is no way that a single resource can actually perform all of those activities and to be honest it will most likely never happen, a “single point of information” has all the chances to become a “Single Point of Failure” and therefore we must understand that the Scrum theory is truly great on paper but does not relevant once you need to implement it.

Know this, the PO can be the resource that can determine the project vision and maintain the backlog stories, but it will most likely be a different person that actually owns the product and communicate with the stakeholders (Senior management, Clients, Budgets Etc.).

The Characteristics of a true product owner

Leadership - A good PO will provide a clear and informative vision for the team, it’s his responsibility to make sure that the scrum team will understand the project goals and what is expected from them.

Availability and communication - The product owner should be available for the scrum team, simple has that, a good communication is the key to every project and especially in scrum process.

Aim for continues improvement - The PO should aim to improve the process per iteration, it’s one of his major responsibilities to make sure that the scrum team will improve through time.

Experienced -  The PO role possesses many activities such as determine the goals, vision, and ROI of the project, to be able to determine each one of them, the PO should have the experience needed to deal with these challenges in a way that does not affect the project goals.

Adaptable to changes - As you know, in scrum we embrace changes that can raise during the SDLC, a good PO is not afraid to confront these changes and resolve them in a way that does not affect the project goals and vision.

Trust the Scrum team – A good PO, will trust the team once they determine their sprint commitments, a good PO will provide the freedom needed for the team to grow and manage their tasks throughout the iterations. 

My Presentations