Bad boy automated tool

Bad boy is the automation regression tool which works with view state and lots of the features in it.

To download it http://www.badboy.com.au/

It is a good record and play back tool with load testing feature also i.e we can simulate the 1000 users at a time

It not commercial tool or open source tool cheap to use

Malicious code injection : Not through Sql

All code injection attacks work on the same principle: a hacker piggybacks malicious code onto good code through an input field in the application. Therefore, the protection instead has to come from the code within the application itself.The root of all code injection problems is that developers put too much trust into the users of applications. A developer should never trust the user to operate the application in a safe manner. There will always be someone who is looking to use malicious code in an exploitative manner.

Aside from SQL injections, there are several other types of malicious code injection attacks with which developers must become familiar. Three of these types of dangerous malicious code injections are
1.XPath injection
2.LDAP injection,
3.command execution injection.

XPath Injection:

The attacker inputs a string of malicious code meant to trick the application into providing access to protected information. If your website uses an XML (Extensible Markup Language) document to store data and user input is included in an XPath query against that document, you may be vulnerable to an XPath injection.

For example, consider the following XML document used by an e-commerce website to store customers’ order history:


< orders >
< customer id = " 1" >
< name > Bob Smith
bob.smith@bobsmithinc.com
1234567812345678


1
10.00
Sprocket


2
9.00
Cog



…


The website allows its users to search for items in their order history based on price. The XPath query that the application performs looks like this:

string query = "/orders/customer[@id='" +
customerId + "']/order/item[price >= '" +
priceFilter + "']";

If both the customerId and priceFilter values have not been properly validated, an attacker will be able to exploit the XPath injection vulnerability. Entering the following value for either value will select the entire XML document and return it to the attacker:

'] | /* | /foo[bar='

Find more

Localization Testing

What is localization (L10N)

Adapting a (software) product to a local or regional market.
Goal: Appropriate linguistic and cultural aspects
Performed by translators, localizers, language engineers

Localization

The aspect of development and testing relating to the translation of the software and ite prsentation to the end user. This includes translating the program, choosing appropriate icons and graphics, and other cultural considerations. It also may include translating the program's help files and the documentation. You could think of localization as pertaining to the presentation of your program; the things the user sees.


Internationalization (I18N)

Developing a (software) product in such a way that it will be easy to adapt it to other markets (languages and cultures)
Goal: eliminate the need to reprogram or recompile the original program
Carried out by SW-Development in conjunction with Localization
Handing foreign text and data within a program
Sorting, importing and exporting text and data, correct handing of currency and data and time formats, string parsing, upper and lower case handling.
Separating strings from the source code, and making sure that the foreign language string have enough space in your user interface to be displayed correctly

Internationalization

The aspect of development and testing relating to handling foreign text and data within a program. This would include sorting, importing and exporting text and data, correct handling of currency and date and time formats, string parsing, upper and lower case handling, and so forth. It also includes the task of separating strings (or user interface text) from the source code, and making sure that the foreign language strings have enough space in your user interface to be displayed correctly. You could think of internationalization as pertaining ot the underlying functionality and workings of your program.


What is I18N/L10N stand for ?

These two abbreviations mean internationalization and localization respectively. Using the word "internationalization" as an example; here is how these abbreviations are derived. First, you take the first letter of the word you want to abbreviate; in this case the letter "I". Next, you take the last letter in the word; in this case the letter "N". These become the first and last letters in the abbreviation. Finally, you count the remaining letters in the word between the first and last letter. In this case. "nternationalizatio" has 18 characters in it. se we will plug the number 18 between the "I" and "N"; thus I18N.


I18N and L10N

I18N and L10N comprise the whole of the offort involved in enabling a product.
I18N is "Stuff" you have to do once.
L10N is "stuff you have to do over and over again.
The more stuff you push into I18N out of L10N, the less complicated and expensive the process becomes.

Finding the Text box maximum length by one click

If the Webpage you are testing contains a form fields with text boxes then, if you need to perform the boundary value analysis testing for the text box and validations for the text box use the following javascript




