Introduction:

As a qa-automation tester in Product QA for SLES and SUSE-Manager, the SUTs I test (system under test) (like SLE-12-SP2-beta-etc) are changing every day (new packages, patches are merged to SP2, files changes and so on).

Problem: we don't have a tool that give us metadata about the system, like machinery well do.

machinery inspect SUT machinery show SUT

Problem : what changed from system SLE12-SP-BUILD 8000 from to 8400 ? ( oh, i lost the mail from release manager ! )

machinery compare Problem : i found a regression with systemd-tests-suite on SLEnkins: the testsuite fail on BUILD 7400 , but build 7399 is still OK.

what exactly has changed for the package, but also for the system? -> Machinery

Problem: As QA i found a BUG on NFS. I have to report a bug.

Machinery can help me to fill the bug, giving me exact information about really different systems (SLES-12-SP1, openSUSE), etc, what has changed with NFS ? Or Fedora side?

RESULTS

First i want to thank the machinery team, especially Mauro and Manuel that supported me. On this hackweek, have integrated machinery for qa-automation on the library https://github.com/okirch/susetest, and in the SLEnkins automation Framwork.

This work really nice, for scanning systems under test. (SLES, openSUSE)

For qa-automation, machinery works nice and i achieved what i was expecting ! :)

I can scan, compare systems. This could be a FEDORA, DEBIAN, ArchLinux whatever against a openSUSE or a SLES.

In QA and Development, and even Relase Management Perspective this is awesome.

NEW HACK ! :

Revolutionar Perspective for QAAUTOTESTING with Machinery

I'm really glad, i can show you this :

https://slenkins.suse.de/jenkins/job/suite-machinery/32/console

In this example, i compare a SLES-12-SP2-LATEST, with 3-4 builds before.

RESULTS is amazing

With machinery i achieved to compare differents builds from SLES-12-SP2, thanks to the scope, i can see exactly was has changed and was not. I can compare a SLE_12-SP2-GNOME with a SLE-12-SP2-Default, and tracks perfectly changes.

Concrete examples are here :

Scan of a system With console log for machinery ( after the tests are executed) https://slenkins.suse.de/jenkins/view/Test%20suites/job/suite-machinery/13/console

Or with the inspect command redirect to a file.txt to workspace jenkins:

``` setup() machinery_sut = machinery(sut)

try: sometest(sut) machinerysut.inspect() machinerysut.show("tests-machinery") machinerysut.compare("SLE-12-SP2-BUILDXXX-GNOME") ```

Join this project Leave this project

Looking for hackers with the skills:

qa-automation susetest python slenkins machinery

This project is part of:

Hack Week 14

Activity

over 8 years ago: okurz liked this project.

over 8 years ago: dmaiocchi added keyword "machinery" to this project.

over 8 years ago: dmaiocchi added keyword "slenkins" to this project.

over 8 years ago: dmaiocchi added keyword "qa-automation" to this project.

over 8 years ago: dmaiocchi added keyword "susetest" to this project.

over 8 years ago: dmaiocchi added keyword "python" to this project.

over 8 years ago: mamorales liked this project.

over 8 years ago: evshmarnev liked this project.

over 8 years ago: e_bischoff liked this project.

over 8 years ago: dmaiocchi started this project.

over 8 years ago: dmaiocchi originated this project.

Comments

over 8 years ago by e_bischoff | Reply

For point 2), snapshots would be an alternative. Which does not mean that using machinery to do that is not interesting - on the contrary!

over 8 years ago by dmaiocchi | Reply

ok first result are avaible here: https://slenkins.suse.de/jenkins/view/Test%20suites/job/suite-machinery/10/console