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