javascript:var x=document.getElementsByTagName('input');myVals='';for (var i=0;i

Notepad Conspiracy Bug

As every one knows about the Notepad Defect 4-3-3-5 letters crashes the notepad. If not follow the things
1. Create a notepad file
2. Type "bcd efg hij klmno" (Without quotes)
(You can try any combination like "this api can break", "this cat can split", "jane can not dance", "text wit hou tcaps" and "xxxx xxx xxx xxxxx".)
3. Save the notepad (with any name)with any one of the above mentioned phrase
4. Open the same notepad file again and verify that notepad crashes.

This is because of the ASCII to UNICODE conversion problem happening in Windows not in notepad.


for more details click here and here

Is testing advancing or stagnating ?

The quality movement started in 1924 when Walter Shewhart gave his boss at Bell Labs a memo suggesting the use of statistics to improve quality in telephones. Later came Juran and Deming, and the movement was well on its way. Not surprisingly, the software industry eventually took up the challenge of systematically improving quality. Let’s look at how that began.


In 1976, Michael Fagan published his first paper on Design and Code Inspections. He talked about how inspections could reduce errors in software. In the same year, Glenford Myers wrote Software Reliability Principles and Practices. In this book, Myers talks about testing philosophies—emphasizing the importance of designing good test cases. He goes on to describe test cases which test the code as if it’s in a sealed, black box. In 1979, Myers wrote his fifth book, The Art of Software Testing, which soon became the bible of the Software Quality movement. In this book, he talks about the importance of Inspections, Black and White Box testing, and the benefits of regression testing.

Sounds like a solid beginning. So, what’s my point?

My point is this. I don’t think testing has advanced since Fagen and Myers wrote their first papers and books. We are still using the same methods to perform our work. We are still asking the same questions.

Now, I’m not suggesting that there haven’t been any important books written in the time since the books Myers wrote. In fact, since then many fine books have been written on the subject of software testing.

In 1983, seven years after Myers' software reliability book, Boris Beizer wrote Software Testing Techniques, a very good book on the subject of software testing. Beizer gives the terms Black Box and White Box testing new names—Functional Testing and Structural Testing respectively. But for the most part he talks about testing methods similar to Myers.

In 1995, a full nineteen years after Myers’ book, Edward Kit wrote Software Testing in The Real World, another good book on software testing. But still, Kit talks about Functional Testing (Black Box) as well as White Box Testing.

But if you have been in the business for any length of time, you get a distinct sense of déjà-vu. If you don’t believe me, take a look at the next testing conference advertisement you get in the mail. Then think about that talk you attended years ago. The one where the speaker described a testing oracle that would create test cases for you. Have you ever seen such a tool that really worked on real code? I doubt it.

What about the CMM and ISO 9000? These processes were going to help us produce high-quality software. How many of you are still using them? Have they solved your quality issues?

Like most of you, I create functional test cases, update regression test suites, and attend
an occasional code review, all in the name of process improvement. But I haven’t seen anything new or revolutionary impact my world.

Again, I’m not minimizing or trying to downplay software quality process. But, like most of you, I work in the real world of tight deadlines and poor requirements. Most of the time I don’t even have real functional specifications. Software engineering documentation—what’s that?

So thinking back to Myers’ 1976 book and all the testing books and conferences since, have we advanced or are we stagnating?

Let’s just say, I feel the algae growing.

Testing For Developers

When we testers find yet another "Did you even run this?" bug, it's easy to believe developers purposely inject bugs just to taunt us. I have worked with a lot of developers over the years, and I've found that they generally do try to test their code but simply don't know how to go about doing so effectively.

As testers gain experience they build up a checklist of common problems, classes of bugs that crop up over and over, and areas that tend to be troublesome. Developers don't have our experience, so they don't have anything similar.

If developers don't know how to test very well, and testers have a simple checklist we use to find the most common bugs, then giving our checklist to developers should help out both sides.

That's my theory anyway, and this is my checklist. I'm testing it right now with my developers. Test it with yours/yourself and let me know what happens!

Customize This List: If you get a bug, determine what test (or even better, what general class of tests or testing technique) would have caught the bug, then add it to this list.
Use Your Tester: Brainstorm tests with your tester. Review your (planned/actual) tests with your feature team. Coordinate your testing with your tester, especially with respect to tests they have already written/are currently writing.
Focus On Your Customer: Think, "Where would the presence of bugs hurt our customers the most?", then let your answers drive your testing.
Test Around Your Change. Consider what it might affect beyond its immediate intended target. Think about related functionality that might have similar issues. If fixing these surrounding problems is not relevant to your change, log bugs for them. To quote a smart person I know, "Don't just scratch it. What's the bug bite telling you?"
Use Code Coverage. Code coverage can tell you what functionality has not yet been tested, but don't just write a test case to hit the code. Instead, let it help you to determine what classes of testing and test cases that uncovered code indicates you are missing.
Consider Testability. Hopefully you have considered testability throughout your design and implementation process. If not, think about what someone else will have to do to test your code. What can you do / do you need to do in order to allow proper, authorized verification? (Hint: Test Driven Design is a great way to achieve testable code right from the get-go!)

Ways To Find Common Bugs:
Reset to default values after testing other values (e.g., pairwise tests, boundary condition tests).
Look for hard coded data (e.g., "c:\temp" rather than using system APIs to retrieve the temporary folder), run the application from unusual locations, open documents from and save to unusual locations.
Run under different locales and language packs.
Run under different accessibility schemes (e.g., large fonts, high contrast).
Save/Close/Reopen after any edit.
Undo, Redo after any edit.
Test Boundary Conditions: Determine the boundary conditions and equivalency classes, and then test just below, at, in the middle, and just above each condition. If multiple data types can be used, repeat this for each option (even if your change is to handle a specific type). If multiple data types can be used, repeat this for each option. For numbers, common boundaries include:
smallest valid value
at, just below, and just above the smallest possible value
-1
0
1
some
many
at, just below, and just above the largest possible value
largest valid value
invalid values
different-but-similar datatypes (e.g., unsigned values where signed values are expected)
for objects, remember to test with null and invalid instances
Other Helpful Techniques:
Do a variety of smallish pairwise tests to mix-and-match parameters, boundary conditions, etc. One axis that often brings results is testing both before and after resetting to default values.
Repeat the same action over and over and over, both doing exactly the same thing and changing things up.
Verify that every last bit of functionality you have implemented discussed in the spec matches what the spec describes should happen. Then look past the spec and think about what is not happening but should.
"But a user would never do that!": To quote Jerry Weinberg, When a developer says, "a user would never do that," I say, "Okay, then it won't be a problem to any user if you write a little code to catch that circumstance and stop some user from doing it by accident, giving a clear message of what happened and why it can't be done." If it doesn't make sense to do it, no user will ever complain about being stopped.