Re: Test case draft for Basic networking test case
Linux Pundit <[email protected]> Tue, 9 Dec 2025 07:47:04 +0530
| Newsgroups | gmane.linux.redhat.fedora.testers |
|---|---|
| Message-ID | <[email protected]> |
On 09-12-2025 00:19, Brandon Nielsen via test wrote: > On 12/8/25 9:31 AM, Kamil Paral wrote: >> On Fri, Dec 5, 2025 at 6:25 PM Adam Williamson >> <[email protected] <mailto:[email protected]>> wrote: >> >> On Fri, 2025-12-05 at 17:14 +0100, Lukas Ruzicka wrote: >> > Hello, >> > >> > The QA team has been missing test cases to test Basic networking. >> I have >> > written a draft of the test case and now I am collecting >> suggestions on how >> > to improve it, check if anything is missing, or if something >> needs to be >> > changed. >> > >> > The Basic networking test case is here: >> > https://fedoraproject.org/wiki/QA:Testcase_Basic_networking >> <https://fedoraproject.org/wiki/QA:Testcase_Basic_networking> >> > >> > We will also need to create a WIFI test case and a VPN test case, >> both the >> > CLI and GUI variants, so if anybody has ideas how to do it, let >> me know. >> > >> > Thanks for your help. >> >> Thanks for writing this! >> >> It seems...long. :D I get that it's trying to encapsulate >> everything in >> the criterion, but it's a bit overwhelming. Still, it is very >> comprehensive and robust. >> >> I think when I wrote the criterion I was envisaging something a bit >> shorter, sloppier and vaguer, that mostly relied on the tester's >> 'typical' network configuration and was just 'try and open a web >> site, >> does that work?' kinda stuff. But...maybe this is better? >> >> Curious to know what others think. Do we prefer something very >> detailed >> and 'clean room' like this? >> >> >> Hmmm. First of all, thanks, Lukas, for clearly giving it a lot of >> effort! Unfortunately, I'm afraid that this amount of effort will >> make it one of those "nobody wants to do it" test cases, because it's >> long and complex. But it depends what we want to do with this. If >> this is to be automated, then big +1 from me, let's do it. If this is >> intended to be a manual test, then I think we need to simplify it, >> and not just because of length, that's just one of my concerns. One >> of my other concerns is that this is... too short. Networking >> requires a lot of know-how and in many areas it seems it doesn't go >> deep enough, which means further expansion to explain some steps in >> more detail would be needed. For example, it uses keywords like >> "enp1s0" but doesn't explain how to figure out what *your* actual >> network device is called. The same goes for IP ranges, connection >> names ("Wired connection 1"), and maybe some more. >> >> Using VM as a remote server is of course the most straightforward >> idea, but it has its own pitfalls. For example, ping doesn't work in >> libvirt user session, only system session (at least according to my >> past experience). The IP ranges will vary (unlike in the testcase, >> mine is 192.168.124.0/24 <http://192.168.124.0/24>). And of course, >> the tested system is often a VM itself. Does this testcase assume >> nested virt in that case? Or VM<->VM connection? This will definitely >> get even more complex, if we want this to be followed by the general >> public with heavily varied networking environments. >> >> I also see two possible goals of this test case, and I'm not sure >> which one was the intended one. The first goal is to verify that the >> very networking basics work, setting an IP address, ping, curl, etc. >> This test case verifies that. The other goal is to test that the >> real-world network works on a particular device of the tester. So >> actually sending packets to your router and to the internet, >> receiving a web page, etc. Since this test case uses a local VM, are >> those packets even going through the network card, or are they just >> "virtualized" in the kernel? I have no idea. But it surely doesn't >> test that your wifi connection works fine, or cable speed negotiation >> with your router, and that you can open fedoraproject.org >> <http://fedoraproject.org>. The first goal is great for automation, >> the second goal is good for human testers with varied hardware. >> >> It might be best if we can do both. Convert this into an OpenQA >> script that will run tirelessly each compose. The steps are exact, no >> need for a human tester to repeat it. And let's have a simplified >> version for humans, that will test connecting to a wifi/cable, >> pinging a well-known server, opening a website (note that we already >> have https:// fedoraproject.org/wiki/QA:Testcase_desktop_browser >> <https:// fedoraproject.org/wiki/QA:Testcase_desktop_browser> for >> that, though), and possibly some optional stuff like switching a dns >> server. The wifi seems like the most important stuff to me (for human >> testing), because we can't easily replicate that in OpenQA (most of >> the other stuff we can). >> >> > > I generally agree with all the above, it looks like "too much" and > likely to drive people off. If it could be largely automated, that > would be excellent. > > That being said, I was able just now to complete the tests between two > usermode VMs created and run via Boxes. It was pretty straightforward > to complete. > > As for the wording of the test case itself, I would like to see the: > > `sudo nmcli con add type ethernet ifname enp1s0 con-name static` > > invocation added to the "Set up static networking on the tested > machine (nmcli)" section as well so you can just copy paste the > following commands. > > It might also be nice if the "Deactivate the existing connection" > verbiage made it clear "existing" isn't some network-manager magic, > and that you need to figure out your "existing" connection name via > `nmcli connection show` as is made explicit in the server > configuration section. > detailed testing layout is a must. maybe broken/arranged into categories based on "layers" of networking -- _______________________________________________ test mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue