Microservice Testing Trends for 2018

                       Microservice Testing Trends for 2018

Automation	API Testing	Mobile Application Testing	Cloud-based Application Testing
Quality teams are taking measures to adopt automation to address deployment velocity requirements and the need to ensure the most complete coverage possible. To address this need, every testing area—from compatibility and usability to performance and efficiency is going to require enhanced and improved automation	In years past, APIs – and the teams that built them – were largely viewed as peripheral concerns for the IT organization. That couldn’t be further from the truth now. Because APIs have become such strategic enterprise resources, it’s now very common for business users to get involved very early in the process and participate on an ongoing basis. These line-of-business leaders aren’t along just for the ride: they expect the APIs that you’re certifying to be high quality and offer performance in compliance with strict service level agreements.	With the growing usage of mobile devices and app downloads, the trend of mobile application testing is gaining ground in software testing domain. According to Gartner, almost 300 billion mobile applications will be downloaded next year. Since mobile application testing assists in enhancing end-user experience, the number of enterprises practicing mobile application testing is rising significantly every year. According to industry experts, 92percent of organizations are planning to emphasize on mobile application testing. The only challenge for executing mobile application testing is finding the appropriate tools, strategies, infrastructure along with the right capabilities.	Clouds form an essential aspect of Development cycle for several organizations. The World Quality Report states that cloud testing went up from 4 percent in the year 2015 to 24 percent in 2016. The IT industry puts a major emphasis on cloud testing by adhering to a specific methodology for analyzing cloud-based services. According to industry experts, the ever-increasing implementation of cloud solutions will result in the significant adoption of cloud-based testing in 2018. Unlike other complex and costly test environments which are quite troublesome to maintain, cloud infrastructure is flexible and offers an easy solution.

 

Internet of Things (IoT)	Crowd Sourced Software Testing	Testing Centre of Excellence (TCoE)	Context-driven Software Testing
In the current age of digital information, Internet of Things (IoT) has been experiencing constant growth. It is another major advancement that is gradually transforming how enterprises interact with their employees, associates and consumers. Digital innovation combined with machine-to-machine connectivity in the IoT industry is facilitating the smooth connectivity between multiple systems via various sophisticated platforms.	This is yet another trend in software testing that is gaining recognition worldwide. Crowd Sourced Software Testing helps enterprises manage their budget for developing sophisticated software. It is particularly helpful in difficult situations when testing teams may not have access to all the resources for testing the software in different circumstances. Crowd sourced software testing is a procedure under which software applications are made available to several end-users so that they can identify the flaws and bugs. Such testing services are generally controlled by organizations ‘as a service’	This trend has been undergoing a significant boom in the testing domain since the year 2011, and will continue to maintain its steady growth in the coming years. That said, it is imperative for TCoEs to embrace a more dynamic methodology so as to adopt up-and-coming trends such as DevOps, Mobile, Agile and Digital Transformation. TCoEs must constantly propel testing by implementing service virtualization, integration, and life-cycle automation..	Context-driven testing is another new trend that is emerging slowly but steadily. When it comes to software applications testing, a one-size fits all approach cannot be considered reliable. Diversity and robust integration of devices make it complicated for QA teams to set up a steady testing strategy. The necessity of being adjustable to any context changes has resulted in the popularity of context-based testing. Testers that are capable of acclimatizing to specific contexts thrive whereas the one-size fits all approach becomes irrelevant.

 

Agile and Uninterrupted Delivery

Comprehensive Security Testing

A large number of businesses today are solely dependent on mobile apps. As delivery cycles are getting shorter, conventional models of development are taking a backseat at the moment. Agile Dev cycles, uninterrupted delivery, and continuous deployment play an instrumental role in the success of any mobile app strategy. Thus, testing tools will focus more on integrations with IDE (Integrated Development Environments) and similar tools that will assist in continuous delivery

The increasing adoption of mobile, cloud computing, and IoT platforms in the IT industry has given rise to increased demand for security testing, thus, making it one of the vital priorities for IT leaders. Storing sensitive data such as credit card/debit card details, bank account details, and other confidential data on mobile phones makes them vulnerable to online theft. Thus, testers will continue focusing on renewed security by putting comprehensive security into practice

 

