diff --git a/src/mds/apitest/mdstipc_api.c b/src/mds/apitest/mdstipc_api.c
index d37c4b28a..732692d52 100644
--- a/src/mds/apitest/mdstipc_api.c
+++ b/src/mds/apitest/mdstipc_api.c
@@ -1714,6 +1714,13 @@ void tet_svc_subscr_VDEST_10()
 		FAIL = 1;
 	}
 	// Retrieving the events
+	// [Lennart] To synchronize using sleep is probably not the best
+	// solution. It should be possible to wait for events instead
+	// I can see that this is used in lots of places
+	// How can you be sure that the event has happened after 1 sec in all
+	// environments all the time where this test may be executed?
+	// The tet_mds_retrieve_for_change() seems to do that (sort of). Could
+	// at least something similar be done here?
 	sleep(1);
 	if (mds_service_retrieve(gl_tet_adest.mds_pwe1_hdl, 500,
 				 SA_DISPATCH_ALL) != NCSCC_RC_SUCCESS) {
@@ -6061,6 +6068,28 @@ void tet_adest_all_rcvr_thread()
 	free(mesg);
 }
 
+// [Lennart] It is not obvious what this function is doing. Every function
+// struct, class etc. where it is not obvious what it is doing or what its
+// purpose is, should (shall) have a description. This is important also for
+// test code.
+// Internal functions like this one shall be static. If a file contains
+// functions that are used externally the file must have a corresponding header
+// file. A "common" header file containing declarations of functions from
+// several files shall not be used. If a function is declared in a header file
+// then it shall be documented there. If the function is local (static) the
+// description shall be where the function is implemented.
+// A description (comment) is not needed if the function name is self
+// explanatory and there is nothing special that a user needs to know.
+// But, even if the function name makes it obvious what the function is doing
+// and it not doing anything else (hidden) a note may be needed if it is for
+// example not thread safe or if there are parameters which are not obvious how
+// to use etc.
+// I don't think you should fix all functions in the test code with this ticket
+// but it should be done for all new functions. Also if time is invested to
+// analyze a function then it should be documented so that it don't have to be
+// done over and over again in the future.
+//
+
 uint32_t tet_mds_retrieve_for_change(MDS_HDL mds_hdl, MDS_SVC_ID your_scv_id,
 		SaDispatchFlagsT dispatchFlags, NCSMDS_SVC_ID req_svc_id,
 		MDS_SVC_PVT_SUB_PART_VER svc_pvt_ver, NCSMDS_CHG change)