25 May

128 Technology: 128T Networking Platform

128 Technology: 128T Networking Platform


We’re proud to announce that tCognition has recently partnered with 128 Technology, Inc. (Burlington); the former founders of Acme Packet (now Oracle)!

128 Technology in a Nutshell

128 Technology understands that for many companies, the network is a core part of their business – and in some cases, the network is their core business. They have developed the game-changing and stateful 128T Networking Platform (128T), which uses a Secure Vector Routing architecture that exponentially improves enterprise application performance, Cloud (AWSAzureGoogle), Security & Identity Governance, and network simplification, all while reducing cost through the elimination of now unnecessary devices (i.e. load balancers, firewalls, etc.).

128 Technology’s vision for 128T is rooted in the five basic principles below:

IP networks should be session-aware

All meaningful IP services and applications are based on sessions – the two-way exchange of information between endpoints. A session-oriented perspective provides the basis for a fundamentally new way of building, optimizing, and securing networks with end-to-end, fine-grained control, and visibility.

Advanced network capabilities should not be standalone functions

Network functions such as firewalls, load balancers, and Wide Area Network (WAN) optimizers have some level of session-awareness, yet reside in multiple physical or virtual appliances that add to the complexity. Imbuing session awareness and control into the routing layer enables the consolidation of these functions, and makes them native to the act of routing.

Routing must evolve to be application and service-centric

The modern model for routing must evolve beyond simply IP addresses and cost-based forwarding to encompass the notions of service topologies and policy frameworks. Multi-tenant policy and control logic should exist within, not on top of, IP networks.

Overlay networks are not the answer

Encapsulation or tunnel-based overlay networks such as MPLS, IPSec, and VxLAN sit on top of IP networks in order to deliver deterministic routing, network virtualization, and segmentation. These techniques create overhead, fragmentation, operational costs, and scaling challenges – and limit the effectiveness of security and monitoring systems. Session-oriented networking offers a better alternative that stretches virtual networks end-to-end across network boundaries and domains.

Zero trust security must be everywhere

Perimeter security models are no longer sufficient for today’s business demands. Next-level network security requires that no user, traffic source, or connected network should be trusted. IP routing is no exception.

With these principles in mind, 128 Technology has developed a new kind of networking platform that addresses a broad range of networking challenges but is easy to implement alongside your existing network. They’re excited about this platform because it will deliver outstanding benefits to enterprises, service providers, and cloud services companies alike.

128T Networking Platform (128T) is a software-based platform that exponentially simplifies networking, reduces cost, and provides greater security. The session-oriented, service-centric, and deterministic policy engine enables faster route selection and bi-directional route enforcement through the use of a distributed control plane (vs. centralized controller), eliminating the need for tunnels, overlay networks, and segmentation, treating traffic flows in direct correlation to the established policy.

The CGN approach to networking configures end sites with private addresses, which in turn are translated to public addresses by NAT devices embedded in the network. The incorporation of CGN is similar to a tunnel header applied in multi-tenancy environments, and thus, application-level NAT problems are eliminated, as the source and destination addresses are translated back to the original addresses before delivery to the final destination. 128T is superior to current software-defined Wide Area Networking (SD-WAN) architectures and network functions virtualization because it eliminates complexity and reshapes the way organizations design, deploy, and operate real-world networks by making them dramatically simpler, smarter, and more secure.

Application in Financials and Retail

128T brings tremendous value to the Financial Services and Retail Industries, with a unique focus on the following use cases.


Zero Trust Security starting at the very edge of the network and extending across network boundaries; no packets enter the network unless there is an explicit policy allowing access.


Next Generation WAN (NG-WAN) with seamless failover, the ability to leverage public and private networks, and the need for more and lower cost bandwidth across networks.

Interconnecting Data Centers

To create one “logical” DC to the enterprise including Disaster Recovery with the support of duplicate IP addresses, and the ability to move services across networks.

For example, 128 Technology is currently working with a large financial software company that had experienced a session failure resulting in millions of dollars lost in trades. Session migration and session failover were a high priority for them; all resolved using 128T.

