Software Testing and Automation Testing

Automated software testing vs developer testing

Now a days the software development life cycle needs aggressive regression testing.

Difference between test specification and test plan

You can see there is quite good differences we have between test specification and test plan

Testing EJB’s use openEJB

Testing Ejbs requires a container which gives all the required conditions to deploy and use the deployed bean. OpenEjb is open source frame work which can be used to test all the business methods.

What is ETL Testing?

Etl  testing is testing the transformation done of source data before moving it to the target and also validating the target data.

What is a test case?

Test case is set of input values, execution preconditions, expected results and execution post conditions, developed for a particular objective or test conditions, such as to exercise a particular program path or to verify compliance with a specific requirement.

What is a bug?

In Software or computer, “bug”  is an error, flaw, mistake, failure, or fault in a computer program that prevents it from working correctly or produces an incorrect result.

Differentiate between Quality Assurance (QA) and Quality Control (QC)?

J Unit Testing Basics

J unit testing is very much related to the Java code.

How to break the software

How To Break Your Software

“If you can’t make something not work, keep on trying.”

We can break the software by using the following points:
1) Understand the whole application or module in depth before starting the testing.
2) Prepare good test cases before start to testing. I mean give stress on the functional test cases which includes major risk of the application.
3) Create a sufficient test data before tests, this data set include the test case conditions and also the database records if you are going to test DB related application.
4) Perform repeated tests with different test environment.
5) Try to find out the result pattern and then compare your results with those patterns.
6) When you think that you have completed most of the test conditions and when you think you are tired somewhat then do some monkey testing.
7) Use your previous test data pattern to analyse the current set of tests.
8)Try some standard test cases for which you found the bugs in some different application. Like if you are testing input text box try inserting some html tags as the inputs and see the output on display page.
In other words:
• Check the data input validation
• Adopt the testing technologies like Boundaries value analysis (very big values, very small values)
• Missing error handling (causing the system loose connection). Disk full etc.
• Interface errors detected only once the system is tested end to end
• Check for the valid & invalid characters
• Testing the text fields, Drop down list & combo boxes by empty values in case of both the mandatory & non-mandatory fields.
• Testing the drop down list & combo boxes by without selecting any available values in case of both the mandatory & non-mandatory fields.
• Testing the text fields with the multiple combination of the test data
• Sometimes testers finds bugs, by crashing the system while doing “this and that, bla, bla” things.
• Step through all scenarios provided, basically walking through the application and ensuring that it does what is supposed to.
• Test “normal” system behavior an performance
• Because most of the functionalities does not offer only forced moved (wizard like), shall be tested “unusual” flows resulted from abnormal combinations of operations and unusual scenarios resulted from also unusual combinations of flows.
• Try unusual data inputs (larger size, special characters, others)
• Perform stress, Load & Performance tests: intensive processing

Additional Information:
The first rule of thumb that I have is: document everything. The reason is because “it is not valid unless and until you can repeat it”: If you find a problem during your testing, try to repeat the procedure that led to the problem; if you cannot replicate the problem, it may have been an anomaly and not a real problem. Furthermore, if you want to be able to compare test results (say from version to version), you must run the same procedure, otherwise the results are not comparable.

If you start testing without a test script or documented test procedures, at least have a plan – a “roadmap” — to make sure you do not go off course; and take notes of what you are doing and the results you find along the way (in other words, document everything).

Be careful that you do not go off course and test something that may not have needed testing (or very little testing); focus on testing what is appropriate and what will be truly effective. Using the example of the family car, you would not want to spend all time and resources trying to blow up the car using any method possible. Anybody can break the car by placing enough explosives in the right places, but what does that get you? All you have done is proven that the car will break. But was the car designed and built to survive such an attack, and how likely is it that a normal family car will be subject to such an attack? Try to break the product (the car or the software) only in a manner that is appropriate to the purpose and design of the product.

