Hi Patrick, My understanding for the automatic testing mentioned here is about developer unit test or kind of pre-integration test before "gbs submit". As you've discussed there are several ways to do unit test, either integrate with Jenkins build system, or submit test request through gbs command. QA provided another standalone web tool for unit test, we call it developer testing tool (DTT). It might not perfect, but do provide below capabilities for unit test: - Share lab devices with developer, and provide a way for developer to share his device with others in same group. So far, there is one VTC7120 and one VTC1010 in the system. - Share QA automated test suites. User can select test sets for unit test. - Image management, user can select released image or any image which can be reached through http or https - User can upload and install system packages or developer test cases to IVI device, the trigger the test - Fetch log and test result from test device - Monitor test progress ...
This test infrastructure is used by pulsaudio, gstreamer and bluez developers before. DTT helped developers to get confidence on package upgrade. -Cathy >-----Original Message----- >From: Dev [mailto:[email protected]] On Behalf Of Patrick Ohly >Sent: Friday, June 13, 2014 12:06 AM >To: Stoppa, Igor >Cc: Kervinen, Antti; [email protected] >Subject: Re: [Dev] automatic testing > >On Thu, 2014-06-12 at 18:40 +0300, Stoppa, Igor wrote: >> On 12 June 2014 18:21, Patrick Ohly <[email protected]> wrote: >> > One reason for using a remote farm is that developers do not necessarily >> > have access to real test devices. Using the same hardware for different >> > developers is more cost-efficient, too, in particular when those >> > developers are in different time zones and not active at the same time. >> >> sure, it's just that the HW needs to come from somewhere :-D >> both the IVIs or whatever we want to use and the servers that will >> create the images. >> >> One more reason to search for consensus also beyond the circle of developers >> ;-) > >Of course. But aren't release engineering and QA also following this >list? It is not the "developer" list, it is the list for "development of >the Tizen platform". > >-- >Best Regards, Patrick Ohly > >The content of this message is my personal opinion only and although >I am an employee of Intel, the statements I make here in no way >represent Intel's position on the issue, nor am I authorized to speak >on behalf of Intel on this matter. > > > >_______________________________________________ >Dev mailing list >[email protected] >https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