128T can also add enormous value to any retail organization by providing secure, efficient, and dynamic connections to retail locations. Through the NG-WAN platform, a large auto part retailer, for example, was able to connect over 4,000 sites countrywide. The primary driver for this retailer was 128T’s ability to provide dynamic failover of applications.

How tCognition Can Support 128 Technology

tCognition offers cost effective programs in support of advanced technologies like the 128T Networking Platform, providing Application Development & IntegrationQA-Test EngineeringHelp Desk (Level 1-3+), and 24×7 Managed Services all customized to meet the exacting requirements of our client’s needs.

We employ solution development and product support teams for Enterprise applications like NetSuiteOracleSAGE and SAP; monitoring and management tools like EM7, Nectar, and HP OpenView; secure mobile (iOS, Android, MS) application Single Sign-On (SSO) solutions for accessing ServiceNow, ERP and CRM platforms; Omni-Channel – WebRTC solution frameworks enabling browser based full collaboration communication; Telematics, connected vehicle solutions for Agero, vehicle manufacturers like Toyota and VW, and Insurance companies.

We look forward to working with and supporting 128 Technology in taking on the challenge of securing, controlling, and optimizing clients’ overly complex networks – and internetwork – architectures. Let us know how we can engage you in a discussion and show you how we can help deliver the highest level of security, control, and agility – along with 128 Technology!

15 Jun

UAT vs. SIT Testing in QA

UAT vs. SIT Testing in QA

UATvsSITtestingUAT and SIT are the two different levels of testing in the application testing phase of QA. UAT stands for User Acceptance Testing and SIT stand for System Integration Testing. Here we compare UAT vs. SIT against one another.

UAT: User Acceptance Testing Best Practices

User Acceptance Testing is the final stage of testing before the system is accepted by the operational user. End users perform UAT based on the user requirements specifications to confirm whether an application is meeting requirements.

Types of UAT:

There are two major types of User Acceptance Testing: Alpha Testing and Beta Testing.

  1. Alpha Testing: Alpha testing is performed at the developer’s site by the customer. The testing is performed under a developer’s control. Alpha Testing is performed once the system testing is completed.
  2. Beta Testing: Beta testing is performed at one or more customer’s sites by the end user of the software. For the beta testing of an application, it is given to a trusted customer. Here the testing is not under developer’s control. Beta testing is performed only after alpha testing is done. 

SIT: System Integration Testing Best Practices

System Integration Testing is performed to confirm whether the modules tested individually can work together to deliver the required functionality. Modules tested individually may work fine, but when they are integrated together some issues may occur. System integration testing is performed to test the dependency between modules through transfer of data from one module to another.

System integration starts at the module level where units are integrated together forming to form a subsystem and eventually a system.

Types of SIT:

There are two major approaches to System Integration Testing: top-down integration approach and bottom-up integration approach.

  1. Top-down Integration Approach: Here modules are integrated by moving downwards in hierarchy, where the main module is at the top. In a top-down approach if lower modules are not ready a dummy modules called a stub is used for testing. A stub acts as the module during the test. Stubs have the minimum functionality required to be used while testing the ‘above’ module.
  2. Bottom-up Integration Approach: Here modules are combined and started to test at very low level. If the top level modules are not ready then drivers are used for testing. A driver is a program specially used for testing.

Comparison between UAT vs. SIT:

No. SIT- System Integration Testing     UAT- User Acceptance Testing
1 Testing interface between modules Testing with respect to user requirements
2 Purpose of testing is to see the interface Purpose is to test the functionality from end user’s point of view.
3 Performed by Developers and Testers. Performed by Customers and End Users.
4 Issues will be with data flow, control flow. Not as per User Requirements.

User acceptance testing best practices and systems integrated testing best practices are both critical skills for any quality assurance team. At tCognition we pride ourselves on our QA team, head to our quality assurance page to find out why!

15 Jun

Forward and Backward Compatibility Testing Examples

Forward and Backward Compatibility Testing Examples

ForwardAndBackwardCompatibilityTestingTechnology is changing tremendously in styles. To keep up with the competition, constant upgrades of a product and a focus on branding is necessary even after successful versions of any given software or hardware have been launched. This is where compatibility testing comes into play.

Compatibility testing is most important part of software development to test whether a developed product is working as expected as see if improvements or enhancements are required. Hardware, mobile devices and other applications can all be tested for compatibility.

All major product developments in the corporate space include some kind of compatibility testing before launching the product into the market. This compatibility testing has two forms: backward compatibility testing and forward compatibility testing.

Forward Compatibility Testing:

To verify and test developed software or hardware to see if it is compatible with future versions of other platforms or not is known as forward compatibility.

Because all of the dynamics of future compatible platform(s) are not always known, forward compatibility testing is little bit harder to test than backwards compatibility.

Backward Compatibility Testing:

To verify if a developed software or hardware product is compatible with older platforms or not is known as backward compatibility.

In this case, all of the dynamics of the potentially compatible platform are known, so backward compatibility testing is much more predictable than forward compatibility testing.

Forward Compatibility Testing Example:

A Siebel CRM update to the new version was halted with the help of compatibility testing:

Our client wanted to upgrade Siebel CRM from 8.1 to 8.4. With the help of a test environment setup with Siebel’s backup framework, the testing observed that the migration of their customized database would not be stable with the Siebel 8.4 version. Due to this testing, development on the migration to the new version was stopped. This helped to avoids lots of issues and had the clients start thinking about alternative platforms.

Backward Compatibility Testing Example:

Mobile Apps:

Every brand (Samsung, HTC, etc.) has their own different Android UI and customization. If they release new UIs, versions or customizations, they will test their platforms to make sure that they are backwards compatible with older applications as well. They don’t want people who download their new UI not be able to use their favorite existing apps, hence backward testing.

During backwards compatibility testing in this example, we ask these questions:

  1. Is the new version/platform working fine with every older applications and APIs?
  2. Is the devices’ securities remaining stable and strong?
  3. Is the new version/platform upgraded device working fine with older components – hardwares like battery and its backup, charging and status of charged device,  camera, flash, network and calls, display UI’s resolutions etc. working fine?
  4. Is the new version/platform upgraded device working fine like before?
  5. Is the new version/platform upgraded device not corrupting older data of the device and customer data?
  6. Is the UI of the applications still graphically pleasing and working well with the all applications?
  7. Is the new version/platform upgraded device as good as before or better?

Some of the tools used for compatibility testing:

Operating System Compatibility:

  1. Virtual Desktops
  2. iOS Simulator
  3. ADT bundle

