🚀 go-pugleaf

On 22 Maj, 15:44, A.L. <f...@2005.com> wrote:
> On Mon, 21 May 2007 23:26:17 +0200, Seweryn Habdank-Wojewódzki
>
> <shw_m...@wp.pl> wrote:
>
> >No to jeśli ich Pan nie wiedział, to czemu się Pan w ogóle wypowiada na ich
> >temat.
>
> >Podaję jeszcze raz jeden z nich:
>
> >http://www.programmingresearch.com/solutions/qaj2.htm
>
> >>>> Mnie nie interesula linki na temat QA
>
> Ja sie nei wypowiadalem na ich temat. Ja napisalem ze je olewam. Ten
> link powyzej, na przykald, uzywa slow QA ale nic nie ma wspollnego z
> QA, albowiem QA nei zajmuje sie, cytuje, "software metrics". QA
> zajmuje sie zgodnoscia systemu ze specufikacja UZYTKOWA i sposobel w
> jaki owe wymagania UZYTKOWE sa spelnione. czyli patrzy na system okiem
> uzytkownika.

To jest, z kolei, pański sposób interpretacji pojęcia QA. Wszystko
zależy
wyłącznie od tego, w jaki sposób to pojęcie definiuje firma - od
niczego
więcej.

Przykładowo, w Aldecu terminem QA określało się testerów, przy czym ci
testerzy testowali wszystko jak leci różnymi metodami. Nie wnikałem w
to,
jak oni opracowują procedury do testowania. Pomijając już taki
szczegół, że
potrafili czasem zgłaszać z wysokim priorytetem bugi, które - jak
potem
doszedłem po historii kodu - prześlizgnęły się przez dobre 5 wydań.

W Motoroli z kolei QA był to zespół odpowiedzialny za pilnowanie
zgodności z
procesem. Dostawali metryki, opracowywali je, kontrolowali
poszczególne
czynności. Nie miało to nigdy nic wspólnego z istotą kodu, który jest
pisany.

W tej firmie, w której pracuję teraz, definicja jest jeszcze inna.

Mówiąc inaczej, są takie QA i inne. Może więc zamiast używać
określenia QA i
stanowczo twierdzić, co QA robi, a co nie, powiedzmy sobie po prostu
jasno i
szczerze, jakie czynności procesowe są potrzebne do zapewnienia
szeroko
pojętej jakości oprogramowania i jak się je zapewnia.

> >Fakty są takie, że firma, która zajmuje się QA za pieniądze oferująca
> >produkt dla firm zajmujących się PRODUKCJĄ oprogramowania wie co robi.
>
> Firma stosuje "stragehie hype" (jezeli to mowa o powyzszym linku),
> albowiem jak napisalem, QA sie tym nie zajmuje.

Mnie tam średnio rusza posługiwanie się określeniem właściwie lub nie
- hasła
są dobre dla managerów.

> >To już wiemy. Niech sobie Pan lepiej przypomni co Pan wiedział o pisaniu
> >oprogramowania w moim wieku.
>
> Zapewne wiedzialem jeszcze mniej niz pan. Ale: a) nie uwazalem ze
> wiem, b) sluchalem innych

A teraz osiągnął pan wiek, w którym: a) uważa, że wie, b) nikogo nie
słucha.

> >To niech się Pan pospieszy, bo zanim się Pan zorientuje to kompilacja w
> >locie będzie Panu oceniać kod i potem go testować (również w locie), zanim
> >zostanie uruchomiony dynamiczny moduł.
>
> Nie rozumiem co Pan ma na mysli. Zaden tool nie bedzie mi ocenial kodu
> (niby jak?... Po ilosci linii?...)

Akurat ilość linii to jest metryka, która w praktyce średnio
kogokolwiek
interesuje. Te i inne elementy, że się tak wyrażę, "procesu IBM-
owskiego" są
traktowane dziś przez wiele firm dość pobłażliwie. Wiele z tych
elementów jest
wartych stosowania (np. przeglądy kodu), tyle że IBM-owska definicja
jest
mocno na bakier z rzeczywistością.

> i nie bedze go testowal.

Jasne, oczywiście - sami lepiej go przetestujemy przez klikanie.

