TIBCO Definition:

TIBCO is an integration tool or middle ware tool which is used to integrate the application system.

TIBCO KEY Component

  • TIBCO Designer
  • TIBCO Business Works engine
  • TIBCO Administrator
  • TIBCO Runtime Agent (TRA)
  • TIBCO HAWK
  • TIBCO Enterprise Message Server (EMS)

 

Key test check points referring TIBCO Administrator

TIBCO Administrator is used to deployed the application and here test team can verify few things like

  • Latest Ear file is deployed or not
  • All the Service instance are running or not
  • All the Global variable defined
  • In case of any issue or error Test team can verify the logs and trace the process using TIBCO Administrator.

TIBCO TESTING: 

As per the TIBCO Testing is concerned TIBCO worked as middle-ware tool and used for the integration purpose. The key challenge in the TIBCO Based Application is to make sure the data flow from one component / application to another component going smooth and data consistency and integrity maintained throughout the journey, whenever Test team go for the integration testing user has to make sure that incoming request and responses are valid and it’s support all the necessary protocols like HTTP, HTTPS, JMS etc. and data conversion are appropriate during the complete journey.

TIBCO provides the flexibility to integrate with JAVA, .NET, Web application, SAP, CRM application

 

Advantage of TIBCO TESTING

  • TIBCO Testing hide the application complexity and give you opportunity to focus on core functional testing like Library, process ,classes ,web service  without knowing the in-depth coding information
  • There is no scripting or very less scripting and configuration required in case you chose any Automation tool for the functional testing or Performance testing for the TIBCO based application
  • Easy to use and not required much effort to maintain and manage
  • Platform independent
  • TIBCO Testing More focus on the Core functionality like response time, process, Web service, Protocol support, key business scenarios and environment specific scenarios like what happened in case of EMS server is down or DB Down or service instance are not running, Critical engine crash, fall-back file.
  • All the Exceptions and logs are captured and communicate to the concern user via mail or through alert.
  • TIBCO BW have inbuilt Tester to test the process.

PROCESS

Business scenarios: Verify the Fall-Back file is written at specified location when the EMS Server is down

Precondition: DRAGAN Server and Database up and Running.

Component: JAVA Client Application, EMS SERVER, DRAGAN SERVER, DATABASE, DRAGAN DASHBOARD

Process:

  • The Java client application perform any transactions then request goes to EMS Server
  • EMS Server didn’t Received the Messages as EMS Server is down.

 EMS

 

Check point

  • EMS Server is down hence request shouldn’t go to the Server and information will write in the Fall-Back file at specified location.

 unix

 

Check point

  • Fall-Back File will be available at specified location and all the necessary information kept in the fall-back file and naming convention should be correct.

 

Check point

  • Fall-back file size should not be more than 5 MB

Conclusion: As EMS Server is down hence Transactions not performed and information are captured in the Fall-Back file and specified location with desired location.

Automation Testing Tools

There are several Automation tools are used for the Testing for the TIBCO based application like

  • LISA
  • Green Hat Tester
  • Jmeter
  • Load Runner
  • Soap UI

Comparison between TIBCO Based testing and Traditional Testing

The Key objective of testing to find the defects in the early stage of the Test cycle and testing required repetitive efforts to make sure the application is working fine and meet the business expectation. Test team need to perform the testing on regular basis on repetitive mode if application is GUI based than testing is comparatively easy but if the application is Web based and having multiple component involved like LDAP, Authentication, Authorization, Adopter etc.  In TIBCO Based application Testing is more close to system testing where component level testing performed like each Web Service is verified on various parameters like input, expected output, timeout in case of delay etc.

In TIBCO based application testing test team are verify the messages /request are sent successfully referring the various protocol like HTTP, HTTPS, MQ etc.

For the TIBCO Based application can be tested using the TIBCO BW application which is having a in-built feature of testing and it’s very easy to use for the testing and drag and drop facility giving easy way to test team to do the necessary changes and build the Test framework as per the project need and easy modification and maintain.

Core business logic and business scenarios can be tested very easily

 

 

Traditional way of testing having so many drawbacks like Time Consumption, Manual intervention and many more hence due to these reason Test team faces issue when all the applications are not completely developed and deployed on the Test environment and this lead to increase the cost of the project due to proper utilization of the test team in the absence of complete development of the application or component.

Traditional Testing approach is not aligned with the current business need and objective and issue encounter in the later stage of testing or inadequate testing lead lesser quality product.

Application/Component based testing using stub for the TIBCO based application is very helpful  and TIBCO will give you the facility to test each process, web services core business logic, performance and make sure the core functionality is working fine at component/application level without putting  much efforts in the scripting and configuration issue.

In case of manual approach testing team required more time and repetitive efforts during testing after each build and its introduce the possibility of UN-identified defect move to the next level and if you go with Automation Tools for traditional testing   then test team need complex scripting and then modification and management of scripting which is very time consuming and costly as well.