archive-info.com » INFO » H » HSKUPIN.INFO

Total: 368

Choose link from "Titles, links and description words view":

Or switch to "Titles and links view".
  • firefox automation | hskupin.info
    also have to reach out more on Github to actually find interested people Therefore Henrik requested a Github mirror of our mozmill tests repository It s available at https github com mozilla qa mozmill tests now With the last release of Mozmill 2 0 6 we got the mozcrash packages included So far we aren t able to process stacktraces given that the necessary crashreporter symbols were not available for daily builds of Firefox on the FTP server This has been fixed now for all kinds of daily builds As seen for the last beta and final releases of Firefox we still have a good amount of broken configuration files for ondemand update tests in Mozmill CI Those are failures done by the person who runs those tests but also by broken behavior in the mciconf tool Given that we want to put more focus on the full automation stack for update tests now To get started we need appropriate notifications send out by Mozilla Pulse Individual Updates For more granular updates of each individual team member please visit our weekly team etherpad for week 17 and week 18 Meeting Details If you are interested in further details and discussions you might also want to have a look at the meeting agenda the video recording and notes from the Firefox Automation meetings of week 17 and week 18 automation ci contribution firefox automation mozmill testing Mozilla Automation Training day is today June 4 2014 Henrik Skupin 5 Comments The Firefox QA Automation team is hosting another Automation Training day on June 4th The event is a day long so join us whenever you are free You will be able to learn details about our projects how we tackle automation requests or simply to get started with coding We are always around to assist you in getting started We are looking out for you and your participation automation firefox automation training Mozilla Firefox Automation report week 15 16 2014 June 3 2014 Henrik Skupin 3 Comments In this post you can find an overview about the work happened in the Firefox Automation team during week 15 and 16 Highlights To be able to support the new update path for Firefox Beta users via a final release candidate on the beta channel we had to update our update testruns with Mozmill in the mozmill automation repository Further we also had to add support for this update path in Mozmill CI Cosmin spend his time on those patches and finally we got those out and active That means from now on our software update tests can handle Firefox X 0b9 Firefox X 0RC Firefox X 1 0b1 updates More information can be found on bug 960781 We also pushed some other updates for Mozmill CI to our production system which includes timestamps for the log output of the pulse listener and the addition of the application name for the product to test The latter was necessary for MetroFirefox But even after we stopped support for it we wanted to see it landed given that we could add other products more easily in the future Also Henrik pushed a change for Mozmill CI which removed support for running localized versions of Firefox Nightly builds This was necessary so that our systems can be better utilized for those Aurora and Beta builds where actually most of the localization work is happening Individual Updates For more granular updates of each individual team member please visit our weekly team etherpad for week 15 and week 16 Meeting Details If you are interested in further details and discussions you might also want to have a look at the meeting agenda the video recording and notes from the Firefox Automation meetings of week 15 and week 16 automation ci firefox automation mozmill testing Mozilla Firefox Automation report week 13 14 2014 May 9 2014 Henrik Skupin 3 Comments In this post you can find an overview about the work happened in the Firefox Automation team during week 13 and 14 Highlights Finally we were able to upgrade our mozmill ci production system to Mozmill 2 0 6 The only caveat is that we had to disable one test for cleaning history to prevent the always occurring Flash crash on Windows This week Henrik was able to land the first fixes for broken TPS tests Together with Andrei we were able to fix 4 of them Also we had our first Automation Training days The first one on Monday was a huge success and we have seen lots of new faces Sadly the second one on the following Wednesday we haven t announced separately so lesser people joined our training In the future we will make sure to announce each Automation Training day separately Also there will be only a single one in a full week so it will allow people to do some homework until the next session In week 14 we released version 2 0 6 1 of our mozmill automation package It was necessary to allow QA to run the Mozmill update tests with overriding the update channel so update tests from a release candidate to the next beta build can be performed After we discovered even more Flash crashes of the same type we decided to use the debug version of Flash on our Windows systems Main reason is that those builds don t crash Sadly given that they would give us way more information But Adobe should at least know where the crash is happening Also given that we do not have any private data on our test machines we decided to actually upload a minidump from one of those crashes to Bugzilla This information actually helped Adobe a lot So we will continue doing that Last but not least Henrik was able to fix another 7 bugs for TPS Those were broken tests a broken behavior of the TPS test extension or enhancements Individual Updates For more granular updates of each individual team member

    Original URL path: http://www.hskupin.info/tag/firefox-automation/ (2016-05-01)
    Open archived version from archive


  • mozqa | hskupin.info | Page 2
    compatible test run and make sure that the upcoming Firefox Beta Nightly builds are handled too Mozmill Tests We take a stab in handling and coordinating the creation of new Mozmill tests and fixing the broken ones The reason for this change I will also explain in a separate blog post shortly But to say in general we need more test coverage and skipped failing tests over a long time are bad practice and counter productive So lets get all of them re enabled again and new tests written Addons There will not be that much time for us this quarter to continue developing the add ons we own But we will make sure to fix breakage for MemChaser and Nightly Tester Tools if those occur If you want to help out you are more then welcome WebApps Testing While this is not on our official goals for this quarter we have to assist the WebApps QA team to figure out the right test harnesses to create automated functional tests for open web apps It will be a challenge and we are kinda interested to see that upcoming As you can see there are plenty of projects to work on Any of those are public and are waiting for your contribution If you are interested in working with us and to raise your personal skills please contact us via our public mailing list or automation IRC channel automation mozmill mozqa testing Mozilla Software Mozmill 1 5 12 released May 7 2012 Henrik Skupin 2 Comments Something we have learned over the weekend was Never say never After we have released the 1 5 11 release of Mozmill on April 19th we were sure to not have to ship any other release off this branch We want to concentrate our work on Mozmill 2 0 and get it out as soon as possible But things can change and sometimes faster as expected So by last Friday it was already late in the evening Mike Conley contacted me on IRC and mentioned that Mozmill will be broken starting with tomorrows build The reason for it was the Global Per Compartment patch which has been landed in Nightly builds of Firefox and Thunderbird at that time Great Why do things like those happen just before when I m already in my weekend Anyway given the importance of this bug it broke the whole test infrastructure of Thunderbird which mostly relies on Mozmill I was talking immediately to Clint Talbert Given the good bug report from John Schoenick we were directly aware of what the problem was and agreed on a new API to get the issue fixed So I have spent a good portion of my Saturday and Sunday evening to put together a patch which removed the broken code in waitForPageLoad and replaces it with the new API So by now we do no longer add a custom mozmillDocumentLoaded property to all windows but have a nice windowMap object that handles all the loaded states of each window on its own I think that s great and modifying the DOM of each window was even a bad idea since the beginning of the project Good to see that killed That means early today we got all patches landed and I was able to release Mozmill 1 5 12 to PyPI and even the uploaded extension on addons mozilla org has been approved in the meantime If you haven t updated yet and you make use of Nightly builds you should do it now Lets cross the fingers that no other unexpected issues will arise and force another 1 5 branch release firefox mozmill mozqa Software testing Mozilla Software Nightly Tester Tools 3 3 released May 3 2012 Henrik Skupin Leave a comment Having a good experience when testing Firefox Nightly builds should be self evident Therefor the QA Automation Services team is maintaining the Nightly Tester Tools extension which brings a couple of useful features to ease the testing efforts While the extension works fine most of the time we unfortunately fail at times when a version bump for Firefox happens Exactly this action repeats in a 6 week interval and is the release cycle of Firefox So what happens here The extension registers binary components for the crashme feature in the manifest file and that s why it is not handled as a compatible by default extension by the add ons manager So right after a version bump the extension gets marked as incompatible until the compatibility information on addons mozilla org has been updated This results in an unavailability of the extension in Nightly builds for a couple of hours or even a day depending on when one of us has time to actually do the version bump That had to be changed and thankfully Szabolcs Hubai has spent some time on it to fix the problem and to make our extension compatible by default From now on you will never see the Nightly Tester Tools disabled after a version bump of Firefox which is great I hope you all will enjoy it With the 3 3 release we also ship some other fixes which you can read about in the changelog You want to help in the development of the extension Feel free to contact us as usual via MozIRC or our mailing list addons extension firefox mozqa testing Mozilla Review of Automation Services goals in Q1 2012 April 26 2012 Henrik Skupin Leave a comment Now three weeks after Q1 of 2012 has been passed by I finally have the time to give some details about our work happened during the first three months As usual we set a couple of goals we wanted to see by the end of the quarter All of them were kinda important so we did our best to get all of them done and we succeeded even if it was in the last minute So everyone of us was happy about the

    Original URL path: http://www.hskupin.info/tag/mozqa/page/2/ (2016-05-01)
    Open archived version from archive

  • mozqa | hskupin.info | Page 5
    addons event firefox mozqa testday Mozilla Second Add ons Manager redesign testday this Friday June 9 2010 Henrik Skupin 3 Comments This Friday June 11th Mozilla QA is holding the second testday about the new Add ons Manager for Firefox 4 0 Looking back to the fantastic results we got from the last testday we hope to have a similar attendance this time We will concentrate on exploratory testing mostly the complete user interface and the back end You will find detailed information in our testday event page Please join and help us to make sure we will have the best Add ons Manager ever in Firefox 4 firefox mozqa testday testing Mozilla Jsbridge 3 5 6 and Mozrunner 2 4 3 available June 9 2010 Henrik Skupin Leave a comment Within the last two weeks we had to push two maintenance releases for jsbridge and mozrunner which now fix two major issues Bug 570790 Due to a broken pyPI package of jsbridge the extension wasn t working properly on all platforms At least on Windows the files which have been accidentally added to the tar gz file caused an error when loading files from the components and chrome folder of the extension We have removed all those instances to make sure the extension will work again Bug 568839 Installing binary extensions with Mozmill was broken in version 2 4 2 All files which have been extracted from the XPI were handled as ASCII files With this fix Mozmill is now able to install any version of extensions successfully If you still notice any other problems please get in contact with us automation firefox mozmill mozqa testing Mozilla Testday for creating Mozmill Tests for Add ons May 26 2010 Henrik Skupin 1 Comment Mozmill is not only able to execute functional and unit tests against applications which are build on top of the Gecko platform but can also be used to run those type of tests against extensions If you are an extension author and interested to see your extension tested in a daily fashion by our automated test runs in the QA lab you should definitely join the testday on Friday May 28th We really want to encourage you to think about the implementation of automated functional tests for your own extension And it s not only helpful for the extension itself but can also help us to identify regression in the Firefox development cycle as early as possible To have an introduction available we were working closely together with Google to have example tests in our mozmill tests repository Learn how Mozmill tests will be written and how they can be run in Firefox The Mozmill team will be around the whole day to assist you wherever possible If you are interested in the testday you should read through the following documentation about the creation of testscripts for extensions You can also attend when you have general questions about Mozmill or when you want to help in fixing

    Original URL path: http://www.hskupin.info/tag/mozqa/page/5/ (2016-05-01)
    Open archived version from archive

  • Firefox Automation report – week 9/10 2014 | hskupin.info
    support yet due to missing symbol files for daily builds on ftp mozilla org we can at least show that a crash was happening during a testrun and let the user know about the local minidump files Individual Updates For more granular updates of each individual team member please visit our weekly team etherpad for week 9 and week 10 Meeting Details If you are interested in further details and discussions you might also want to have a look at the meeting agenda the video recording and notes from the Firefox Automation meetings of week 9 and week 10 automation automation development ci firefox metro mozmill QA Post navigation Previous Post Firefox Automation report week 7 8 2014 Next Post Firefox Automation report week 11 12 2014 Logging In Profile cancel Sign in with Twitter Sign in with Facebook or Comment Name Email Not published Website Notify me of follow up comments by email Notify me of new posts by email 3 Replies 0 Comments 3 Tweets 0 Facebook 0 Pingbacks Last reply was April 11 2014 EdgarsLabRat View April 11 2014 moz Henrik Skupin Firefox Automation report week 9 10 2014 http t co 3Eq2dShwjN Reply planetmozilla View April 11 2014 Henrik Skupin Firefox Automation report week 9 10 2014 http t co hmyEOuSd4A Reply PlanetFeeds View April 11 2014 Henrik Skupin Firefox Automation report week 9 10 2014 In this post you can find an overview about the wor http t co yZ9dzwPcU6 Reply Photostream April 2014 M T W T F S S Mar May 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 Recent Posts Review of Firefox desktop automation work Q1 2016 March 31

    Original URL path: http://www.hskupin.info/2014/04/11/firefox-automation-report-week-9-10-2014/ (2016-05-01)
    Open archived version from archive

  • automation development | hskupin.info
    to have a look at the meeting agenda and notes from the last two Automation Development meetings of week 47 and week 48 automation automation development ci firefox jenkins metro mozmill Mozilla Mozmill speed improvements after upgrading Python from 2 6 to 2 7 3 November 29 2013 Henrik Skupin 5 Comments Yesterday we tried to upgrade our mozmill ci cluster to the previously released Mozmill 2 0 1 Sadly we failed on the OS X 10 6 machines and had to revert this change After some investigation I found out that incompatibility issues between Python 2 6 and 2 7 3 were causing this problem in mozprofile Given the unclear status of Python 2 6 support in mozbase and a talk in the ateam IRC channel I have been advised to upgrade those machines to Python 2 7 I did so after some testing also because all other machines are running Python 2 7 3 already So I didn t expect any fallout First post upgrade tests have proven this The interesting fact I would like to highlight here is that we can see speed improvements by running our tests now Previously a functional testrun on 10 6 has been taken about 15 minutes Now after the upgrade it went down to 11 minutes only That s an improvement of nearly 27 with Mozmill 1 5 24 With Mozmill 2 0 1 there is a similar drop which is from 8 minutes to 6 minutes Given all that and the upcoming upgrade hopefully soon of our mozmill ci system to Mozmill 2 0 1 we will see an overall improvement of 60 15 minutes 6 minutes per testrun This is totally stunning and allows us to run 2 5 times more tests in the same timespan With it we can further increase our coverage for locales from 20 to 40 for beta and release candidate builds as next step automation automation development ci mozmill python Mozilla Automation Development report week 45 46 2013 November 21 2013 Henrik Skupin 2 Comments After the last report over a two week cycle I have to follow up with another one for the weeks 45 and 46 Due to my move I had limited availability and to fix some important other stuff So hopefully this is the last report over a two weeks period in the near future Highlights To be able to release Mozmill 2 0 1 as soon as possible Henrik had to fix a lot of existent bugs for mozprofile in conjunction with its add on manager class Those fixes were necessary because our restart tests were broken due to an inappropriate clean up of add ons after closing Firefox At the end 10 bugs have been fixed We are close to get our first Metro tests running with Mozmill on Windows 8 and 8 1 But before we can really do that the whole mozmill tests repository has to be refactored to support multiple applications Here both Andreea and Andrei are doing most of the work Dave and Henrik were both working on a couple of Mozmill CI issues which will help us to better diagnose the memory issues and random crashes of the Jenkins Java process Everything has been merged to our staging server and has to bake a bit before a push to production will happen Henrik added a new feature to Mozmill CI which allows us to run tests for builds off project branches This will come into play really soon when we have to execute daily tests for the upcoming holly branch which is mozilla central without the Australis UX Dave released gaiatest 0 19 b2gpopulate 0 11 and b2gperf 0 12 to resolve leaks in performance tests Individual Updates For more granular updates of each individual team member please visit our weekly team etherpad for week 45 and week 46 Meeting Details If you are interested in further details and discussions you might also want to have a look at the meeting agenda and notes from the last two Automation Development meetings of week 45 and week 46 automation automation development b2g continuous integration firefox mozmill Mozilla Automation Development report week 43 44 2013 November 7 2013 Henrik Skupin 2 Comments Given that I was partly away in the last two weeks I haven t had the time to write another summary report of our work yet So lets combine the last two weeks in a single blog post this time Highlights To be able to continue our work to speed up testruns in Mozmill CI Henrik upgraded our Mozmill CI system to Jenkins 1 509 4 This step was necessary so that we can investigate the slowness in sending out emails for finished testruns which could take up to 25 minutes Beside that Henrik also disabled the sending of emails for successful testruns given that those were mostly blocking us and no one really uses them That was already a real boost and our system was able to execute all of the 245 update tests for the 25 0 release in 25 minutes across all platforms If you are interested in our goals you might want to have a look at Henrik s post about the Automation Development team goals for Q4 As noted in the last couple of Automation Development reports our Windows 8 1 64bit nodes were really unstable and restarted at random times With a lot of research Henrik was able to identify the problem Finally it turned out a bug in VMWare vSphere you could circumvent by tweaking the CPUID mask of the machine All the details about investigation and problem solving can be found on bug 916746 Together with Adrian from the IT team Henrik setup another slave node for each supported platform of the Mozmill CI production instance That means for the 16 different platforms including 32bit vs 64bit we are running 64 slaves now That is a lot and the need for Puppet support is more

    Original URL path: http://www.hskupin.info/tag/automation-development/ (2016-05-01)
    Open archived version from archive

  • metro | hskupin.info
    new mozprocess version With the ongoing pressure of getting automated tests implemented for the Metro mode of Firefox our Softvision automation team members were concentrating their work on adding new library modules and enhancing already existent ones Another big step here was the addition of the Metro support to our Mozmill dashboard by Andrei With that we got new filter settings to only show results for Metro builds When Henrik noticed one morning that our Mozmill CI staging instance was running out of disk space he did some investigation and has seen that we were using the identical settings from production for the build retention policy Without having more then 40GB disk space we were trying to keep the latest 100 builds for each job This certainly wont work so Cosmin worked on reducing the amount of builds to 5 Beside this we were also able to fix our l10n testrun for localized builds of Firefox Aurora Given that we stopped support for Mozmill 1 5 and continued with Mozmill 2 0 already a while ago we totally missed to update our Mozmill tests documentation on MDN Henrik was working on getting all of it up to date so new community members wont struggle anymore Individual Updates For more granular updates of each individual team member please visit our weekly team etherpad for week 7 and week 8 Meeting Details If you are interested in further details and discussions you might also want to have a look at the meeting agenda and notes from the Firefox Automation meetings of week 7 and week 8 automation ci firefox automation metro mozmill testing Mozilla Automation Development report week 47 48 2013 December 6 2013 Henrik Skupin 4 Comments This is again an overview about the highlights of our work in week 47 and 48 this year Sorry for the delay of a couple of days but some critical work was holding me off from writing this post Highlights Henrik and Dave were working on a couple of Mozmill CI updates which have been pushed to production The first batch of features and bug fixes landed in week 47 It included the monitoring plugin for Jenkins which hopefully will help us to figure out the reasons of Java crashes Also we can finally run project branches via our CI now even it can only be done manually as of now It is important for our upcoming tests for the Holly branch Firefox Nightly without the Australis feature The second batch landed by last week was intended to upgrade our system to Mozmill 2 0 1 Sadly we failed in it due to a couple of other failures which we haven t seen before on our staging server So we partly reverted back the latest commits for production and we all are working hard on getting those issues fixed With the detected failures by upgrading to Mozmill 2 0 1 Henrik has noticed that one of those existed because of an incompatibility of mozbase

    Original URL path: http://www.hskupin.info/tag/metro/ (2016-05-01)
    Open archived version from archive

  • Double-check to disable Firefox Sync when doing a regression test to not loose important profile data | hskupin.info
    passwords and other synced data So a warning for everyone who is doing regression tests for Firefox and has Sync enabled Please do NOT forget to disconnect Sync for the testing profile and double check that it has been turned off firefox QA sync testing Post navigation Previous Post Mozmill 2 0 released Next Post Automation Development report week 39 2013 Logging In Profile cancel Sign in with Twitter Sign in with Facebook or Comment Name Email Not published Website Notify me of follow up comments by email Notify me of new posts by email 8 Replies 7 Comments 1 Tweet 0 Facebook 0 Pingbacks Last reply was October 2 2013 planetmozilla View October 1 2013 Henrik Skupin Double check to disable Firefox Sync when doing a regression test to not loose important profile data http t co F73EIglaw2 Reply Neil Rashbrook View October 1 2013 Isn t that a bit of a bug in Sync Surely if your password file is missing or corrupted it should try to restore it rather than pushing the change to your account Reply Henrik Skupin replied View October 1 2013 Well I removed the passwords within Firefox because simply removing the signons sqlite file made the regression disappear So for a minimized profile I wanted to have at least all my passwords removed So in that case I don t call it a bug in Sync Reply avih View October 1 2013 When testing and developing I think it would be wise to never use the production main profile I have shortcuts to run all relevant builds release nightly own builds UX etc with custom profile paths This also typically avoids any noise issues the production profile may have due to cruft from extensive usage and unless you specifically test profile cruft issues issues are generally more consistent with a clean profile E g path to dev firefox exe no remote profile path to dev profile The explicit binary path is to make sure it doesn t use the global firefox exe in case firefox exe doesn t exist at the expected folder The no remote makes sure it will use the specified binary rather than piggyback an already running firefox instance The custom profile makes sure it will not intermix with the production profile Reply Henrik Skupin replied View October 1 2013 The problem here is that only my main profile showed the regression So I had to trim it down As I have written I was working on a clone of the main profile but that doesn t help if Sync is active Reply Horea View October 1 2013 Maybe you could try one of those file recovery utilities to get back the deleted files Reply Henrik Gemal View October 1 2013 Oh no Reply Richard Newman View October 2 2013 Note that Sync will only sync deletions if you actually perform a deletion If you delete the database file that backs the data source e g signons sqlite it won

    Original URL path: http://www.hskupin.info/2013/10/01/double-check-to-disable-firefox-sync-when-doing-a-regression-test-to-not-loose-important-profile-data/ (2016-05-01)
    Open archived version from archive

  • sync | hskupin.info
    a website via my personal profile By surprise the user name and password hasn t been filled in automatically and a check for the saved passwords have revealed that NONE are stored anymore All were gone forever After some thoughts I figured out that sync was the problem here because I missed to disconnect it in the copied profile So after I have deleted the signons sqlite and other files it also removed all the information from my sync account which got distributed to all my other machines too So on each of them the passwords are gone And if that isn t bad enough the backup tool on my Ubuntu machine had a hick up lately and deleted all the old backup files on the backup drive Not sure how that have come but with that I completely lost all my stored passwords and other synced data So a warning for everyone who is doing regression tests for Firefox and has Sync enabled Please do NOT forget to disconnect Sync for the testing profile and double check that it has been turned off firefox QA sync testing Photostream May 2016 M T W T F S S Mar 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 Recent Posts Review of Firefox desktop automation work Q1 2016 March 31 2016 Firefox Desktop automation goals Q1 2016 February 2 2016 Review of automation work Q4 2015 January 9 2016 Automation Survey Follow up January 5 2016 Results of the Firefox Automation Survey December 3 2015 Survey about sharing information inside the Firefox Automation team November 23 2015 Firefox Automation report Q3 2015 October 20 2015 Crusial SSD bug

    Original URL path: http://www.hskupin.info/tag/sync/ (2016-05-01)
    Open archived version from archive