Friday, May 31, 2013

How to manage Crowd Testing and Crowdsourcing? Addressing Major Managerial Problems

Crowd Testing is a new paradigm in the quality driven space of software testing. There are a number of predictions and pros stating that this type of testing might become immensely popular and would be able to acquire a profitable market share in the software testing industry. On the contrary it is yet to be seen any significant success stories or deliveries achieved via this innovative branch of crowdsourcing industry. Without denying the fact that this area of software testing is still in its so called adoption oriented infancy rather it has grown significantly based upon its technology/infrastructure driven maturity level, yet we have to keep a keen eye on the expanse or demise of the same.

Whenever a new technology comes in everybody starts to talk about its advantages and benefits it bring along. But as I am closely related to this field I felt to do otherwise I would like to point out more cons or problems that we need to manage or deal with, so that Crowd Testing succeeds and can truly stay put on the variety of beneficial claims laid down by its pioneers. 

The major managerial problem this crowd testing brings can be summed into these categories: 


  1. Proper Dissemination of Testing Requirements into the Crowdsourced Team of Testers
  2. Skill identified or Experience based Work Allocation
  3. Concrete Business Clarifications Mechanism
  4. Reduction of crowdsourced resources based liability risks and mitigation plan
  5. Irrefutable Wages Delivery Mechanism
  6. Enabling of testing technologies for mobile, business intelligence, VPN etc on crowd testing environments
  7. Business Confidentiality & Security Aspect Justification for Cloud and Crowd based software testing model
  8. Defects Validation Mechanism 
  9. Synchronization Mechanism of crowdsourced testers' (globally located) work for Test Reporting (For periods when defects are scarce)
  10. Crowdsourced Resource Retention
  11. Idiosyncrasy of Deployment Schedules & Stringent Timelines
  12. Ground level binding of Crowdsourced Testers with country specific legal contracts.


The above stated managerial problems presents a challenge to Crowdsourced Testing or Crowd Testing firms/organizations. There might be several scenarios where Crowd Testing companies will try to take these challenges one by one and address them by their own business model or implementation methodologies. Rather the one who can get rid of them all will stand out to be a winner. In my following blog I will suggest my own strategies to deal with these. So till then I invite all like minded and fellow professionals to find a way out and leverage the pros and diminish the cons to give a profitable business solution out of Crowd Testing and Crowdsourcing.

Thursday, May 23, 2013

Future of Software Testing - A Practical Approach for Service Industry

Software Testing of the present day scenario is either manual or automated wherein efforts are invested to get the desired Quality Analysed Validations or Verification based results. The future of software testing is an area not much thought of; in terms of technology based improvements or innovations. Rather people and organizations have largely invested on improving the overlay of various test management/delivery related processes. 

The problem with the current approach is that we are able to sustain and also grow in the respective business but what about threat and sustainability issues if an autonomous test mechanism is developed. Large organizations are focusing on creating capabilities and nurturing software testing talent on the basis of the software that is ready to be tested or has been tested once in its life cycle or is currently under development to be tested. But what about if the technology or principles on which software testing itself is based upon will it never change? Should it never evolve? If we will continue to linger upon service providing based on the eons old manual and software solutions will this area ever advance?

In order to get rid of these age old techniques new approaches has to be considered and developed plus adopted for this technology area to grow. There are 4 approaches out of which I do not foresee any clear winner or rather I should say I cannot predict which one shall be adopted more. 

Starting from the first one is: AI based Object Identifiers with Metadata based Action Definitions. These Object Identifiers will go through  any -> to-be-tested application regardless of the environment via which it is hosted. It will then identify all the user actionable and non actionable fields and make a classical approach based repository. Now the tool will be already be equipped with AI based Metadata Action Definitions which will enable the tool to process and analyse the objects to create test actions. When the Test Analyst will complete the analysis of the same it will execute the same and hence the software testing will be completed with proper capture of Test Actions (Evolved out of Test Design) and Test Results to generate Test Reports in a matter of minutes. This tool can also hold the test analytic from the current test to re-use the same test actions in case similar kind of application comes for any test assignment. 

Second Approach is: In current scenario (Laughable Fact) the business requirements gathering is not based on any technology framework which makes it a stenographers job apart from the understanding of the business imperatives/impacts/functionalities etc. which is a specialist's job. The business requirement gathering too should follow a industry standard and all the business logic collection should be done based on metadata or object identifiers based tech. This is will not only enable the testers to easily verify their findings rather reading the functional specifications documents as boring novels. But also enable the developers to easily follow the business logic as per business definitions logic. In order to validate the test actions itself business will also create a Requirement Documents in the Metadata Identifiable format to verify the test results. 

Third approach can be: AI Based Object Identifiers Embedding in Source Code. This approach will enable a self inclusion of Test Actions identifiable Object Identifiers based Metadata inclusion into the source code itself at the time of development. In this case it would be easy for the developer to code the application as per the business requirement and Unit Test it also with negligible efforts.

The fourth or the final approach is a bit tedious and can be less popular: Usage of AI based Object Identifiable Neural Network derived Test Actions Repository. In this approach a tester can either enter the test flow or test actions using his/her conventional test design and then see the tool identify the test actions and execute them. Or it can be run in a learning mode wherein the tester can record how it tests a particular application and hence can train a neural network to test the same in subsequent test phases. 


In order to get algorithms or technical consulting on the above ideas please comment on my blog or send me mail :) 

Bad practices for a Software Test Engineer

People mostly talk about the good and the best practices but it is also important to know the worst or the bad practices which a Software ...