SERVICE VIRTUALIZATION VS. MOCKING AND STUBBING

Mocking and stubbing are similar to service virtualization, but they function on smaller scales. Mocking and stubbing usually involve testing specific behaviors in restricted contexts, whereas service virtualization replicates systems at a production scale

The growing popularity of service-oriented architecture and Agile development exposes limitations to mocking and stubbing. Service virtualization approaches testing at the infrastructure level and creates models that different teams can reuse in different circumstances. Mocks and stubs typically require manual development for each use case. Service architectures typically require too many dependent variables for mocking and stubbing to be practical, and agile workflows demand a speed that these methods struggle to meet.

Beyond that, developers are more likely to introduce errors into stubs and mocks based on their assumptions of how the application is supposed to react in each situation. Quality assurance teams can integrate both technologies if they use service virtualization when they need to emulate systems and mocking or stubbing when they only need simple, context-specific testing.

Type of Virtual Services / Stubs / Mocks

Stubs and virtualized applications can be simple or rich. Many vendors provides different service virtualization tools to create stubs and virtualized applications to the level required for support with development and testing.

In this blog we will have a quick look at what are the different types of stubs or virtual services which are required to roll out a quality product early.

 

Stub Type	Description
Basic	There is a hard-coded single response for each specific input.
Non-deterministic	There are "n" hard-coded responses. A message switch is used to "switch" the response based on the input message.
Data-driven (parameterized)	There is input and/or output data specified in external data sources, for example, databases or spreadsheet files.
Data model-driven	There is input and/or output data in a data model that includes relationships among those data items.
Behavior-driven	Stubs can be extended with "behaviors" that are Java plug-ins that can respond to messages and proactively cause the stub to behave in a particular way. All the major vendors like CA, IMB, Smartbear supplies some behaviors with their service virtualization tools but we can write our own. For example, a behavior can be used to make a stub act as a market data feed source.
Deterministic	This comprises a series of Receive Request/Send Response or Subscribe/Publish actions that are based on the message used to create the stub.

 

Hope this short blog gives you the details to get insight of types of Virtual Services or Stubs

 

Feel free to share your inputs / suggestions in the comment section below.

 

 

Microservices Integration Patterns - Catering Continuous Deployment Requirements

Hello All,

In this blog we will try to understanding what microservices are and what are the different integration patterns in which microservices are implemented.

Lets first understand what are microservices

Micro Service is independently deployable service modeled around a business domain. It is a method of breaking large software applications into loosely coupled modules, in which each service runs a unique process and communicates through APIs. It can be developed using messaging or event-driven APIs, or using non-HTTP backed RPC mechanisms.

Micro Services are designed to cope with failure and breakdowns of large applications. Since multiple unique services are communicating together, it may happen that a particular service fails, but the overall larger applications remain unaffected by the failure of a single module.

Now the question arises what is the need to implement microservices when we have integrated different systems for atleast a decade now.

The answer is in the below table

Gone are the days when we used to have 3-4 releases in a year. The current business demands us to roll out new features and application more frequently and with very minimal or no downtime.

In the example above, we can see how the releases have changes and now code can be deployed more frequently like the case of amazon where they deploy the code into production every 11.6 seconds

There are different integration patterns using which one can implement microservice and cater to the continuous changing business needs.

We will try to understand it with an banking example.

Let’s assume that we are responsible for building an application for managing a Banks day-to-day operations. Among the many things that our application will have to do, we’ll focus on:

• Managing Debate and Credit cards transaction
• Managing the net banking transaction
• Managing lending transaction

Now, let’s say a customer swipes his debate card. What should our application do? It should certainly update the customers record. It should also initiate the transaction in net banking module. It also makes debate of the debate card transaction and update the available balance in the net banking module

In a monolithic architecture, using a single relational database for the whole application, would be straightforward. In the same process and transaction, we can update the customer record, mark any available balance changes, and insert the customers record into the corresponding table. In case of errors, we can rollback the transaction.

On the other hand, in a distributed microservices architecture, it can start to get complicated. Let’s assume that we have the following services:

• A transaction service from cards, which manages customers transactions records
• A creditCheck service, which manages the customers bankings operations
• An lending service, which manages customers mortgage and lending's

Remember that each service manages its own data, so that when the transaction Service is triggered with a transaction when the customer swipes his card, it not only has to update its own database, but it also has to make sure that the other relevant services are also notified. This is critical for maintaining consistency in the application. But which is the best way for a service to notify other interested services of events or changes?

To understand it more, refer below example with pointers for the different transaction involved and different systems / applications which help implement it.

mS- > JDBC ->  MQ -> 3rd Party

1. User initiates Transaction by swiping Card
2. Card systems confirms the availability of fund with net banking
3. Net banking send the confirmation to process transaction
4. Net banking send request to process notification based on the preference given by user [SMS, eMail] to Notification system
5. Notification system creates entry in audit tables and send notification message to outbound queue
6. 3rd Party system consumes the message, process the message and returns acknowledge message to banking notification system by adding the acknowledge to its outbound queue
7. Notification system updates the confirmation to Cards and Net banking system
8. 3rd party delivers the message to end users with confirmation of transaction

      Database sharing is one the easiest and fastest way of sharing data across multiple services. In our case, we could create a new service, whose sole responsibility will be to keep the three databases in sync. The service could run a batch job every so often, in which it fetches from the Cards database the latest unprocessed transactions. Then, for each relevant record, it could update the other two services’ databases.

      You’ll notice that the new sync service has direct access to the three databases. This means that changes to any of the three services’ database schemas will also affect the new sync service. One of the fundamentals of microservices architectures is that each service/team owns its own data. This allows for development teams to make internal changes to their services without affecting any other services as well as enabling every team to deploy their services independently, with minimum coordination from other teams. By allowing other services to access their database, we’re increasing the coupling between services and teams and introducing friction into the release process. But what would happen to the other services if the shared tables’ schemas changes? And in any case who is responsible for those tables now anyway?

      These two factors alone are enough for rejecting this solution because as a general rule we want to avoid solutions in which multiple services access the same database. Especially when those services are owned by different teams. For example, you might consider having the transaction service update the other services’ databases directly. 

      Probably the most intuitive way of integrating our services would be using REST. Both the Cards, Net Banking and Lending Services can define a dedicated REST endpoint that other services can use to notify them of the transactions. In this case the Cards transaction Service will call these two endpoints when it processes a new transaction.

The advantage of this approach is clear: the implementation details of each service remain private. As long as the REST interface is not changed, each team can make any internal change it needs to its service with minimum coordination with other teams. However, this approach doesn’t come without its own set of problems.

As you probably know, REST works synchronously. There two major downsides to using synchronous communication

Temporal Coupling

We’ll have a problem if either the Cards or Net banking Service happens to be unavailable when the transaction Service sends them a request. What should the Transaction Service do? Rollback? Try again? If that doesn’t work, then what?

The more external synchronous calls our service makes, the more dependencies it has and the less resilient it becomes.

Every time a service calls another service synchronously, it will block it until it receives a response. In our case, our transaction Service will have to wait for both the creditCheck and Credit history Services to complete their requests before it can return its own response to the calling service or client. This might not seem like much, but this extra latency can add up if you’re not careful.

Also beware of cascading effects: when there is long chain of services communicating with each other via REST, one slow-responding service can slow down all the other services up the chain.

Another issue with this approach is that the calling service has to be aware of any external service that might need to get notified when an interesting event happens. We’ll need to modify our credit service every time that a new service will want to get notified of a new transaction.

We can easily decouple the caller and callee services by putting a message broker in the middle. Every time it processes a new transaction, the transaction Service will publish an event to the message broker. On the other side, the Net banking and Lending Service will have subscribed to the message broker to receive events about transaction updates. Each service will receive and process those events independently and at its own pace

The key concepts here are:

The message broker will store the messages safely until they are processed. This means that the transaction Service will be able to process new transaction, even if the net banking or lending Services are unavailable. If they happen to be unavailable, messages will accumulate in the message broker and will be processed once the services are back up

The transaction Service doesn’t need to know about the net banking and lending Services, as it only communicates with the message broker. What’s more, we can add and remove subscribed services just by reconfiguring the message broker, without affecting the transaction Service. The message broker will receive the corresponding message and send it to all subscribed services. This pattern is called fan-out

Events are being processed asynchronously now, which means that the transaction Service can return a response as soon as it has published the event to the message broker. Other slow-working services won’t affect our service’s response time

Subscribed Services can process events at its own pace. If the Publisher Services sends more events than the subscribed service can process, the message broker will act as buffer, isolating both services.

Note that we can have asynchronous communication only when our Cards Service doesn’t need a response from the other two services. This is not the case in cards swipe and all the transaction happens at run time. This is possible in scenarios of Notification only as notification are of low priority compared to transaction of the customer.

As part of the decoupling that we get by using a message broker, the Publisher Service won’t know about the Subscribed Services (and vice-versa). While this brings about several advantages, like we just saw, it also means that the Subscribed Services cannot send a response back to the Publisher Service. It would also be remiss not to mention here that using asynchronous communication makes testing and troubleshooting more difficult .

   Another possible pattern that we haven’t considered here is using files for sharing data between services. If you have experience with ETL processes, you’ll probably find this approach familiar. Every X amount of time, the transaction service could write files containing the relevant events to a common directory (FTP, S3, HDFS, etc…). On the other side, the Net banking and Lending services can poll the directory for new files to process.

Since data is processed in batches, it has a considerably large delay compared to other approaches. In addition the testing of this pattern can be quite tricky .

Microservice Testing Tools