Browser Compatibility Testing:

  1. Adobe Browser Lab.
  2. CrossBrowserTesting (https://crossbrowsertesting.com).
  3. IE Tester
07 Jun

Exploring the Benefits of API Testing

Exploring the Benefits of API Testing

BenefitsOFAPItestingAPI is an acronym for Application Programming Interface. An API is a set of procedures, methods and functions that developers “open up” to other programmers in order to have their applications interact and communicate with other applications. Once an API is built, it is necessary to test the interface to make sure it is working properly.

API testing is different from UI testing, and it mainly concentrates on the use of software to send API calls, receiving outputs and logging the system responses. API tests investigates applications that have varying API functionalities and varies the parameters of the API calls in different ways that verify functionality and expose failures.

Here is a diagram of where API testing typically comes into play:


API Test code: What should be performed –

The API test code or test “harness” should send different parameter combinations through the API, and the return values based on input conditions should be checked.

API testing is the only way to provide truly secure, reliable and scalable connections between platforms. Testing provides these benefits:

1. Access to application without user interface

The major core advantage of API testing is that it provides access to application without users actually having to interact with a potentially disparate system. This helps the tester to detect and recognize the errors early, instead of them becoming larger issues during GUI testing.

2. Protection from malicious code and breakage

API test requires extraordinary conditions and inputs, which protects the application from malicious code and breakage. Basically, API tests push software to their connective limits. API testing helps remove vulnerabilities.

3. Time Efficiency vs. functional and validation testing

API testing is far more less time consuming than functional and validation testing. 10,000 automated API tests save 3 hours of time on average vs. functional and validation testing.

4. Cost Effective / Reduces Testing Cost

API test automation requires less code than GUI automated tests thus providing faster test results and better test coverage. The end result of faster testing is a reduction in overall testing costs. Testing the API level functionality of the application provides an early evaluation of its overall build strength before running GUI tests. Early detection of errors reduces the manual testing cost. API test automation increases the depth and scope of the tests.

5. Technology Independent

In an API test, the data is interchanged using XML or JSON and compromised of HTTP requests and responses. These all are technology independent and used for development. Thus an API test allows you to select any core language when using automated API testing services for your application.

API Testing Tools:

There are many API testing tools available such as:

1. JMeter

JMeter is an open source tool available on the market for API testing. JMeter provides an easy integration with Jenkins to run the test periodically and Jenkins has a plugin for Jmeter to parse the result file and display the charts.

2. Eclipse IDE Java SDK tool – Automated API testing

Eclipse IDE Java SDK is an open source tool, which helps in consuming RESTful web services with Jersey Client API. Jersey client API is an easy-to-use, high level, Java technology API that can help you write clients for any HTTP-based RESTful web service.

3. Test Manager

Test Manager is a tool to test API by sending requests like GET() and POST() and receiving a response from a particular application server or web server. The user enters the specific IP address, port address and then creates a new request with input parameters. On successful execution of a script, a response is received like ‘200 OK’. Some more tools like Hurl, Fiddler, Runscope, dotTest are also available for API testing.

06 Jun

QA Testing in an Agile Environment

QA Testing in an Agile Environment

qa_agile_environmentAs a QA Testing Engineer, I have worked on different SDLC models (software development lifecycle models). One of the most recently introduced SDLC models are “Agile Methodologies”. Nowadays, being “agile” is considered more appropriate and is chosen more often over the traditional methods like “waterfall” models.

Creating an agile test environment has developed a cult following. Like most of the QA engineers here at tCognition, I subscribe to the “Agile Manifesto” (from agilemanifesto.org):



“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”

QA Testing with Agile Processes – “Sprinting”:

The agile process is followed in software development where requirements are changed frequently and there is need to show the working software at frequent intervals. This is where sprinting comes into play.

All the requirements together in a single project are called product backlogs. The backlogs are divided into multiple iterations, or “sprints”. A single sprint will undergo plan, design and development. Afterwards, the solution to these requirements are tested and reviewed.

A set of requirements that can be implemented independently or on top of the previous sprint work are taken and recorded in documents called user stories. Development is performed on the current sprint’s user story. A typical sprint span lasts about 2-4 weeks. Each sprint is followed by testing activities and any issues / bugs are fixed. After this testing the code is ready to be deployed.

There will be multiple sprints in any given project until all the requirements from the product backlog are covered and the project is completed end-to-end.

Tips on Creating an Agile “Environment”:

Key points to be remembered while working on a project that follows an Agile Framework:

  1. Purpose: Think about what this project is all about and what is needed to implement the solution.
  2. Teamwork is very important. Frequent interactions with your teammates are a must. Consider it like a bunch of mini or micro projects where a single project has to be delivered in a 2-4 week span.
  3. Active participation in all the scrum meetings and holding brainstorm sessions are essential.
  4. Each user story should be discussed and mapped by the QA team and all the requirement gaps should be found as early as possible.
  5. Give feedback: communication promotes agile methodologies.
  6. Testers should always keep an end-to-end approach in mind even though it is one sprint at a time!
  7. Test data preparation needs to be done well in advance. The following points should be considered:
    – What kind of test data is required?
    – Can the test data created be reused in current and future sprints?
  8. A few sprints should be allocated for regression testing and system testing at the end to make sure application is working fine end-to-end.
06 Jun

Beta Testing Mobile Applications with Selenium

Beta Testing Mobile Applications with Selenium

BetaTestingAppsUsingSeleniumWhy use Selenium for Beta Testing?

Beta Testing is testing carried out on new or upgraded software applications by actual users “getting their hands dirty”. Selenium is an open source record-and-replay software testing automation tool that is the preferred choice for testing GUI and the functionality of web applications. Selenium is preferred for beta testing because of its robust, open-source software testing framework. Selenium tools are used across diverse industries to test applications for performance, reliability and compatibility of web applications.

Selenium’s open source licensing and support for multiple browsers, languages and platforms makes it a more advantageous product than QTP (QuickTest Professional) which incurs high license costs. Selenium is a advanced test automation tools designed for effectively performing web browser based automation tests such as Selenium UI testing, load testing and more.

Selenium Beta Testing Tool Descriptions:

  1. Selenium IDE – Selenium Integrated Development Environment (IDE) is a Firefox plugin that lets testers to record their actions as they follow the workflow that they need to test.
  2. Selenium RC – Selenium Remote Control (RC) is for complex programming languages like Java, C#, PHP, Python, Ruby and PERL to create more complex tests.
  3. Selenium WebDriver – Selenium WebDriver is the successor to Selenium RC which sends commands directly to the browser and retrieves results.
  4. Selenium Grid – Selenium Grid helps run side-by-side tests across different machines and different browsers at the same time which results in minimized execution time. commands directly to the browser and retrieves results.

Advantages of Selenium Vs QTP

  1. QTP costs money.
  2. Selenium works with all browsers, QTP works only with only latest version of browsers.
  3. Selenium Support Mobile Testing where as QTP needs 3rd-party devices to support mobile testing.
  4. It is a a more automated form of testing.
02 Jun

QA: Functional vs. Regression Testing

QA: Functional vs. Regression Testing

Functional Vs Regression TestingWhat’s the difference between functional vs. regression testing?

In short, functional testing ensures all functionalities are working as expected, while regression testing occurs only after a team publishes a new build in order to fix defects or debug software updates.

Functional Testing

Functional testing includes validating functionalities of any given program. Typically, functional testing involves black box testing. A tester identifies if a set of code is meeting any given criteria. The functionality is the only thing measured. Design and user experience are not considered during functional testing.

The main points of functional testing:

  1.  Understanding customer requirements
  2.  Testing input data
  3. Gathering expected results
  4. Executing test cases
  5. Comparing actual vs. expected results
  6. Updating results according to test case

Functional testing best practices –  focus on:

  1. GUI coverage: with different screen resolutions, GUI elements like font size, color, etc.
  2. Input domain coverage: taking valid and correct size with appropriate formats.
  3. Return of correct data with correct input.
  4. Order of functionality (i.e. Tab order).

While executing test cases we need Input data. The input data is the data which is used for test cases execution.

There are two types of input data:

i) +Ve Test Data – Inserting data should be valid data. Valid data means we have to follow SRS (System Requirement Specification) document, where the input range or valid inputs details are described.

ii) –Ve Test Data – Inserting data should be invalid data. This means the data which is not specified in SRS or invalid inputs details or not in range.

A diagram of Functional Testing: Input Data Results

Functional Vs Regression Testing

From the above diagram we can use the Bombardment of +Ve and –Ve Input data on software build to find whether actual result matches expected results.

Regression Testing

Even small changes or modifications to software can bring unexpected issues. Regression testing becomes very important to test whether existing functionality is impacted. Regression testing ensures every functionality is working properly after any update or modification happens.

Regression testing is done when:

  1. Any patches added to software or configuration of software has been changed.
  2. If new Change Requests are implemented to the build.
  3. New Features are added or any functionality has been added.
  4. Existing functionality is modified with improvements.

Sometimes regression testing is implemented to:

  1. Find bugs that can found because of new changes or modifications done on build.
  2. Check for  side effects after fixing bug or any changes made.
  3. See if there are continuous change requests then there is high possibility of new issues.
  4. Help quality improvements.

Diagram of regression testing:

Screen Shot 2016-06-02 at 9.40.11 AM

Conclusion – Functional vs. Regression Testing

At the end of the day, functional testing is verifying whether functionality meets customer requirements. An example of regression testing best practices could be represented as development teams making changes to existing builds or published code.