QA szoftvertesztelési automatizáció - melyik programnyelv?

Ha az adatelemzői énemet kérdezed, eléggé egyértelmű a válasz részemről: Python és egy csipetnyi R. Viszont most QA vezetőként szeretném megosztani személyes meglátásaimat és tapasztalataimat a témakörben, s egyik sem kánon, csupán meglátás, amely az adott helyzet korlátai között értelmezendő.

Illeszkedő Stack

Először is érdemes azt a nyelvet választanod, amelyikben fejlesztik a tesztelendő szoftvert. Ez főleg azóta igaz, amióta a JavaScript is kiszabadult a Node.js-nek hála a böngészőkből. Nincs olyan népszerű nyelv amelyhez ne lennének tesztelési keretrendszerek és/vagy Selenium binding. Ez azért hasznos, mert ha elakadnál valahol, akkor egy halom ember áll rendelkezésedre a környezetedben, akik segíteni tudnak. Fontos tapasztalat, mielőtt kérdezel, tedd fel a kérdésed a kötelező kellékként nálad lévő Debug kacsának, mert különben könnyen irritábilis szindrómává válasz a fejlesztő kollégáid körében...

Multi Stack

A jelenlegi cégemnél a fejlesztési célplatformok nagyon tág kört ölelnek fel (backend, frontend, mobil, IOT, beágyazott eszközök stb.), rengeteg programozási nyelvvel. Ha a csapatod nagyon erős a kódolásban, akkor is lehetetlen feladat ennyi ökoszisztémát kellő mélységgel átlátni. Ezért a stratégiánk az volt, hogy legyen egy közös nyelvünk a csapatban, hogy könnyebben legyen az emberek rotálása, és egymás helyettesítése.

JavaScript (Stack része)

Első körben a JavaScript-vel próbálkoztunk meg csapatszinten, mert nem volt olyan terület, ahol ne lett volna a része valamilyen szinten stack-nek (Mobil: Corodova, React Native, Backend: express.js, socket.io, Frontend: React stb.). Bár nem volt olyan terület, ahol ne lett volna megoldás (pl. IOT eszközre is csináltunk prototípus service-ket), de pár problémába sajnos beleütköztünk. Az első, hogy a kódolás világában kezdő kollégák számára nehézséget okozott az aszinkron programozás koncepciója. A másik, hogy projekt cég révén sokszor váltunk projektet, és van hogy fél év múlva ismételten elő kellett venni megoldásokat. Nem volt olyan eset, ahol a függőségek frissítésekor ne kellett volna átírnunk az adapter osztályokat. Sajnos az npmjs csomagjainál nem szempont az API felület védelme, még a puppeteer esetében sem.

Python (Új nyelv)

Végül hiába próbáltunk meg a meglévő stack-ből választani programozási nyelvet, végül Python lett a befutó. Hátrány, hogy ez egy plusz nyelv a cégnél alkalmazott stack-ek nyelveihez képest. Bár jobban örülnék egy Flask-os/Django-s backend-nek, mint PHP-s társainak, de ez csak személyes és elhallgatott vélemény. Előny, hogy kevesebb kódbázist termelünk pl. Java-hoz képest, ami azt eredményezi, hogy kevesebb idő a tesztelési kódbázis karbantartása is. További előny, hogy kezdő kollégák, hamar tudnak kisebb részfeladatok szintjén produktívan közreműködni. Itt is igaz, hogy nincs olyan tesztelési témakör, amelyre ne volna megoldás. Pl. CAN hálózatokkal kapcsolatos megoldásokat is tudunk integrációsan tesztelni. Érzésre valamiért az általunk használt programkönyvtárak fejlesztőik fegyelmezettebbek a megoldásuk által kínált programozási felületek megőrzésében. Egy fél év után újrakezdett projektnél, maximum csak a függőségek verziószámát kell frissíteni, jóval ritkább, hogy újra nyálazhatjuk át az adapter osztályokat.