Finally, do not rely solely on testing the purpose or intent of the software and hope that you will find all possible problems. Also test the Architecture/Design and test the Code/Build. What would otherwise be a silly coding error could be the cause of a catastrophic problem that may not pop up until normal use by the user – too late. Finding the cause (and location) of that problem may be almost impossible.
Sometimes it’s all depends on the type of the application.
But general I try to feed the application as much data as I can. Make the application compute as much as I can, like sorting lots of data while turning the network connection on and off.

Other things I do is misusing fields. Try to generate reports with a lot of data and cancel the reporting process while in progress. And try again as soon its stops.

Again it depends what kind of application it is.

How to Break Software is a departure from conventional testing in which testers prepare a written test plan and then use it as a script when testing the software. And flexibility is needed in software projects in which requirements can change, bugs can become features and schedule pressures often force plans to be reassessed. Software testing is not such an exact science that one can determine what to test in advance and then execute the plan and be done with it. Instead of a plan, intelligence, insight, experience and a “nose for where the bugs are hiding” should guide testers.
QA engineers are the bridge between end-users and programmers, so they must understand the problems that users can encounter. Early on, an entry-level QA position involves simple testing. For example, a user may need to input a password into a Web site, which must be between five and ten characters. The QA engineer must then test how this will work if the user types a space, a dot, a dash, or a comma.

Software quality assurance engineers and testers oversee the quality of a piece of software’s development over its entire life cycle. Their goal is to see to it that the final product meets the customer’s requirements and expectations in both performance and value. During the software life cycle, they verify (officially state) that it is possible for the software to accomplish certain tasks. They detect problems that exist in the process of developing the software, or in the product itself. They try and make things not work (try to “break” the software) by creating errors or combinations of errors that a user might make. For example, if a user enters a period or a pound sign for a password, will that break the software? They seek to anticipate potential issues with the software before they become visible. At the end of the life cycle, they reflect upon how problems or bugs arose, and figure out ways to make the software development process better in the future.
Testers must keep at testing, exploring and trying to unearth issues. Bugs may appear intermittently or under certain conditions. Testers should not ignore or give up, but instead try different scenarios to reproduce the issue. Software Testers must also realize that all products have bugs. If a product looks to be free of bugs, it just needs more testing to find issues that current tests haven’t looked at. Testers should always be in the pursuit of bugs and view every defect found by a customer as a slip or gap in their tests which must be addressed immediately.

Of historical note on breaking software There was a team inside IBM in the 80′s called the Black Team. They had a culture of saying that they had “succeeded” when they broke the software to encourage the identification of defects. They considered their work a “failure” when they failed to find/identify any faults in the software. On the other hand, the outcome of their “failure” was great reliable software…

So systematic testing trying out all possible combinations is necessary if you are up to breaking a software.

Compiled by Nagaraj U

Selenium IDE

Selenium IDE is firefox plugin and this selenium IDE is used to record the application and put the verification points.

Selenium IDE has an options to convert the the basic HTML format of recording to any language unit test code like Java, Ruby or the PHP etc.

To download the selenium IDE plugin click here

After download the firefox selenium ide plugin install it and go to tools you will see an option Selenium IDE. Click on it. It will open a the selenium IDE in the recording mode.

To use Selenium IDE you need to fill out and start recording the behavior of the application. for example i am working on testing the idomain-name.com application. we  need to enter the url in the Base URL fileld and then click on the record button and then it will be in recording mode.

Then we need to go to the web application what we are testing and start working on it. and we need to add or record the checkpoint called as verification points. once the recording is done then we have to stop it. We can observer that the Selenium IDE has recorded the events what we have accomplished in the application. All the instructions of recording has written in the HTML. We can use these instruction as html or convert them to any language you know like Java, PHP, Pyton etc. But one importent thing to notice here is the Selenium IDE only runs the HTML instruction So make sure that when you save the file then you are saving it in the HTML format.

How do i test the recorded selenium HTML instructions.

??