Test Script Definition:
A test script in software testing is a collection of instructions or directions that will be performed on the application or system under test, to test that the system functionality works as expected. There are different means for executing test scripts. Manual testing. These are all the more ordinarily called test cases. Automated testing.
Each of your Test Scripts will be separated into Test Steps. That is to say, there will be orderly instructions, saying what to do, and what ought to happen.
The format or the structure of a test script or software testing cases is generally as follows:
Test Number:
To keep your Test Steps all together and to give a perspective when you discover a defect, e.g. “It happened in Test Step 6”
Action:
This action is to be performed by the tester who is going to execute the test script.
Expected Result:
This is what should happen with the output or the result when the desired action is performed. In simple words, this is the way the system under test should function.
Actual Result:
This field is also used many a times. It shows the actual outcome or the output after an action is performed. It is tallied with the expected result written in this column. If it does not match, then it is said to be a defect.
Every Test Step ought to be a sequential continuation of the past Test Step. For instance,
Test Step Action Expected Result
T1 Please Enter User Name User Name field is populated
T2 Please Enter Password Password field is populated
Login button enabled
T3 Press Login key User is logged in to application
There are two primary fields of thought as to the level of how much detail the Test Steps ought to have. The first is like the case we just gave, where every progression of the login procedure is indicated, with the consequence of that progression additionally determined. The other is that lone a general direction should be given, for instance like just saying that “User is logged in”.
Both methodologies have their advantages and disadvantages. The more detailed methodology is additional tedious both to write and to execute. Be that as it may, it can be executed by somebody who has almost no earlier learning of the application.
Other Tester’s, who are acquainted with the application, can most likely do these things without pondering it, yet you can’t. In this circumstance, orderly instructions would be extremely beneficial for you.
In their non-existence, one would require instructions in how to do these things. One choice is to ask another person. The upside of this is the point at which you have begun another job as a Tester, conversing with individuals is great and builds up a decent association with your new partners. The drawback is that they will likely be occupied, and since the vast majority are not regular educators, they would most likely not show you exceptionally well. This is another element that prompts the feeling that Testers don’t know much.
The other alternative is to peruse the organization documentation on the methodology – the main disadvantage with this is, in our experience, most organizations don’t have it – “we haven’t got around to producing that documentation”, “we’ve been meaning to do that”, “we’re always so busy”, “maybe that’s something that you could do”, etc, etc.
What’s more, the last choice – which is likewise the most well-known – is to simply fight through until you have worked it out yourself without the help of anyone else.
When you turn out to be more acquainted with the application, you as well, will have the capacity to raise an order, make a contract, issue a refund, without point by point guidelines.
When you achieve this stage, you would most likely discover the regulated guidelines to be arduous and tedious, and would just naturally give each of them a Pass until you achieved the part of the application that you expected to test.