Összegzés

Tehát itt is igaz, hogy nincs egyértelmű válasz, hisz mindegyik nyelv csupán egy eszköz a saját előnyeivel és hátrányaival.

1. Ha lehet, olyan nyelvet válassz, amit a csapatod is használ fejlesztési nyelvként.
2. Ha csak ismerkedsz a kódolás világával, akkor a Python-t ajánlanám.
3. Mind a Java, C#, JavaScript, Ruby is alkalmas arra, hogy elindulj a kódolás izgalmas világába...

UI: Bár izgalmas világ, de nagyon sok idődet fogja elvenni, nagyon sok idődet... Forrás

Full Page Screenshot of a Website

Teljes képernyő mentése weboldalról

Siralmak

A Selenium Webdriver képernyőmentési interface-nek megváltozásával keresztbe húzták jó pár tesztelő számítását. Sajnos WebElement-eknek hiába van képernyőmentési interface-e, gyakorlatilag nem működik. Jó pár hajszálam ment rá mire egy kolléga rájött a megoldásra.

Környezet és megoldás

Idén úgy döntöttünk, hogy a QA csapat által használt nyelv JavaScript lesz és kihasználjuk a Node.js futtatási környezet előnyeit (illetve hátrányait). Ezért el kezdtük használni a Puppeteer megoldását. Ott is a képernyőmentés teljesen esetlegesen működött, míg nem találtunk egy workaroud-ot. Hosszan ecsetelhetném, hogy miket próbáltunk ki (pl. figyeltük, hogy a document.images mind betöltődött-e, stb.), de aztán a megoldás az lett, hogy 2x egymás után kell csinálni képernyőmentést, és a második az esetek 99%-ban jó lesz...

Korlátok

A webelement-ek esetén ez a móka sajnos nem működik, de egy kis képmetszés és már a webelement-ekről is vannak szép képernyőmentéseink. Fontos korláta a dolognak, hogy a setViewport metódusnak olyan beállítást adunk, amely triggerelné a chromium készülék emulációját, akkor ez a workaround sem működik...

Példa Kód

const puppeteer = require("puppeteer");
const url = "http://index.hu";

const viewport = { width: 250 };

(async () => {
  const browser = await puppeteer.launch();
  const page = await browser.newPage();

  await page.goto(url, {
    waitUntil: "networkidle2"
  });

  await page.setViewport(Object.assign(page.viewport(), viewport));

  await page.screenshot({
    path: `./scnapshot-${Date.now()}-${viewport.width}x${
      viewport.height
    }.jpeg`,
    type: "jpeg",
    fullPage: true
  });

  await page.screenshot({
    path: `./scnapshot-${Date.now()}-${viewport.width}x${
      viewport.height
    }.jpeg`,
    type: "jpeg",
    fullPage: true
  });

  await page.close();
  await browser.close();
})();

Remények

• Jó lenne, ha a Webelement-eken működne a képernyőmentési interface, mert jó lenne ha több böngészőn is tudnánk snapshot jellegű tesztelést végezni
• Én annak is örülnék, ha újra az összes böngésző a teljes képet renderelné ki képernyőmentés esetén...
• De ha a Yandex aShot megoldása is működne, annak is nagyon örülnék...

macOS Mojave vs Pyenv - Build Failed megoldás

Hibajelenség

Ma végre rászántam magam, hogy újrahúzzam a rendszerem, és egyből jött is a fekete leves. Pyenv szokásos parancs pyenv install 3.7.2 után szép kis hibaüzenet BUILD FAILED (OS X 10.14.1 using python-build 20180424)

Megoldás

1. Győzödjünk meg róla, hogy az xcode telepítve van, ha nem akkor
   xcode-select --install
2. Majd pedig jöhet a megoldást hozó parancs
   sudo installer -pkg /Library/Developer/CommandLineTools/Packages/macOS_SDK_headers_for_macOS_10.14.pkg -target /

Az érdem ismételten nem az enyém, hanem FORRÁS

Szemöldökráncolás és PHP III.

Type hinting

class Task
{
    protected $title;
    protected $complete;

    public function __construct(string $title,
                                bool $isComplete = false)
    {
        $this->title = $title;
        $this->complete = $isComplete;
    }

    public function isComplete(): bool
    {
        return $this->complete;
    }
}

$task = new Task("Go to the store", "false");

var_dump($task->isComplete());

Az eredmény bool(true), ami nem meglepő, hiszen a nem nulla hosszúságú karakterláncok logikai értéke igaz, viszont ami melepő, hogy alapértelmezetten nem akad ki az interpreter. Magunknak kell rendelkeznünk arról, hogy declare(strict_types=1); hogy nehogy ilyen kis BUG forrást vigyünk a rendszerbe...

Szemöldökráncolás és PHP II.

Függvényhívás tömb paraméterrel

Kódrészlet

function addElement($list)
{
    $list[] = 4;
}

$myList = [1, 2, 3];

addElement($myList);

var_dump($myList);

Eredmény

array(3) {
  [0]=>
  int(1)
  [1]=>
  int(2)
  [2]=>
  int(3)
}

Ismét csak a python-os, C#-os, Java-ás stb. beidedződés alapján azt várnám, hogy a $myList tömb négy elemű lesz, amelynek negyedik eleme 4. Value type VS Reference type. A PHP a tömböknél nem a referenciát adja át, hanem másol, gyakorlatilag érték típusként viselkedik. A megoldás & operátor alkalmazása a pareméterek definiálásánál... Az csak történelmi érdekesség, hogy PHP4-es esetében az objektumoknál is alkalmazni kellett az & operátort, például assignment esetén is. Szerencsére azóta már az objektumok Reference type-ok a PHP varázslatos világában is...

Szemöldökráncolás és PHP I.

Változók hatásköre

Van pár programozási nyelv, amellyel foglalkoztam és vannak titkos kedvencek is, de van hogy az embernek olyan programozási nyelvvel kell foglalkoznia, amely nem a szíve csücske, de attól még munkája során megkerülhetetlen. A legjobb tanulás, ha az ember másoknak magyarázza el az "AHA" élményeit. Tehát ez a kis sorozat amolyan személyes kis jegyzet, amely segít rögzíteni a friss élményeket.

Az alábbi kód a következő hibát dobja Notice: Undefined variable..., ami a nem túl kellemes frusztráció élményét okozza, ha az ember a python LEGB változó hatáskörének szabályain nőtt fel...

$myGlobal = 1;

function printGlobal()
{
    echo $myGlobal;
}

printGlobal();

Természetesen a PHP javára kell írni, hogy ezzel a húzással egyértelművé teszi hogy egy a függvényen belüli lokális változóval dolgozunk, vagy pedig egy globális változóval...

$myGlobal = 1;

function printGlobal()
{
    global $myGlobal;
    echo $myGlobal;
}

printGlobal();

macOS Sierra - Nem jelennek meg az alkalmazások a Spotlight-ban

El kezdtem ismerkedni a PC világa után egy kicsit a Mac világával, és már a kezdetekkor szembetaláltam magam egy igen idegesítő bug-val.

Az újonnan telepített alkalmazások nem jelentek meg a spotlight-ban. A hivatalos support által javasolt megoldás sajnos nem segített. Végül a következő megoldás hozott eredményt:

• Spotlight kikapcsolása
  sudo mdutil -a -i off
• Spotlight kiürítése
  sudo launchctl unload -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
• Spotlight betöltése
  sudo launchctl load -w /System/Library/LaunchDaemons/com.apple.metadata.mds.plist
• Spotlight újraindítása
  sudo mdutil -a -i on

Tanulság, hogy minden rendszer használata szívás, és minden rendszernek meg van a maga előnye.

Forrás