diff --git a/GettingStartedOnTesting.wiki b/GettingStartedOnTesting.wiki
index aabcba7..35a7a08 100644
--- a/GettingStartedOnTesting.wiki
+++ b/GettingStartedOnTesting.wiki
@@ -1,7 +1,7 @@
 #summary Guide on tips and tricks for writing tests for Melange
 #labels Contents-Draft,Importance-Useful,Phase-QA
 
-This page is inteded for tips and tricks for writing tests for Melange.
+This page is intended for tips and tricks for writing tests for Melange.
 
 <wiki:toc max_depth="3" />
 
@@ -10,13 +10,13 @@
 == Testing framework==
 In a nutshell, tests are all about comparing the expected result with the actual result after application of a function/method under test. If you expect to get a particular value, you can assertEqual to the value of the actual result. If you expect that a particular exception should be raised, you can assertRaises the exception. If you expect that a template is used to render a web page, you can assertTemplateUsed the template. If you expect that a mail has been sent to a particular person, you can assertEmailSent(to=the_persons_email_address). On the other hand, if you cannot predict the exact value but you expect that the value will change after the application of a function/method under test, you can assertNotEqual to the value before the application of a function/method under test. In addition, you may also want to assert that the environment before your test is your expected/required testing environment.
 
-Not only should normal situations/use cases be tested but also should other possible situations/use cases, which is particularly important for security tests. For example, we should not only test that an HTTP POST with a correct XSRF token can be successfully applied, we should also test that an HTTP POST with an incorrect XSRF token should be forbidden. For anther example, for views that are only accessible to users with developer privilege, we should not only test that the views work if the current user is a developer, we should also test that the views are forbidden if a normal user or even an unregistered user tries to access the views.
+Not only should normal situations/use cases be tested but also should other possible situations/use cases, which is particularly important for security tests. For example, we should not only test that an HTTP POST with a correct XSRF token can be successfully applied, we should also test that an HTTP POST with an incorrect XSRF token should be forbidden. For another example, for views that are only accessible to users with developer privilege, we should not only test that the views work if the current user is a developer, we should also test that the views are forbidden if a normal user or even an unregistered user tries to access the views.
 === `Python unit test` ===
 All existing logic and models tests of Melange are built on Python unittest TestCase (unittest.TestCase). It gives you several assert methods as well as setUp and tearDown methods which will be respectively called before and after each test case, and also enables your tests to be run by almost all python test runners.
 ==== `Usage` ====
   * Derive your test class from unittest.TestCase.
   * Use setUp method to set up test environment, e.g. seed data store.
-  * Use tearDown method to clean up the test.
+  * Use tearDown method to clean up the test. Its  not necessary to use this method because the datastore is cleared automatically after the completion of each test method with the help of a Nose plugin (see tests.run).
   * Use assertTrue, assertEqual, assertNotEqual, assertRaises and so on to assert that the expected result actually happens.
   * Check [http://docs.python.org/library/unittest.html the documentation of Python unittest] for more information.
   * Example usage in Melange: tests.app.soc.logic.`*`, tests.app.soc.modules.gsoc.logic.`*`, tests.app.soc.modules.ghop.logic.`*` 
@@ -47,7 +47,7 @@
   * Example usage in Melange: tests.app.soc.tasks.`*`, tests.app.soc.modules.gsoc.tasks.`*`, tests.app.soc.modules.ghop.tasks.`*` 
 
 == Naming convention ==
-The name of the test module for testing a codebase module is the name of the codebase module plus a prefix of "test`_`" (without quote), e.g. test_base.py. The name of the test class for testing a codebase class is  the name of the codebase class plus a surfix of "Test" (without quote), e.g. BaseTest. The name of the test method for testing a codebase method is the name of the codebase method with the first letter capitalized plus a prefix of "test" (without quote), e.g. testGetForFields.
+The name of the test module for testing a codebase module is the name of the codebase module plus a prefix of "test`_`" (without quote), e.g. test_base.py. The name of the test class for testing a codebase class is  the name of the codebase class plus a suffix of "Test" (without quotes), e.g. BaseTest. The name of the test method for testing a codebase method is the name of the codebase method with the first letter capitalized plus a prefix of "test" (without quote), e.g. testGetForFields.
 
 == Organization of tests ==
 All tests are in a separate directory
@@ -69,8 +69,8 @@
 === `TaskQueueTestCase` ===
 It extends gaetestbed.taskqueue.TaskQueueTestCase by subclassing unittest.TestCase so that all its subclasses need not subclass unittest.TestCase in their code.
 === `Data seeder` ===
-Data are usually needed to conduct tests. The seed functions are here to seed data for tests. 
-  * There are two seed functions, seedn and seed. The difference between them is that seedn seeds n data of the model class while seed only seeds one data of the model class.
+Data is usually needed to conduct the tests. The seed functions are here to seed data for tests. 
+  * There are two seed functions, seedn and seed. The difference between them is that seedn seeds n data or instances of the model class while seed only seeds one data or instance of the model class.
   * Location: soc.modules.seeder.logic.seeder.logic.Logic
   * Function prototype: seedn(self, model_class, n=1, properties=None), seed(self, model_class, properties=None)
   * Usage: any number of properties can be specified either with their values or with the data provider used to generate the values. Unspecified properties will be generated randomly; unspecified ReferenceProperty will be generated and seeded recursively.