Do not blame it on server. Quite often performance tester blame it on server while scripting in the lower environment such as pre production, performance testing environment, or functional testing environment. I would like to share my experience, do not blame it on server while writing scripts if you faced any HTTP errors. Read on.
Web Application debugging
Most of us write scripts for web application; it can be modern web applications like Netflix, Airbnb etc or legacy applications which built on traditional 2 or 3 tier architectures. In many occurrences, we often tend to contact environment team or the person who is in-charge to start/restart/stop servers. Stop here. Do not contact them unless it is actual issue in the server while writing scripts.
Do not blame it on server
Before you contact them, make sure that
environment is really down. You can create some utility to get the status or you can ask the infrastructure team is there any such utility available.
When I work on any projects, very first, I check for the needs. Ask your project manager to list out the utilities available. This will give you a chance to develop macro, shell scripts, JMeter or LoadRunner script to automate the daily tasks.
Whether any updates are going on in your scripting environment. Often, server patches or updates runs on weekends, if you come to office on Monday morning, definitely you might face issues in the environment. It is likely due to patches/updates screwed your environment. Check for patches/updates email in your deleted email folder.
There is no environment downtime going on
Once you make sure that there is no issue in the environment, it is time to debug your scripts. Below is my approach to debug any HTTP related errors.
Analyze the error message in the output log. Try to replicate the error manually. E.g. if you are receiving any HTTP, check for the page in the browser whether you are really getting HTTP error.
If you are getting HTTP errors manually then there is an issue in the code. You can raise a defect or contact functional testing team for more details on the defect.
If you are not able to replicate the error manually, then it is time to drill down the issue further.
Debug the HTTP request in your script. Check for the below particulars.
Query string parameters
Check for the previous request and response details and compare it with manual transactions.
Check for the authentication credentials in your script.
Check for the test data in your script
Check for the format of date, time, social security, credit card, dynamic string, and all sorts of test data.
Check for the SSL options or its configuration.
Check for the certificates details.
Web Services debugging
When compare to web application script, debugging is quite easy in web services scripts. Please make sure the following particulars.
Endpoint is really available when debugging
Check for the protocol, URL, method, test data, certificates and request payload
Check for the headers such as content-type, auth etc.
Use other tool such as SOAP UI, JMeter to reproduce the issue
Use Chrome extensions if your enterprise allows the usage of browser add-ons
Instead of blaming the servers or environment team, make sure that you validated above points before you send email or log the hours in the downtime tracker. Please share if I missed any other points and your experience in the comment section.
Hi there! NaveenKumar N is a passionate and experienced Performance Test Analyst based in Chicago, IL, USA with the skill sets in Manual Testing, Test Automation, Performance Testing, and Web Services.
He loves to learn and experiment new trends and models in Software Testing.
Please stop by at his personal blogs: NaveenKumarN.in, PerfTractor and Giftt