Common Cross Browser Issues – Need to be tested

–Overlapping of Layout and Elements.
— Rendering Issues.
— Element out of Bounds or exceeding its container or not displayed.
— Inconsistency of third party plugins.
— Different Font Sizes across various browsers.
— Changing size of Elements across browsers.
— Alignment Issues.
— HTML Errors and broken pages.
— Browser Bugs Little known errors cause big problems.
— Inconsistent Popups and other message boxes across browsers.

— Page Loading time across browsers – are a few worth a mention.

Situational testing

Every organization, every system and every project is different, so every test project requires a unique approach. Situational testing offers various forms of testing and allows you to complete your testing projects flexibly, at the lowest possible cost and in the shortest possible time.

Among the forms of testing recognized within Situational testing are factory based testing, global scripting, session based testing, bug hunts, test tours and free style exploratory testing. Testers choose one or more of these test forms, depending on the organization, project and system. This way, Situational testing encourages you to approach testing in a flexible, structured and pragmatic fashion. With Situational testing you achieve better results than using a single specific approach.

What is Fuzz testing and Tips

Fuzz testing is a kind of QA-Testing which involves inputting some invalid data into the program in order to monitor it for crashes and ensure its security.

Security contributors and researchers use a lot of different fuzzing approaches on Firefox.

Tips for fuzzing on Firefox.
A–>  Nightly Tests
If you want bugs identified earlier, mind that the nightly builds directly correspond to the central Mozilla’s HG repository, as well as always contain the latest features prepared for release. These offer the great opportunity for testing changes much earlier.
B–> Mini-dumps
It is not that efficient to run Firefox under the debugger for fuzzing. You can instead try the mini-dumps Firefox’s crash reporter provides. By means of the mini-dump_stackwalk tool, it’s possible to obtain the stack trace from a dump for further triage. An advantage of such an approach is its working on all the supported platforms.
C–>Special Builds
Builds of regular release are not good for fuzzing since they lack some significant features debug builds have. Debug builds, for instance, have a range of enabled memory invalidation routines. Another good thing in debug builds is assertions. While all the assertion failures report bugs, some assertion types are especially capable of indicating security holes.
D–>Multiple Instances
By using multiple profiles you may in parallel run multiple Firefox instances on one host. You may specify your profile name in the command line. Mind that the prefs.js file provided with ADBFuzz also contains some significant options to be added directly into the prefs.js file of the fuzzing profile you’re using.
E–> Communication
Communication between the outside harness and the running in-browser component is especially important when testing browsers. When the fuzzer running inside a browser has just an outside harness which’s monitoring it, communication from fuzzer to harness is mostly helpful for logging all actions taken by the fuzzer so that they are more easily reproduced.
F–> Using Add-on Debug Functions
Certain functions accessible in privileged context are very powerful only for automated testing. Among such examples are the garbage collector’s calling, zealous garbage collection ability, Firefox quitting, or the cycle collector invoking. There’s a publically available add-on for this.