Some testing tools

Data Base Tester:

“Test data generator is a simple, powerful and fully customizable utility that generates data, tables (views, procedures etc) for database testing (performance testing, QA testing, load testing or usability testing) purposes.”

Key features

• Nine ways to fill in the fields.
• The product resolves all master-detail relationships automatically.
• Values Library makes your test data more realistic.
• Create test tables, views and procedures as well as database rows.
• Scramble and Update data generation modes.
• High performance: generator inserts about 8550 test data rows per second (for 5,000,000 records project, SQL Server 2000, Pentium 1700MHz).
• Database independent. You can populate Microsoft SQL Server database as well as Oracle or PostgreSQL database. DTM Data Generator supports all common database interfaces: ODBC, IDAPI, OLE DB, or even Oracle Call Interface.

http://www.sqledit.com/dg/index.html

JavaScript Validator:

“JsTester allows validation of javaScript code inside java. It provides a group of assert methods like JUnit’s Assert, it also supports the validations described in http://javascript.crockford.com/remedial.html, and the ability to use your own validations (unary & binary predicates).”

 http://jstester.sourceforge.net/

Web Functional Test:

“AdventNet QEngine is a complete automated testing tool for functional testing, performance testing, web services testing and regression testing of web applications and web services. “

It has free edition with some interesting features.

http://www.adventnet.com/products/qengine/index.html

What is TTCN?

The TTCN language is a part of the ISO/IEC 9646 conformance testing framework and is specially designed for the specification of tests of communication systems.

Concept: abstract test suites:

Description of a set of tests that should be executed for testing an IUT (Implementation Under Test) together with the relevant data declarations. The test are described using a black box model.  The messages can be defined using either TTCN-Type notation or ASN.1.

What is Extreme Programming?

What is XP? The methodology is designed to deliver the software your customer needs when it is needed. XP empowers your developers to confidently respond to changing customer requirements, even late in the life cycle.[XP.org]

The core practices of XP are [XPfaqs]:

1. The Planning Game: Business and development cooperate to produce the maximum business value as rapidly as possible. The planning game happens at various scales, but the basic rules are always the same:
   1. Business comes up with a list of desired features for the system. Each feature is written out as a User Story, which gives the feature a name, and describes in broad strokes what is required. User stories are typically written on 4×6 cards.
   2. Development estimates how much effort each story will take, and how much effort the team can produce in a given time interval (the iteration).
   3. Business then decides which stories to implement in what order, as well as when and how often to produce a production releases of the system.
2. Small Releases: Start with the smallest useful feature set. Release early and often, adding a few features each time.
3. System Metaphor: Each project has an organizing metaphor, which provides an easy to remember naming convention.
4. Simple Design: Always use the simplest possible design that gets the job done. The requirements will change tomorrow, so only do what’s needed to meet today’s requirements.
5. Continuous Testing: Before programmers add a feature, they write a test for it. When the suite runs, the job is done. Tests in XP come in two basic flavors.
   1. Unit Tests are automated tests written by the developers to test functionality as they write it. Each unit test typically tests only a single class, or a small cluster of classes. Unit tests are typically written using a unit testing framework, such as JUnit.
   2. Acceptance Tests (also known as Functional Tests) are specified by the customer to test that the overall system is functioning as specified. Acceptance tests typically test the entire system, or some large chunk of it. When all the acceptance tests pass for a given user story, that story is considered complete. At the very least, an acceptance test could consist of a script of user interface actions and expected results that a human can run. Ideally acceptance tests should be automated, either using the unit testing framework, or a separate acceptance testing framework.
6. Refactoring: Refactor out any duplicate code generated in a coding session. You can do this with confidence that you didn’t break anything because you have the tests.
7. Pair Programming: All production code is written by two programmers sitting at one machine. Essentially, all code is reviewed as it is written.
8. Collective Code Ownership: No single person “owns” a module. Any developer is expect to be able to work on any part of the codebase at any time.
9. Continuous Integration: All changes are integrated into the codebase at least daily. The tests have to run 100% both before and after integration.
10. 40-Hour Work Week: Programmers go home on time. In crunch mode, up to one week of overtime is allowed. But multiple consecutive weeks of overtime are treated as a sign that something is very wrong with the process.
11. On-site Customer: Development team has continuous access to a real live customer, that is, someone who will actually be using the system. For commercial software with lots of customers, a customer proxy (usually the product manager) is used instead.
12. Coding Standards: Everyone codes to the same standards. Ideally, you shouldn’t be able to tell by looking at it who on the team has touched a specific piece of code. <!–
13. Practice 13: The first rule of practice 13 is: Don’t talk about practice 13.
–>

Consumer perception of the software quality

The consumer’s perception of quality is of central importance which may not be the same as the developer’s. Quality has been demonstrated to be a major determinant of success. Relative perceived quality (customer’s judgements of the quality of the supplier’s offer relative to its competitors) was the single most important factor in affecting the long run performance of a business. Quality was shown both to have a greater impact on ROI (return on investment) level and to be more effective at gaining market share than lower pricing. [Roman Fitzpatrick]