> A poza
> tym, wie Pan... Unit tests to nie sa jedyne etsty. Jak dwa moduly sa
> unit tested, to nie ma zadnej gwarancji ze razem bada dobrze
> pracowaly.

Odkryłeś pan Amerykę. Zgadza się - od tego właśnie są następnie testy
integracyjne, regresyjne i funkcjonalne. Oczywiście wszystkie w pełni
zautomatyzowane.

> Do tego sa inni ludzie zwani "testerami" ktorzy robia takie
> testy wlasnie.

Aaaa, to pan jesteś dopiero na tym etapie. Widzę, że się za szybko
wyrwałem z
tym poprzednim zdaniem.

Niestety, ci "inni ludzie" zajmują się tylko i wyłącznie
opracowywaniem
wymagań i tworzeniem procedur koniecznych do zweryfikowania zgodności
wymagań
z wykonywanym programem. Stopień zautomatyzowania może być różny -
oczywiście
w przypadku nie istnieniania zautomatyzowanego testu dla danej
procedury wykonuje
się ją ręcznie. Ale wykonywanie procedur to nie jest główne zadanie
zespołu
testującego - głównym zadaniem tego zespołu jest ich opracowywanie.

> W zaleznosci od miejsca ejst to osobna organizacja,
> albo sa wmontowani z development team. W kazdym razie ich jedynym
> zadaniem jest robienie testow funkcjonalnych, integracyjnych,
> regresyjnych itede.

Tak się akurat składa, że jedyne testy, które jest trudno
zautomatyzować, to
testy funkcjonalne (i funkcjonalne części testów regresyjnych). Testy
integracyjne są akurat mocno związane z kodem i najczęściej da się je
w pełni
zautomatyzować - oczywiście zależy to od tego, czy aplikacja (system)
ma
wbudowane możliwości odpowiedniego testowania.

Poza tym testy integracyjne - podobnie jak jednostkowe - też często
korzystają
z ograniczonej funkcjonalności, bo interesuje ich współpraca kilku
modułów, a
nie cały działający system. W testach integracyjnych zatem również
zupełnie
normalną rzeczą jest tworzenie zaślepek do modułów, które w danym
teście nie
podlegają testowaniu.

Rozumiem, że kiedyś ludzie nie mieli pojęcia o tym, żeby tak pisać
testy
integracyjne, tylko klepali testy integracyjne ręcznie na w pełni
działającym
systemie. Ale to już przeszłość.

Napisałbym nawet z chęcią, że "widocznie w Ameryce dopiero muszą do
tego
dojść", gdyby nie taki szczegół, że sam pracuję w amerykańskiej firmie
i wiem,
że Amerykanie doszli do tego już dawno i to nawet chyba jako pierwsi.

> Nei maja ci ludzie nic wspolnego z QA, bo QA to
> zupelnie osobna organizacja, i jak pisalem, kodu na oczy nie widzi.
> Powtarzam na wszelki wypadek jeszcze raz.

Jeśli przyjąć, że QA to nie jest Quick Aquisition, tylko Quality
Assurance, to
teoretycznie taka organizacja powinna zajmować się wszystkimi
rzeczami, które
są konieczne do zapewnienia jakości kodu.

Jeśli zapewnienie jakości kodu wymaga, aby kod został sprawdzony pod
określonym kątem, i można to wykonać odpowiednim narzędziem, to QA
będzie się
zajmowało sprawdzaniem kodu za pomocą odpowiedniego narzędzia.

>
> >> , ale nie maja nic wspolnego z rzeczywistoscia.
>
> >Rzeczywistością, czy jakimiś skostniałym patrzeniem na świat?
>
> Niby ze jakim?... Ja Panu pisze o tym co sie w firmei dzieje na dzis.
> Dzialo sie tak samo w firmach w ktorych pracowalem poprzenio.

Niech zgadnę - jedną z nich był IBM?

> Jezeli
> ma Pan jakies recepty na odswiezenie skostnialego przemyslu
> amerykanskiego, prosze rozwinac skrzydla

Recepty są i wiele firm - i to przede wszystkim amerykańskich - od
dawna je
stosuje. Znam jednak firmy (również amerykańskie - przypadkiem akurat
wszystkie firmy, w których pracowałem, są amerykańskie), które nie
stosują i
wydaje im się, że im jest z tym dobrze.


Pozdrawiam,
Ethouris