Software Quality Assurance & Testing Stack Exchange is a question and answer site for software quality control experts, automation engineers, and software testers. It only takes a minute to sign up.
Sign up to join this community
Here is a link which I came across while looking for answers
But here, only technologies have been mentioned. How could you discern between different technologies when you are going to test it functionally?
I was asked this question in an interview recently.
OK. So, at least from my point of view, those are two separate things.
1) Testing the the things that feed into the website. Here, you care about the language of the helper program if you’re doing function testing, because you need to be able to understand the interfaces that the program is using. Ideally, you can (and the program should be architected to allow this) be testing interfaces to the databases or whatever backs up the data. You don’t want to be doing this via a web browser/web automation tool, since that adds layers that you probably don’t have much control over.
2) Testing the web site itself. Here, you shouldn’t care about the backend processing; that’s invisible (or had better be) to the web browser. And here, ideally, you can use web automation tools to do the testing. Now, here, you might want to test for known problem areas that might be dependent on the underlying tools (SQL injections, passing in invalid data via custom http headers, cross site scripting holes, etc), but the language that the backend program that’s providing the data that builds the website is probably irrelevant; here you’re testing the end-user experience.
If you’re trying to do both of those things at once, in my opinion, you’re making a mistake, as there are types of testing that you can do if you’re testing the backend program that you can’t do from the website, and vice versa. And both of those tests are going to find different sorts of performance problems.
The website itself should not matter much which technologies were used from the front end UI points of view, however there will be differences behind the scenes depending on languages and frameworks.
I would make the following distinction in terms of a programming position:
This is testing the functions and code used to build the application behind the scenes, frequently using similar languages. If it's built in Ruby on Rails it's using Ruby and quite likely using rspec for unit tests and capybara if there are UI tests. So you'd want to up up on those technologies.
This is testing the final product, usually the web site. This sort of testing doesn't care what languages the backend uses other than some estoric patterns that languages and frameworks sometimes have for mistake but these are subtle. One example: Ruby on Rails where forms that flip between states can have issues and also error reporting can be wring if incorrectly assembled.
Instead, black box testing focuses on what the end users is trying to achieve and the functionality they wish to see, regardless of the methods used to assemble it.
To add into what Kevin has mentioned:
For #1 (Internal/backend), the programming language matters because it will affect what kind of testing tool available for you to test. For instance, if you want test the database functionality, you might have to choose different unit test framework (JUnit/TestNG for Java, NUnit for .Net) and mock frameworks.
