Test Strategies for Testing Automatic Resume Submission Service

Few years back, we have developed an Automatic Resume Submission Script.

i-e If a job seeker enters his Resume details in one place, the script will automatically create User Accounts in many U.S job sites for him, and it will automatically post his Resume details in all these Job Sites.

This Kind of Script development is NOT an easy task. It involves lot of complexities. And, we haven’t started doing it properly. Initially we did similar script for one particular customer as a custom development, and later we enhanced it further to bring this Automatic Resume posting script.

Since, we are a small Team with limited budget, right now we are doing some kind of AdHoc testing only.

I am writing this post to initiate a discussion about exploring various Testing Strategies suitable for improving quality of this Automatic Resume Posting Script without requiring more Resources and Time.

Before discussing Test Strategies, let me give some details about this script development.

The important Steps involved in this kind of script development are,

– Automatic resume posting can be done in two different ways. One is, using javascript for auto filling the Forms in the job sites by accessing the DOM of the web page in the Client Side (i-e User’s browser). The other way is, posting the job seeker resume details to the Job Site using php cURL at the http protocol level. (i-e From Server where the Script is Hosted)

The second way (i-e php cURL) is involving some risks. Since the data for all job seekers are getting posted to job sites from same IP Address (i-e same server), the job sites may block that IP address if they thought that it is a DDoS attack.

But I came to know that almost all job sites are encouraging to automatically receive genuine Resume details of Job seekers to increase their customer base. That’s why, they are allowing continuous posting from particular IP. So, I decided to go with the php curl approach.

– First we created set of Function libraries for posting data in various situations (e.g GET method, POST method, with SSL, etc). Unit Testing of these functions is done by hardcoding the resume details in php files.
– Then, we did mapping of various fields of various job sites in mysql tables. (e.g The Input Resume will say experience as 3 years, but one job site will be having option for specifying experience¬† as “2-4 Years”, and another one will be having the option as “more than 2 years”. We need to map them manually onetime in mysql tables)

– Once after completing Function library creation and Job sites Fields mapping, we started creating php files for each job sites for getting the resume details and mapping details from db and post them to the corresponding job site. Live HTTP header firefox Add-on helped much to do this job. Some job sites will he having Captcha entry. The php script is developed to show the captcha image while doing resume posting.

– Then, created few php files for integrating posting of all job sites and for updating the status of account creation (account creation may fail if the user name already exists in particular job site) and resume posting process.

– Then, created user interface for allowing the Job Seekers to make payment, use discount codes, see reports, do Auto login into job sites, etc. And, created Admin Interface for managing users and resume posting.

I think I have given enough details about the background of this script. Now, let us start discussing about Testing this script.

The important challenge of Testing this Resume submission Script is, we can NOT have any separate Testing Environment. For testing our Time Sheet application, first we setup timesheet script in our local machine, and we will move the code to server only after completing the testing in local machine. We can do whatever we want to do testing in the local machine. But the samething can not be done for testing the Resume submission script. Even if we setup the script in local machine the script need to post the details to the external job sites only.

So, we can not Test the script with junk data as it will spam the job sites.

The Next challenge for Testing the script is, the difficulty of choosing appropriate Test data. As I specified earlier, data Mapping plays important role in this script. So, if you decide to test the script with various test data to test the script including the quality of mapping, we will end with thousands of test data. So, it is NOT feasible to test the script completely by giving Test data. The only workaround is, we need to manually check the mapping in mysql table, by going thro’ the lot of mapping data. It is really difficult task and we will be missing to find some incorrect mappings.

Almost all job sites are updating their user interface frequently. Some job sites are getting closed and some of them are acquired by huge job sites. Some jobsites change their CMS completely. So, the script needs to be updated frequently.

As part of the regression testing, we need to find some way for testing the entire script whenever we update the script. (either the coding or mapping). I think just doing adHoc Testing is NOT enough.

Right Now, I am thinking one approach for testing the script with real data. Instead of testing the script with junk data, I plan to allow the Job seekers to use the Resume Posting Service at very cheap price, in return they need to inform us if they find any issue in the job postings. I am working on creating some Special Discount Codes for the Job Seekers who are interested in joining this plan.
This approach won’t do any harm to the Job seekers. Because during this phase, our Team will be manually checking the quality of resume postings by logining into the each and every job site once the script completed the automatic posting. We can easily update any data if our Team find any issue.

Similarly, I am Planning to sell few copies of this entire script at very low price to the people who are showing willingness to cooperate with us to increase the quality of the script and to maintain the quality of the script at long run even if the job sites are getting changed frequently.

Let me see whether this approach works or not. Anyway, I believe there should be some other ways to test the script properly. You can share your thoughts thro’ the comments.

Update: I have tried above approach, but it didn’t work out as most of the script buyers didn’t spend time for reporting the issues. It seems they bought the script to get details about how we developed this script so that they can use the same concept for various of business. So, I had come up with this investment plan.