Microservice Testing Tools
SoapUI is an open source, cross-platform testing tool. It can automate functional, regression, compliance and load testing of both SOAP and REST web services.  It comes with an easy-to-use graphical interface and supports industry-leading technologies and standards to mock and stimulate behavior of web services Key Features •       Provides printable, exportable, and HTML-based reports at Project, TestSuite, TestCase, or LoadTest level. •       Comes integrated with Hudson, Bamboo, Maven, ANT, and JUnit. •       Allows developing own set of features as SoapUI Plugins. •       Records, monitors, and displays all the data. •       Supports WS-Security and SSL decryption.	TestingWhiz is a codeless test automation tool which comes with API/web services testing capability. It lets you perform functional, compliance, load testing and mocking of REST and SOAP web services via WSDL interface over HTTP and FTP. It also let’s perform service denial and penetration checks to ensure the overall health of the web services. Plus, it also lets you perform end-to-end testing right from Web UI, business logic, to database and ETL without coding needs. Key Features •       Supports String comparison to validate the API response. •       Helps log API defects through integrated bug tracking tools like JIRA, Mantis, and Fogbugz. •       Generates visual logs and reports of test execution with an emailing facility. •       Allows distributed and parallel execution across multiple machines and nodes. •       Provide Continuous Integration with Jenkins, Bamboo & Hudson. •       Supports data-driven and keyword-driven testing.
SOAPSonar provides comprehensive web services testing for HTML, XML, SOAP, REST, and JSON. It provides functional, performance, compliance, interoperability and security testing with out-of-the-box support for OASIS and W3C standards. Key Features •       Supports vulnerability tests with XSD-mutation. •       Provides comprehensive WSDL and Schema parsing. •       Performs load testing with behavior modeling and multiple simultaneous loading transactions. •       Provides reports in XML, DOC, XLS, PDF, RTF, and RPT formats. •       Integrates with HP Quality Center.	SOAtest is an enterprise-grade tool by Parasoft for testing and validating APIs and API-driven apps. It provides robust support for the functional unit, integration, security, simulation, mocking, compliance and load testing of technologies like REST, JSON, MQ, JMS, TIBCO, HTTP, and XML. Key Features •       Provides end-to-end testing •       Supports 120+ protocols/message types. •       Comes with an easy-to-use interface. •       Helps create sophisticated, extensible and reusable tests without coding. •       Supports continuous integration testing.
TestMaker is an open source tool to test and monitor the performance of the web, web services and SOA application by PushtoTest. It runs on Jython (Python written in Java). TestMaker can repurpose Selenium tests, SoapUI tests, Sahi tests or any tests written in Groovy, Java, Python, PHP, Ruby and Perl into functional, load and performance tests. Key Features •       Uses command-line prompt for functional, load and performance testing. •       Features an intuitive look and feel with a standard multi-windowed IDE. •       Provides a monitoring dashboard to run tests and display live results. •       Allows accessing all Java libraries and classes due to Jython language.	Postman is yet another API/ web services testing tool which comes with powerful HTTP client support. It has an easy-to-use request builder that allows you to write test cases and manage response data and response time for efficient testing and management of API test cases. Key Features •       Allows collecting and organizing APIs in a feature called Postman Collections. •       Facilitates collaboration and sharing of API data and controls with the team. •       Comes with pasting text feature for hassle-free test creation on command line window. •       Allows writing Boolean tests within Postman Interface.
vRest is a tool exclusive for testing, mocking, and validation of REST APIS and web services. It also supports testing of web, mobile, and desktop applications that interact with third-party APIs or HTTP services. Key Features •       Comes with a mock server functionality to create API mock within minutes. •       Provides a Chrome extension to record and play test cases. •       Supports integration with Jenkins for continuous server integration and Jira for bug tracking. •       Facilitates roles and permissions management. •       Allows exporting and importing test cases and reports from external tools such as Postman Collections, Swagger 2, and more	HttpMaster is another exclusive tool for REST web services testing. It helps testers to test the behavior of REST APIs and validate output data in formats like XML, JSON, and HTML.  With its universal HTTP tool, HttpMaster also helps developer simulate client activity and response behavior of an API application. Key Features •       Comes with an easy-to-use and elegant user interface that doesn’t require advanced technical skills. •       Uses HTTP methods such as GET, POST, DELETE etc. •       Provides different validation types and expressions to ease testing. •       Utilizes command-line interface for test creation and execution •       Allows storing all information – API calls and project data at a single place.
Runscope is a simple tool to test and monitor the performance of the API. It helps you verify whether the web service or API returns the correct data and also prompts when things go wrong with the API. Runscope also supports API and backend service testing of mobile apps. Key Features •       Allows creating tests with dynamic data for even complex cases. •       Displays visually-rich metrics and analytics to identify problems. •       Integrates with tools like HipChat, Webhooks, Slack and PagerDuty to notify when the APIs are down. •       Allows reusing and executing tests across multiple locations. •       Facilitates managing tests centrally for better team collaboration.	Rapise is a robust automation tool with powerful and extensible features. It is based on an open and flexible architecture for rapid functional testing of REST/SOAP web services. Rapise also provides support for testing web applications built in Java, .NET, Ajax, Silverlight, and Flash. Key Features •       Uses HTTP standard methods such as POST, GET, PUT, and DELETE. •       Allows storing prototyped requests against a specific web service. •       Contains built-in REST definition builder and object library. •       Comes with powerful, integrated reporting capabilities. •       Supports cross-browser testing and parallel execution.
WebInject is a free tool for automated functional, acceptance, and regression testing of web and web services. It is a command-line tool and is based on Perl, which simplifies the execution of tests since it doesn’t require one to spend time at the command prompt. Further, it has no IDE like user interface which means, the tests are written outside of the WebInject UI. It can run on platforms that have Perl interpreter. Key Features •       Provides real-time results display. •       Monitors system response time. •       Supports different usage – as a complete test framework and as a standalone test runner. •       Generates reports in HTML and XML formats. •       Allows integration with other system as a plugin for external monitoring.	Storm is another open source tool by CodePlex for testing web services written in Java or .NET. It currently supports only SOAP web service. Key Features •       Allows testing multiple web services from a single UI. •       Helps edit raw SOAP requests. •       Allows invoking web service methods that contain complex data types. •       Supports testing of WCF apps.