[08:51] Though I'm late for the class, thanks Noskcaj, very good lessons for me :) [08:51] I read the class in my history~~ === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Using your preferred testing system with Test Cases - Instructors: smartboyhw - Slides: http://is.gd/TlzUq5 [13:01] [SLIDE 1] Oh hello, good morning (if you are in the USA0, good afternoon (in UK) and good evening (in Asia)! [13:01] Slides for Using your preferred testing system with Test Cases: http://people.ubuntu.com/~smartboyhw/Ubuntu_ISO_Testing_CLASSROOM.pdf [13:01] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html following the conclusion of the session. [13:01] I'm Howard Chan (smartboyhw). [13:02] To ask questions, please use the prefix "QUESTION:" to ask your question in #ubuntu-classroom-chat. [13:02] We have slides this time, so do read along with me:) [13:02] [SLIDE 2] So, who am I? [13:03] I'm a Ubuntu QA tester, and I like ISO Testing very much [13:03] I'm also Ubuntu Studio's Release Manager, responsible for things like making release notes, etc. [13:03] At the same time, I'm a packager at Kubuntu. [13:04] [SLIDE 3] OK, so here's a critical question: Why do we DO ISO testing? [13:04] Well, what is the first thing you need to do when you want to use or try Ubuntu? [13:04] Download one of our images from the servers, burn it to a DVD or USB, and boot it up! [13:05] However, what if the images just aren't working? The users will get angry and won't use Ubuntu. [13:05] This is what we NOT want. [13:05] As ISO testers, we always want to make sure we do make the images usable and installable. [13:06] We try to make it bug-free as most as possible. Of course, there might be some bugs that users find when we didn't find it. [13:06] However, we seriously want most users to be able to try out and install Ubuntu. [13:07] [SLIDE 4] Now, you need some utilities before doing ISO testing. [13:07] First of all, it is a Launchpad account. [13:07] If you attended balloons' session, you would have learnt the importance of a Launchpad account. It is used to login across our QA Trackers, in this case, the ISO QA Tracker, in iso.qa.ubuntu.com [13:08] Then, you need a SPARE machine (DON'T USE YOUR DAILY MACHINE) or a Virtual Machine. [13:08] These are needed to boot and test the images. I will talk about what kinds of Virtual Machines you can install later. [13:09] Preferably, you should also have a Ubuntu system. [13:09] You don't have to necessary install our development release (Saucy Salamander), however it is good to do so. [13:10] It's also OK to use Windows or Mac OS X machines (better still for Macs as you can try out the amd64+mac) images [13:10] And you must have an image:) [13:10] For example, if you want to test the Ubuntu Desktop amd64 image, you have to download it. [13:11] I will teach you what is the best way to download an image later. [13:11] So, virtual machines. [13:12] There are multiple kinds of Virtual Machines' software in Ubuntu's archive. [13:12] I like to use VirtualBox, as it is fully open-source and can test images easily [13:12] [SLIDE 5] it's available by launching a terminal and type "sudo apt-get install virtualbox" [13:13] A software I would recommend for beginning testers though is Testdrive [13:14] Testdrive is a utility developed originally by Canonical, then Ubuntu QA Team got more involved in the development process this cycle. [13:14] It helps you to zsync (download and check) the image and launches the image using KVM or Virtualbox, all at one place [13:15] "sudo apt-get install testdrive" and it's there for you! [13:15] Also available is Virt-manager (KVM) [13:16] A kernel-based virtualization software, it's great also. [13:16] [SLIDE 6] there are also some things I would recommend you to do. [13:16] One is to install zsync. [13:19] zsync is a tool to download and check the md5sum of the image you downloaded. [13:19] Very useful, if you don't want to re-download the image again. [13:19] All the above utilities have specific classroom sessions done by our QA Team members. [13:19] Find the one you want in https://wiki.ubuntu.com/Testing/Activities/Classroom/Saucy [13:20] Also, I recommend you to make a hardware profile [13:21] So when a bug appears and is specific to your hardware, bug triagers and developers can fix it accordingly to your hardware. [13:21] Read the instructions in https://wiki.ubuntu.com/QATeam/Hardware to make your own hardware profile. Shouldn't take more than a minute:) [13:22] [SLIDE 7] What sorts of images should I test? [13:22] Basically, EVERYTHING. [13:22] In some cases though, some images are more equal than others. :P [13:23] Last week, we did some Alpha 1 testing on Kubuntu Desktop amd64&i386 images, Lubuntu Desktop & alternate ppc, mac, amd64 and i386 images [13:23] Ubuntu GNOME and UbuntuKylin images [13:23] These are to be released to the general public [13:23] *were [13:24] So, these images would get tested before the others. [13:24] It doesn't really matter what image you test though. [13:24] For example, you don't like Ubuntu with Unity, you like it with KDE. [13:24] So you test Kubuntu images! [13:25] If you have a Mac machine, test the amd64+mac images! [13:25] After testing one image, test another! [13:26] Make sure you don't test images not fitting your computer's architecture. [13:27] For example, don't test an amd64 image in an i386 computer. [13:27] It will fail, and it is an invalid bug:) [13:29] [SLIDE 8] So, here's my computer spec [13:30] Compaq Presario CQ41-203TX Notebook [13:30] 4GB RAM, 1st-gen i5 [13:30] Running Ubuntu Saucy [13:30] Using Virtualbox 4.2.10 to test image 20130625 (shouldn't exist now, please zsync to the latest one) [13:31] So first of all, zsync to the the image you want to test. [13:32] [SLIDE 8] for example, if you want to test the amd64 desktop Ubuntu image, run “zsync [13:32] http://cdimage. [13:32] ubuntu.com/dai [13:32] ly-live/current/s [13:32] aucy-desktop-a [13:32] md64.iso.zsync [13:32] Oops [13:32] "zsync http://cdimage.ubuntu.com/daily-live/current/saucy-desktop-amd64.iso.zsync" [13:33] Should take about 20 minutes if your connection is adequate:) [13:34] Seriously, no questions? Don't be afraid to ask! [13:36] Will stop for 5 minutes here, so you can zsync the image. [13:41] Go to the ISO QA Tracker at http://iso.qa.ubuntu.com [13:41] Click the login button and login using your Launchpad credentials (don't be scared by the Ubuntu One brand name:P) [13:43] Go to "Saucy Daily" [13:43] and click on the image you are testing [13:43] For example, "Ubuntu Desktop amd64" for me. [13:44] So, on that page there are many testcases [13:45] But for me, I want to run a testcase that will install Ubuntu within a single disk [13:45] So "Install (entire disk)" then [13:46] Click at it, and you will enter a testcase page. [13:46] Click at the "testcase" tab [13:46] Look through the testcase. [13:46] Do ask in #ubuntu-classroom-chat using QUESTION: if you don't understand the testcase. [13:47] So, let's begin. [13:47] Boot up the image. [13:47] For me, it's Virtualbox. [13:48] My VM has 1GB RAM only:) [13:50] If you aren't following me with the same image no worries:) [13:51] Just follow through the testcase. [13:51] After all, our session is about "Using your preferred testing system with Test Cases" [13:51] Now, I booted up the image, and it shows the nice screen, telling me to choose "Try Ubuntu" or "Install Ubuntu" [13:52] The testcase tells me to click "Install Ubuntu", so I shall follow it. [13:53] Next! [13:53] Step 3. [13:53] Fortunately, all the boxes are in green ticks [13:53] \o. [13:54] \o/ actually:P [13:54] For the plugins and install updates ticks, it doesn't really matter. I do tick those when I test the image. [13:55] So "Contineu" to step 5. [13:55] s/Contineu/Continue/ [13:55] There goes the "Installation type" screen. [13:55] The "Erase disk and install Ubuntu" radio button should be default. [13:56] In this case, we want it;) [13:56] So click "Install now" [13:56] We only have 1 drive, so onto step 10. [13:57] The timezone (if you have a valid internet connection) should be set to your city [13:57] (Or at least, your country/region's main city" [13:58] Click "Continue" [13:58] Step 12: I have to check if the keyboard is correct. [13:58] It is! English (United States) [13:58] So "continue" [13:58] Step 14, the details screen. [13:58] I entered the details [13:59] And clicked "continue" [13:59] Now, wait for the installation to continue. The slideshow should appear. [13:59] I mean, the installation slideshow featuring new features of 13.04 (not 13.10, the responsible guys hasn't made it yet) [14:00] Now, if you have any bugs, do report it. [14:00] launch a terminal by pressing Ctrl+Alt+T [14:00] For the installer, type "ubuntu-bug ubiquity" [14:01] If you can't boot the image itself, type "ubuntu-bug syslinux" [14:01] (Of course, in this case, type it in your host computer) [14:01] If there are graphics problems, type "ubuntu-bug xorg" [14:01] Make sure you login using your Launchpad account, and provide enough details. [14:02] See https://wiki.ubuntu.com/QATeam/Overview/Install_Bugs [14:02] It's for reporting bugs in a VM. [14:03] Don't worry if you're unsure, just report it. Bug triagers will help determine if the bug is valid:) [14:05] Guys, don't be afraid to ask questions, raise it up in #ubuntu-classroom-chat with prefix "QUESTION: " [14:07] [SLIDE 21] Now the installation finished for me [14:07] I clicked "Reboot now" [14:07] It asks you to remove the installation media [14:07] Press "enter" [14:08] it should reboot. [14:08] And when it reboots, it will show a beautiful Ubuntu login scren! [14:08] *screen! [14:09] Login and the Unity should appear:) [14:11] OK, now, back into the ISO QA Tracker. [14:11] [SLIDE 24] It's time to report our result [14:14] Sorry guys, [14:14] got someproblems with my computer [14:15] Back to the results [14:15] If it is a pass, click Passed [14:15] Fail = "Failed" [14:15] For failed results, input the bug number of the bug you reported into the "Critical bugs" section [14:16] If it passed but still has bugs, input in the "Bugs" section [14:16] Leave a comment on how it works [14:17] And also, input the hardware profile link you pastebined earlier using the wiki page's instructions. [14:17] Click "Submit result" [14:17] That's it! [14:18] [SLIDE 26] There are some special images you can pay attention to. [14:18] PowerPC images [14:18] These images are normally under-tested. [14:18] However they exist for Ubuntu, Lubuntu and Kubuntu. [14:19] If you have a PowerPC computer (like the Apple G3 or G5), do help! [14:20] Ubuntu Touch Images. [14:20] balloons, I think you should weigh in on this one... [14:21] Skini151 asked: If my VM results is different from real machine results, what should i do in this case? [14:22] Skini151, well, if it's unreasonable for the results of one machine to happen in the other, report a bug. [14:22] Even the same machine, Skini151 [14:23] Treat a Virtual Machine a bit independent. [14:23] BTW, only use VMs in alpha testing. [14:23] For Betas and Release Candidates, we want REAL machines. [14:23] balloons, can you talk about the Touch images please? [14:24] Ubuntu Touch Images are produced by the phablet team for a series of nexus devices [14:25] originally based on quantal the images have been updated to raring and now saucy :-) [14:25] You can find a series of testcases designed around the images that are specific to each piece of nexus hardware [14:25] The devices are Samsung Galaxy Nexus, Nexus 4, Nexus 7 and Nexus 10. [14:26] Downloading and installing a ubuntu touch image on one of the devices requires a few things [14:26] you need to ensure the bootloader is unlocked first, which is a one time step [14:27] *THIS WILL END YOUR DEVICES' WARRANTY THOUGH" [14:27] Once unlocked you can install anything you wish on the device, including restoring android if you wish :-) [14:28] the phablet team maintains a ppa of tools for flashing here: [14:28] sudo add-apt-repository ppa:phablet-team/tools [14:28] you can then install sudo apt-get install phablet-tools android-tools-adb android-tools-fastboot in order to get the adb bits you need along with the phablet-tools created by the team [14:29] running phablet-flash will then enable you to flash the device, and keep it up to date with new images [14:29] Full details on installing on a device can be found here: https://wiki.ubuntu.com/Touch/Install [14:29] Thanks balloons :) [14:30] Then, off to mininal installation images [14:30] These are called mini.iso images [14:30] They don't reside on our normal daily image repository in cdimage.ubuntu.com [14:30] Instead, they reside on archive.ubuntu.com [14:30] Since they are built off from one package: debian-installer [14:30] These images are the minimal environment you needed to install Ubuntu. [14:31] You can use tasksel to install whatever you want. Ubuntu + Kubuntu + Lubuntu is possible [14:31] And finally, flavour images. [14:31] Official flavours are those distributions that are based off from packages within the Ubuntu archie [14:32] *archive [14:32] They are: Kubuntu, Edubuntu, Xubuntu, Ubuntu Studio, Mythbuntu, Lubuntu, Ubuntu GNOME and UbuntuKylin [14:32] These flavours are always under-manpower [14:32] Especially when it's time to test images [14:33] A normal QA tester doesn't only test Ubuntu images, he/she also spends testing time on these flavours too. [14:33] so, help them! Go to their development IRC channel and subscribe to their development mailing list. [14:33] That's a kickstart point. [14:37] OK, so some hints [14:37] [SLIDE 27] If you see testcases that are marked "Mandatory", run these first. [14:38] These are very important testcases. [14:38] Then run the "Run-once" [14:38] Finally the "optional" [14:38] Don't hesitate to report any bug you find, even if it doesn't make sense to others. [14:38] Try run some testcases at the same time. [14:39] For example, do the "Live session" with the "Install (entire disk)" [14:39] These testcases don't contradict:) [14:40] [SLIDE 28] We have some useful resources [14:40] Skini151 asked: When will start beta testing? [14:40] https://wiki.ubuntu.com/SaucySalamander/ReleaseSchedule [14:41] For Ubuntu, it will only participate in Beta 2 and RC, so that will start around 25th September. [14:41] However most (if not all) flavours will participate in Beta 1 [14:41] Which is 3 weeks earlier [14:41] The resources: [14:42] https://wiki.ubuntu.com/Testing/ISO/Walkthrough [14:42] This is a guide to test ISO images. It also includes a link to balloons's video on testing. [14:43] Contact us through ubuntu-quality@lists.ubuntu.com (do subscribe to us) and also through IRC in #ubuntu-quality [14:44] That's it for today, we hope to see you guys next time!!! And PLEASE help us to test ISO images!!! [14:50] There are 10 minutes remaining in the current session. [14:55] There are 5 minutes remaining in the current session. [15:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || No Sessions Currently in Progress === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Installing and Introduction to bzr - Instructors: chilicuil [16:01] Hello everyone, my name is Javier Lopez: http://wiki.ubuntu.com/~chilicuil [16:01] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html following the conclusion of the session. [16:01] I'm here today to talk a little bit about bzr and its correlation with the Ubuntu QA team [16:01] bzr usage is not limited to the QA team, virtually every Ubuntu team depends on it [16:02] so having a clue of how to use it proves helpful in the case you're interested in joining the Ubuntu family [16:02] technically bzr (or bazaar) is a distributed revision control system [16:02] DRCSs are systems which allow you to manage the storage and distribution of files (mostly code) to many people [16:03] when using a DRCS you get automatic backups, ease to modify files of different persons, freedom to experiment, and more good things, http://en.wikipedia.org/wiki/Distributed_revision_control [16:03] bzr is only one alternative of the many DRCSs available today, other choices are: git, hg, darcs, etc [16:03] in Ubuntu almost all source packages can be fetched from bzr [16:04] and in the QA team, we maintain and develop the Ubuntu testcases with bzr [16:04] I'll continue with a focus in the QA activities and some practical examples [16:04] if you don't understand any step or technical word please let me know and I'll be happy to stop and try to explain [16:05] so, let's take this case, you've had wonderful evenings using Ubuntu and now you're interested in giving something back to the community [16:05] you've joined the QA team and decided you want to help with the Ubuntu manual testcases suite [16:05] this example however will work if you're interested in helping in other areas, docs, code, or design -- as far as a project gets tracked by launchpad [16:05] since you're starting you probably just wanna take a look and see if there's anything wrong such as a typo or a bad redaction [16:06] on this scenario you will eventually reach https://launchpad.net/ubuntu-manual-tests , and more specifically, https://code.launchpad.net/ubuntu-manual-tests [16:06] there you'll see instructions to download full source code (hint: bzr branch...), and a list of branches [16:06] those branches are differentials between the official source code (lp:ubuntu-manual-tests) and the branches themselves (e.g. lp:~noskcaj/ubuntu-manual-tests/parole) [16:06] so, let's start by downloading the code: [16:07] $ bzr branch lp:ubuntu-manual-tests [16:07] if you don't have bzr, you'll need to install it, or ssh ubuntu@vps.javier.io, pass=ubuntu [16:07] $ sudo apt-get install bzr [16:07] while the above command finish, we'll inform bzr who we are [16:08] we do this to allow bzr write complete reports about who changed what in our projects, we also do it because bzr will reject to work if we don't complete this information =P [16:08] $ bzr whoami "Your Name " [16:09] once the bzr branch command finish, you'll see a 'ubuntu-manual-tests' directory, there you'll have the whole project [16:09] inside of it, if you execute 'ls -lah', you'll notice a .bzr directory [16:10] the .bzr directory is the place where all the bzr information is saved, it's better not to play with it [16:10] so, now that we have the code, we can start by taking a look at the files and history, we can see what changes had been done and by whom over the time [16:10] $ bzr log | less [16:10] and you'll see a couple of interesting fields [16:11] my output looks like this: http://sprunge.us/XjFK [16:11] * revno (aka revision): these numbers are spots where specific changes were done and saved, for example, we can go and see how this repository looked at revno #1 and go back to compare with the current status [16:12] in other terminal, go to the 'ubuntu-manual-tests' directory and execute: [16:12] $ bzr revert -r1 #you'll see a list of files who were modified, added or removed, compared to the last version [16:12] $ ls testcases/packages/ | wc -l [16:12] 24 [16:13] 24 is the number of tests and dirs the package section had when the project was exported for the first time to launchpad [16:13] now, if we go back to the present [16:13] $ bzr revert [16:13] $ ls testcases/packages/ | wc -l [16:13] 50 [16:13] you'll see there has been a progress =), so bzr and DRCS are like time machines for files, you can go to any of the revision number and see how it looked at that moment [16:14] there are more interesting information in the 'bzr log | less' command [16:14] * committer: the person which introduced a revision (or whom to blame =P) [16:14] * branch nick: the name of the tree of changes, yep, you can have different trees with full revisions stacks @_@ [16:14] * timestamp: change time [16:14] * message: a description of the change [16:15] so, now that we've looked around, we could review the current files and see if we can find anything wrong [16:15] let's open "testcases/packages/1424_Nautilus\ Tests" [16:15] if we look at it you'll see that this file have an specific format (more of it in the next session) [16:16] right now we're only change some references from Nautilus to Files, as you know Nautilus was renamed to Files and this testcase hasn't been updated [16:16] let's do it, change every reference from Nautilus to Files, I'll wait a couple of minutes [16:20] now we can see our changes by running: [16:20] $ bzr diff [16:21] There are 10 minutes remaining in the current session. [16:21] mine looks like this: http://sprunge.us/SKAb [16:21] The '-' list the old data while the '+' show the updated information, if everything looks ok, we can create one of those nice snapshots in time called revno or revisions [16:21] $ bzr commit -m "description here" [16:21] ... [16:21] Committed revision 143 [16:21] after doing it, if you run: bzr diff, this time bzr won't print anything, this happens because our changes have been saved and we're currently in the head of the tree [16:21] this doesn't mean we won't be able to view again what our changes were, we can look at them (again) if we run: [16:22] $ bzr diff -r142..143 #143 was our revision [16:22] the same command can be run to know the changes between two random revisions [16:22] now, let's imagine that during our edit session we wrote Fils instead of Files in one of the many Nautilus changes [16:22] in that case, we can uncommit our work, fix the botched job and commit it again: [16:22] $ bzr uncommit [16:22] # fix the typo [16:22] $ bzr commit -m "Description" [16:22] Now we're in a stage where our work can be shared with others [16:22] till now, we've only modified local files and the snapshots had been taken in our system [16:22] so, the first step to do is to upload our branch to lp [16:23] however in order to communicate with launchpad we need to setup our ssh public key(s): https://launchpad.net/~chilicuil/+editsshkeys [16:23] if you don't have a ssh key, you can create one with the following command: [16:23] $ ssh-keygen #and pressing enter till you get back the terminal prompt [16:23] after exporting your ssh key, you'll need to tell launchpad who you are: [16:23] $ bzr launchpad-login your_nickname [16:23] if you completed these two steps, you'll be able to communicate safety with lp, let's upload our changes: [16:23] $ bzr push lp:~chilicuil/ubuntu-manual-tests/rename-nautilus-to-files [16:23] as you can see, the path we're using to push the files is not random [16:23] first, it has our username associated, ~chilicuil, after that, it's the name of the project we want to contribute, in this case it is 'ubuntu-manual-tests', and finally it has a name we selected for our branch [16:23] take in consideration that if you look at http://help.launchpad.net, you could see references to 'junk' branches [16:24] for example here: https://help.launchpad.net/Code/PersonalBranches [16:24] $ bzr push ~chilicuil/+junk/rename-nautilus-to-files [16:24] the syntax is very similar, however when uploading to junk branches you won't be able to request merges (that is the possibility to copy your changes to another project) [16:24] t's a common mistake to upload to a junk branch when what you really want is to upload and then request a merge [16:24] so, finally, if your code has been imported, you can request a merge by using the command: [16:24] $ bzr lp-propose #or going directly to your branch in launchpad and select 'Propose for merging' [16:24] other people working in the same project will get your changes by branching the original project (where your changes will land) or using 'bzr pull' to update their branches with the 'master' tree [16:25] so basically that's how we work in the QA team [16:25] there many other commands and ways to use bzr, and people in #ubuntu-quality is familizared with it, so feel free to join us and ask, there also good resources online: [16:25] * http://doc.bazaar.canonical.com/latest/en/mini-tutorial/ [16:25] * http://doc.bazaar.canonical.com/bzr.2.5/en/ [16:25] if you already know git, you can start here: http://doc.bazaar.canonical.com/migration/en/survival/bzr-for-git-users.html [16:25] There are 5 minutes remaining in the current session. [16:26] I think that's all, any question? [16:29] ok, if there is none, I'll end this session right now and will get back in 5 minutes to continue with the next one (ubuntu-manual-testcase collaboration) thanks a lot for following the session (or reading it later) === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Creating and editing Manual Test Cases - Instructors: chilicuil [16:31] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html following the conclusion of the session. [16:33] I'm back =P!, on this session I'll talk about the ubuntu-manual-testcase suit and how to contribute to it [16:34] this will be a full interactive session, so feel free to launch your terminal and get your launchpad credentials [16:34] I'll be doing live edition in ssh ubuntu@vps.javier.io pass=ubuntu, feel free to connect [16:34] the ubuntu-manual-testcase: https://launchpad.net/ubuntu-manual-tests [16:34] is where the packages.qa.ubuntu.com and iso.qa.ubuntu.com testcases live [16:34] from lp they're exported to *.qa.ubuntu.com where are consumed by testers during the cadence weeks: https://wiki.ubuntu.com/Testing/Cadence/ [16:35] it's an extremely easy way to get started with the Ubuntu family and more specifically with the QA team [16:35] if you followed the bzr session you'll already have an 'ubuntu-manual-tests' directory in you $HOME [16:35] if you didn't follow it, you can fetch the complete project with this command: [16:35] $ bzr branch lp:ubuntu-manual-tests [16:35] once you have the project, we can open any of the testcases [16:36] but first let's go to: http://packages.qa.ubuntu.com/qatracker/milestones/281/builds/47603/testcases/1422/results [16:36] and then to 'Testcase' to see how testcases actually look when deployed [16:36] in my computer it looks like this: http://i.imgur.com/zo32w8l.png [16:37] now, let's open the testcase file: testcases/packages/1424_Nautilus\ Tests [16:38] now, you'll see that this file is mostly and html one [16:39] all manual testcases get differente sections, each one defined by the 'Test-case name: app/TC-SHORTCODE-NUMBER' [16:40] when creating a new testcase you don't need to worry by the testcase number, people will assign one to it once it gets merged [16:41] so, after the first line, which is Test-case name: nautilus/TC-NFM-001 (to define that what follows is the first test of the Nautilus testcase suite) [16:42] follows a short description of what the test will try to prove, on this case it will try to verify if Nautilus (now Files) is able to create new files, which is a very basic feature expected from a file manager [16:44] tests can depends in others to test functionallities, for instance, if we're gonna write a test to check if Nautilus can change the name of a file, it can depend of the creation of that file, the sintax is: depends: app/TC-SHORTCODE-NUMBER [16:45] once described the test, follows the actual steps to verify if the desired behavior works or not [16:46] as you can see it has an specific format, which is basically, dl tags for the complete test,

tags for steps, and

for expected results [16:48] when creating new manual testcases, it's recommended that you start by write down all the desired results and steps in plain text, and format it at the end [16:50] required testcases are filled as bugs in https://bugs.launchpad.net/ubuntu-manual-tests/+bugs, currently we're trying to test the functionallity of all default applications in Ubuntu and derived Ubuntu flavors [16:50] that's why there are many new reports opened [16:50] There are 10 minutes remaining in the current session. [16:51] feel free to grab anyone if you feel confortable with the usage of one default ubuntu application [16:51] right now, I'll take a look at https://bugs.launchpad.net/ubuntu-manual-tests/+bug/1183929 [16:52] which is a report who tracks the status of the konsole testcase, konsole is the default X terminal emulator for KDE [16:53] when creating a testcase, you must do it in an ubuntu development version, right now in an ubuntu saucy env [16:54] you can use virtualbox, an spare machine or a chroot to run safety the ubuntu dev version: https://wiki.ubuntu.com/UsingDevelopmentReleases [16:54] what I'll do right now is to open a new instance of pbuilder, $ sudo DIST=saucy ARCH=i386 pbuilder login [16:54] install konsole, and then run it [16:55] I'll take as a reference testcases/packages/1422_Gnome\ Terminal\ Tests [16:55] There are 5 minutes remaining in the current session. [16:57] so if we go back to our online environment, you can see how I do it, I'll open both files, testcases/packages/1422_Gnome\ Terminal\ Tests and a new testecase file for Konsole, testcases/packages/Konsole\ Terminal\ Tests [17:00] so, I'll start by adding: Test-case name: konsoleterminal/kter-001 and then a description [17:00] http://pastebin.ubuntu.com/5817319/ [17:00] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || No Sessions Currently in Progress === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || Current Session: Creating and editing Manual Test Cases - Instructors: chilicuil [17:09] for now, I'll only complete the first testcase so I can show you how to send those changes to the ubuntu-manual-tests project [17:10] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html following the conclusion of the session. [17:10] however the more detailed one testcase can be done the better [17:11] right now my testcase file looks like this: http://pastebin.ubuntu.com/5817338/ [17:11] when we start working on a testcase it's a good idea to assign the report which tracks the status to ourselves [17:12] on this example, I'll assign the Konsole testcase to me, you can do it by going to the launchpad report and click the 'unassigned' button and then 'Assign me' [17:13] now, going back to our tree if we run: $ bzr status [17:14] we'll see that our file figures as: Unkown, that's because it has not been added to the tree, is a complete new testcase! [17:14] we can add it by running: $ bzr add 'testcases/packages/Konsole Terminal Tests' [17:14] and then: $ bzr commit -m "New Konsole testcase" [17:17] and after adding to the local tree, we can share it to the world with: $ bzr push lp:~chilicuil/ubuntu-manual-tests/new-konsole-testcase [17:20] now if you go to your launchpad profile, to the code section, https://code.launchpad.net/~ you'll see the branch you've just pushed [17:20] There are 10 minutes remaining in the current session. [17:21] in my case it's here: https://code.launchpad.net/~chilicuil/ubuntu-manual-tests/new-konsole-testcase [17:21] so, I'm gonna propose the change and add a description, which may be as simple as: Adds Konsole Testcase [17:22] now, it'll get review and probably approved by one of the testcase admins: https://code.launchpad.net/~chilicuil/ubuntu-manual-tests/new-konsole-testcase/+merge/172372 [17:23] as we know that handling html tags can be troublesome, we created a script which will let you know if your testcase is ready for review: https://wiki.ubuntu.com/QATeam/ContributingTestcases/ManualStyleGuide/test_case_format_script [17:24] ensure you run it before actually pushing to the ubuntu-manual-tests project [17:25] we're always open to new contributors so if by any change you feel like contributing to the ubuntu-testcase suite join us at #ubuntu-quality and let us know [17:25] there is also a nice tutorial step by step here: https://wiki.ubuntu.com/QATeam/ContributingTestcases/Manual in case this session were horrible for you [17:25] There are 5 minutes remaining in the current session. [17:29] QUESTION: how do I know what applications need tests? [17:29] right now we're focusing in the default ubuntu applications, you can get a full list here: https://bugs.launchpad.net/ubuntu-manual-tests/+bugs, you can assign any of them [17:30] QUESTION: How do I know what to test in my testcase? [17:30] at the beggining you can focus in the more obvious features, however the more detailed the better [17:30] we intend to really improve the ubuntu quality [17:30] Logs for this session will be available at http://irclogs.ubuntu.com/2013/07/01/%23ubuntu-classroom.html === ChanServ changed the topic of #ubuntu-classroom to: Welcome to the Ubuntu Classroom - https://wiki.ubuntu.com/Classroom || Support in #ubuntu || Upcoming Schedule: http://is.gd/8rtIi || Questions in #ubuntu-classroom-chat || No Sessions Currently in Progress === bipul is now known as koolbrain17 === koolbrain17 is now known as Dexter === Dexter is now known as Dexter_ === emma is now known as em