Organic Testing

Organic Testing is an AutomatedTest methodology that shares a resemblance to both UnitTest and AcceptanceTest. Like UnitTest, they are run by the developers whenever they want (before check-in and integration). Unlike UnitTest, only the framework for the test is provided by the programmers, while the actual data of the test is given by BusinessProfessionals. The set of Organic Tests is built gradually as the software develops; every UseCase and every feature is reflected in a collection of tests. Creating the tests is an integral part of the programming performed by the development team.

One main advantage over UnitTest, is that the test's data is written from the perspective of an ExpertUser, and doesn't rely solely on the programmer. Programmers usually don't write enough tests, and don't check all the UseCases, primarily because they have more interesting things to do. However, a devoted BusinessAnalyst will write real-life use cases if the programmer provides a framework for them. The coverage net of the system by the tests grows much rapidly then in other automatic QA paradigms.

An advantage over AcceptanceTest is that an organic test doesn't need to be an end-to-end test, since the programmer provides hooks inside the software for testing, and therefore every class is testable in principle.

The easiest way to implement OrganicTesting is by hooking JUnit with an IoC container, especially if your software already works this way. See for example http://opensource.atlassian.com/confluence/spring/pages/viewpage.action?pageId=146.

Another advantage of OrganicTesting is that it can be hooked to non-functional tests as well.

In the TgpMethodology, Organic Testing is practiced by using profiles as the basis for TestCases. In fact, the tests are part of the model: test is a type, test-templates are ProfileTemplates, stubs are ProfileTemplates and TestCases are profiles. The profiles serve both as a language (template) and as the concrete content of the tests. Since the business professionals can anticipate the output of a given input, when running the system configured with a certain set of profiles, we can compare the actual outcomes (or system state) to the desired ones. The Organic Testing is basically this comparison, of desired to actual outcome, when running the system or module configured with certain profiles.

The Organic Testing net is using the profiles rather than input as the main substance. Doing so, Organic Testing can grasp a more stable component of the software than the possible inputs tested by standard automatic QA. Moreover, the spectrum needed to be covered to assure quality is smaller as can be seen in the following figure. The Organic Testing covers the green and yellow (inner) cycles, whereas automatic QA covers the orange (outer) one.

The TgpMethodology uses OrganicTesting for another reason - the personnel. As in writing the code, so in testing it, the TGP methodology suggests the cooperation of the non-programmers. It brings the QA experts into the heart of automatic testing is and shares with them what is usually the programmers' responsibility.

OrganicTesting is a major principle of the TgpMethodology, an AgileMethodology that focus on incorporating BusinessProfessionals into software development. However, OrganicTesting can be implemented independently of the rest of the TgpPrinciples. -- ShaiBenYehuda and OriInbar

Discussion

Can it be considered an Agile methodology if it requires a QA division?

It is an Agile methodology because developers constantly run the tests which are defined by the QA people. These tests allows incremental development (IncrementalDevelopment). Shai Ben-Yehuda (ShaiBenYehuda)
As the TgpMethodology is not a firm technique it can co-exist with some traditional QA functions. However, the test are written and run by business professionals (TBAs) and developers. -- OriInbar
I don't think it requires a QA division, but QA people - I mean, people who are involved in the development process, and get their thrills from finding bugs. I find it to be the main disadvantage of TestDrivenDevelopment: programmers don't really like to test their code, but they like their code to be tested. The idea that a programmer only makes a framework for testing, while the actual data for the test is written by another one seems to have its benefits. However, since the programmers run those tests themselves, they have constant feedback, and FeedbackShouldBeFree. However, I don't think one can run OrganicTesting as if they were UnitTests, since there will be too many tests, and it takes too long to run them all. Maybe one should run them only before check-in, or have sub-sets that are meant to be run with every compilation, before check-in, once a day, once a week, etc. (ModdyTeEni?)

I'd ask more questions, but my eyes glazed over after the second paragraph. Can we turn this from a white paper into a wiki page? Examples would help.

Example: Suppose you have bags in your system - lists, vector, queue, etc, which all inherit from interface "Bag". You can write one IBagTest to test all the bags. Its interface will be a class name, initial value, an operation to do, and an assertion. You can create many instances of IBagTest using an IoC container (e.g. Spring ), and let non-programmers write scenarios in XML that check the containers. Since those people are aiming at finding bugs, they will write way more tests than the programmer; they'll put crazy scenarios; they'll copy scenarios from one type of bag to another, etc. A programmer will probably settle at writing two inserts, one erase, and check the sizes.

CategoryAgileMethodology AcceptanceTest TestDrivenDevelopment CategoryTestDrivenDevelopment CategoryTesting

TgpMethodology TgpArchitecture TgpProcess

Issues that Organic Testing should refer to: OneButtonTesting FunctionalTest CustomerTest ProgrammerTest