Monday, March 30, 2015

“IoT” a challenge for Security Testing

“IoT” a challenge for Security Testing: Most of you might have seen the movie Die Hard 4.0. The plot is about the antihero who does a cyber-crime (a “fire sale”) by a hacking maj...

Saturday, March 28, 2015

QA Design Gurus: Let's hack Javascript

QA Design Gurus: Let's hack Javascript: Well yes, most of the applications are HTML5/CSS/JS based and it’s quite easy to build them too with the kind of libraries/frameworks avai...

Friday, March 27, 2015

QA Design Gurus: Node.js ! What is for testing

QA Design Gurus: Node.js ! What is for testing: Node.js has become extremely popular for its ability to run javascript in any platform with a Google chrome runtime engine for windows,unix...

QA Design Gurus: Memory Utilization - Am I seeing it right

QA Design Gurus: Memory Utilization - Am I seeing it right: While doing Performance testing, in addition to response times we need to understand how much OS-Resource our system consumes. OS-Resource...

Thursday, October 24, 2013

Automation on Distributed Infrastructure

In a real-time environment, multiple applications run on multiple machines/servers. If it often a requirement for for distributed testing  which was kind of necessary for both Functional as well as Performance Testing. In the era of cloud and Agile development we cannot expect our regression tests to run for hours/days. Focus should be shifted from how often you run your tests to how soon you want your tests to run.

In my day to day testing , I have always felt the need of a framework that would help me running my functional or performance tests on the servers that run on multiple machines and interact to each other effortlessly. This need has driven me to look for a lightweight framework that would help me to communicate to any of  the servers in my distributed environment without adding much overhead on any of them.

After looking at different existing frameworks like plink,pscp,RPC,RMI,XML-RPC,Pyro etc, and then my focus went on to RPyC(Remote Python Calls). Two things that attracted me at-once when i looked at this framework were its Symmetric behavior and lightweight server.

This is what RPyC say about its features:

  • Transparent - access to remote objects as if they were local; existing code works seamlessly with both local or remote objects.
  • Symmetric - the protocol itself is completely symmetric, meaning both client and server can serve requests. This allows, among other things, for the server to invoke callbacks on the client side.
  • Synchronous and asynchronous operation
  • Platform Agnostic - 32/64 bit, little/big endian, Windows/Linux/Solaris/Mac... access objects across different architectures.
  • Low Overhead - RpyC takes an all-in-one approach, using a compact binary protocol, and requiring no complex setup (name servers, HTTP, URL-mapping, etc.)
  • Secure - employs a Capability based security model; intergrates easily with SSH
  • Zero-Deploy Enabled – Read more about Zero-Deploy RPyC
  • Integrates with TLS/SSLSSH and inetd.

For me the charm of RPyC  lies in being Symmetric and Transparent. This allures any developer who is working on a distributed environment and shows an illusion as if everything is running on a single machine. The new features of RPyC also has publishing functions as services which can be accessed based on the permissions provided while exposing those services and automatic registration of those services. This helps users to look for the service availability on his distributed servers and send his request to the corresponding server.

This coolest stuff tempts me to create a new framework that helps anyone to run his tests on a distributed machines without any configurations or setup.
Hope I do it someday :)

Reference:
http://rpyc.readthedocs.org/en/latest/



Monday, September 2, 2013

What's next in Testing

Few years back Software testing was given very limited importance, but now things have been changed and people have worked on different technologies of Testing. Automation & Performance has always been the appealing factors for people to work which gave tester a privileged identification.

With the change of this stint, software testing have got more new branches like Mobile,Cloud etc. Testing was kind of imperative on different cloud infrastructure provider platforms and automation suites were run on them. Things were never easy, but with the accessibility of different technologies and API's things the pavement looked better.

Considering all these facts, what would be the next level of technology or a tool a software tester would dream of or would really like to develop for his ease ?

Any ideas ?

Sunday, June 30, 2013

Importance of Verticals in Testing

Most of the Software Industries work on the base of  developing Software on Industry Verticals or Business Domains. Well this works to develop Software Applications/Products but the questions that strike my mind as a Software Tester while testing any Product or Applications are 


  • Are we testing it well ? 
  • Is our testing Complete ? 
  • What makes our testing complete ? 
  • How to test something new ?
  • Have I missed any thing ?


Well we can define QA Process to achieve/validate  most of the things, but what do we do when we try to test something new. To answer this I again posed this question back to myself, how good am I in my testing domains ? Well the answer is, one cannot be the best in versatile domains of Testing. We might have exceptions, but how good is the knowledge if it cannot be shared or nurtured gradually. The idea that came out of it is "Verticals in Testing". Verticals are required in Software Testing where resources can be groomed in the respective domain and will be updated with the latest trends or technologies specific to that domain. Team involved in it need to do lot of research but at the end the result will be fruitful. The team will be highly qualified to handle any kind of issues and will set a benchmark for the QA who need to perform testing  in such domains.

 "Verticals in Testing" has always been a debatable topic in the Software Engineering, where  most of the organization thinks that it has very less returns. I think it as an opportunity for an organization to get updated with the newest trends, always ready to gear-up to work with the happening technologies which might help them to walk with the future. 

Let us look at the Positive and Negative Points on having a "Verticals Unit in Testing".

Benefits: 

1. Enough research is done on the respective Testing Domains(Performance, Automation, Database, Security etc) which will help any new Project/Product to start work without investing more time for domain specific testing.

2. A common set of best practices to be adhered to throughout the product teams whose outcome will be a Quality Product.

3. In the software life-cycle the bug found at the early stages will cost very less to fix rather than the one that is caught at the later stages. Verticals Provide us benchmark practices which could be validated/tested with the Product at the stage of design/Architecture.

4. New Horizontal's can easily be adapted or welcomed if the so-called Vertical Tree is Strong. As an example if we consider Mobile as a Horizontal, effort is only required to test the Mobile Domain but not on how to automate it, how to do a Performance Testing or how to perform a Security testing. As an expectation the Vertical unit community have already done their research and their contributions can be readily accepted, which will reduce the burden on the testing team.

5. As a Software Industry/Product based Company the Vertical unit will have better grip on all the products which incorporate the best practices of the Verticals development. This would help the new Products/Project to be reviewed by the best practices that are followed by the Organization.

6. People will start valuing the QA as the standard gets polished with the strong basics.


Disadvantages:

1. Not all organizations would like to maintain or spend money on the teams which do only research and support the teams on the corresponding domains.

2. Limitations on the implementations of the Vertical Domain best practices. Every Product/Project works in its own way and all teams might not agree with the way the earlier teams designs.


Overall the benefits looks more promising, but the disadvantages also lay an important factor for the business. To overcome it,  the Vertical Testing teams need to be dissolved in the Product/Project areas and rebuild back on priority basis. 

Value of the Software Tester is always recognized when his words makes sense. His words will make sense when his mind is trained to visualize the design and applies his domain skills on it. Verticals Testing enables this capability and elevates the caliber of a Software Tester.