Older Browser compatibility for testing legacy applications in a ReadyAPI functional test
We are looking to use ReadyAPI to test some of our legacy applications. These applications often require to be run using an older version of a browser. Eg. IE 7.0.
We have attempted to pass a user-agent header that is a compatible browser version to test the application however we are recieving an error on our application which states that an older browser version is required to use the application in the request response.
This is the header we are passing:
User-Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 10.0; WOW64; Trident/7.0; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Zoom 3.6.0)
Is emulating an older browser version something that is supported in a ReadyAPI functional test? And if so how can we go about implementing it.
I don't know the answer from personal experience here, but I'm going to use logic to answer the question.
the answer to question i s "yes", and the second part of answer is "use fiddler to capture existing traffic that works, then tailor your ReadyAPI requests you've setup to emulate the web requests"
OK - reasons for my answers above.
If you think about it - the listening endpoint is NOT cognizant of the application that is sending the request unless there is a User-Agent header.
If you think about the contents of a web request - you have a payload, a URL (with URI/Query/Matrix parms) and Header parms. That's it - nothing more than that - so as long as you are emulating a working request by reproducing the setup in ReadyAPI to match a working request - then it will be successful.
Your listening endpoint doesn't know it's ReadyAPI! or SOATest or Postman or Katalon or JMeter or whatever (well - it does with Postman cos it always adds in the User-Agent header by default) - but unless you add in the User-Agent header - the endpoint has no idea what the source of the actually request is.
SO - I suspect if your ReadyAPI requests aren't working correctly - it's likely the Headers aren't set as the listening endpoint expects - so likely the User-Agent, but there could be some additional Headers expected that you're not including in your ReadyAPI request.
In this case I'd use Fiddler to capture the genuine traffic (capturing the RAW of the Request) and then i'd update my ReadyAPI request's Header listing (and values) to reproduce exactly the genuine web request that works.
the above is a total guess on my part - but using logic? I think it might be the right answer...... 🙂