eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.comp.programming[newbie] Test porównawczy języków programowaniaRe: Test porównawczy języków programowania
  • Path: news-archive.icm.edu.pl!news.icm.edu.pl!uw.edu.pl!newsgate.cistron.nl!newsgate.
    news.xs4all.nl!news2.euro.net!82.197.223.103.MISMATCH!feeder3.cambriumusenet.nl
    !feed.tweaknews.nl!postnews.google.com!v12g2000vbx.googlegroups.com!not-for-mai
    l
    From: Andrzej Jarzabek <a...@g...com>
    Newsgroups: pl.comp.programming
    Subject: Re: Test porównawczy języków programowania
    Date: Fri, 21 Jan 2011 03:12:49 -0800 (PST)
    Organization: http://groups.google.com
    Lines: 87
    Message-ID: <a...@v...googlegroups.com>
    References: <1...@3...googlegroups.com>
    <n...@4...com>
    <ig760o$nni$1@inews.gazeta.pl>
    <7...@4...com> <igea6t$fca$1@news.onet.pl>
    <9...@d...googlegroups.com>
    <igf0o6$p8v$1@news.onet.pl>
    <7...@n...googlegroups.com>
    <igfcnh$eu$1@news.onet.pl>
    <6...@l...googlegroups.com>
    <igfkqd$t5m$1@news.onet.pl> <igg4g4$kie$1@inews.gazeta.pl>
    <igh3lk$r55$1@news.onet.pl> <ih6o2v$1bp$1@news.onet.pl>
    <ih6pdt$6e9$1@news.onet.pl> <ih6rep$e02$1@news.onet.pl>
    <ih6sn9$ij2$1@news.onet.pl> <ih7ji3$5af$1@news.onet.pl>
    <ih9jlt$ce$1@news.onet.pl>
    <1...@e...googlegroups.com>
    <ihbkor$qp4$1@news.onet.pl>
    NNTP-Posting-Host: 195.11.67.225
    Mime-Version: 1.0
    Content-Type: text/plain; charset=ISO-8859-2
    Content-Transfer-Encoding: quoted-printable
    X-Trace: posting.google.com 1295608369 17112 127.0.0.1 (21 Jan 2011 11:12:49 GMT)
    X-Complaints-To: g...@g...com
    NNTP-Posting-Date: Fri, 21 Jan 2011 11:12:49 +0000 (UTC)
    Complaints-To: g...@g...com
    Injection-Info: v12g2000vbx.googlegroups.com; posting-host=195.11.67.225;
    posting-account=jr5y-woAAAAWidgVjrSJ6j8m650CTb-v
    User-Agent: G2/1.0
    X-HTTP-UserAgent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/534.10
    (KHTML, like Gecko) Chrome/8.0.552.237 Safari/534.10,gzip(gfe)
    Xref: news-archive.icm.edu.pl pl.comp.programming:188369
    [ ukryj nagłówki ]

    On Jan 21, 9:48 am, Tomasz Kaczanowski
    <kaczus@dowyciecia_poczta.onet.pl> wrote:
    > Andrzej Jarzabek pisze:
    >
    > > oprogramowaniu przy testowaniu laboratoryjnym są znacznie mniejsze niż
    > > przy podobnym nakładzie środków przy testowaniu przez QA. Bo dział QA
    > > testuje tylko produkty tej firmy, być może jest zespół, który testuje
    > > tylko dany produkt, dodatkowo mają wskazówki od developerów gdzie
    > > należy szukać błędów i mają możliwość testowania produktu we
    > > wszystkich stadiach produkcji.
    >
    > Widzisz, w jednej z firm, w której pracowałem, ktoś powtarzał, że "autor
    > programu jest najgorszym z mozliwych testerów własnego wyrobu". I wiesz
    > co, po latach doswiadczeń przyznaję mu rację.

    W sensie, że lepszym testerem będzie sprzątaczka?

    [...]
    > sprawdzi dokładnie). Niestety w życiu codziennym pojawiają się sytuacje,
    > których autor programu nie przewidzi (np jakies nawyki osób
    > obsługujacych program). Dlatego w firmie w której pracowałem były osoby
    > w dziale testów, które zajmowały się testowaniem produktów w taki
    > sposób, jaki robia to urzytkownicy, poniewaz było to oprogramowanie

    No dobra, co według Ciebie oznacza użyty przeze mnie powyżej skrót
    "QA"?
    Oczywistą sprawą jest, że dział testów wykonuje testy takie, jak
    opisałeś, a nir tylko realizuje instrukcje programisty.

    Ale też instrukcje programisty przyczyniają się do wykrywania wielu
    błędów, które prowadząc takie testy nie zostałyby wykryte, bo masz np.
    sytuację, gdzie został przetestowany build nr 1234, po czym
    programista wprowadza pewne drobne zmiany i do testowania idzie build
    nr 1235. Jeśli programista wie, na czym polega zmiana i co ewentualnie
    może zepsuć, to może napisać notkę wyszczególnuiającą, jakie części
    czy funkcje należy w tym momencie szczególnie intensywnie testować i
    jakiego rodzaju kombinacje mają szczególnie duże szanse ujawnienia
    bugów. To są bardzo cenne wskazówki, których laboratorium testujące
    gotowy produkt nigdy nie otrzyma.

    > > Jeśli chodzi o błędy polegające na tym, że w bardzo specyficznych
    > > sytuacjach, przy specyficznej konfiguracji, przy specyficznych danych
    > > wejściowych pojawiających się w specyficznych relacjach czasowych
    > > program się wysypuje, to testy laboratoryjne mają bardzo słabe szanse
    > > na ich wyłapanie, bo są w stanie przebadać jedynie bardzo wąskie
    > > wycinki całkowitej przestrzeni zdarzeń.
    >
    > Ale takich błędów też nie wyłapią programiści.

    Po pierwsze programiści posiadający odpowiednie umiejętności i wiedzę
    popełnią takich błędów znacznie mniej dzięki stosowaniu odpowiednich
    praktyk.

    Po drugie oczywiście, że doświadczony progrramista może wyłapać lub
    zmniejszyć szansę takich rzeczy w cudzym kodzie przez code review. Nie
    mówimy już tu nawet o zauważeniu, że np. wątki programu używają
    dzielonej zmiennej bez lockowania, ale przede wszystkim o tępieniu
    złych praktyk, takich jak pisanie nieczytelnego kodu. Bo nie chodzi o
    to, czy ten certyfikowany programista będzie w stanie sprawdzić, czy
    spaghetti code ma błędy funkcjoalne, tylko że będzie wiedział, że to
    jest źle napisany kod, w którym w związku z tym istnieje większa
    szansa na błędy, mniejsza szansa na znalezienie błędów i większa
    szansa na wprowadzenie błędów w przyszłości: więc nie certyfikuje
    takiego kodu niezależnie od tego, czy fanktycznie posiada on błędy
    funkcjonalne, czy nie.

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: