Jacek Zieliński

Jacek Zieliński Project Manager/
Consulting Manager

Temat: Jak to jest z tą jakością

Czy programista powinien robić dobrze, czy dać zajęcie testerowi?

konto usunięte

Temat: Jak to jest z tą jakością

widze, ze kolega Jacek prowokuje do dyskusji nie tylko w pracy ;-)
mysle, ze kazdy programista czujac na karku oddech zespolu testowego chce i bedzie wykonywac swoja prace 'dobrze'; przeto bardziej wolimy gdy sie nas chwali za dobrze wykonana prace niz gani za jej 'odwalanie' i wytyka palcem popelnione bledy (pomijam przypadki masochizmu)
Jacek Zieliński

Jacek Zieliński Project Manager/
Consulting Manager

Temat: Jak to jest z tą jakością

tak naprawdę to chciałem być pierwszy :)

znam niektórych ziomali co mają gdzieś jakość od początku......
Joanna Ś.

Joanna Ś.
szlakiem-karawany-z-
perspektywy-tuktuka-
relacja-z-pograni...

Temat: Jak to jest z tą jakością

Jacek Z.:Czy programista powinien robić dobrze, czy dać zajęcie testerowi?


Powinien robić dobrze I dać dajęcie testerowi :P

konto usunięte

Temat: Jak to jest z tą jakością

A to nie jest tak przypadkiem, ze tester ma sprawdzic czy programista zrobil dobrze, a obaj powinni starac sie wykonac swoja prace najlepiej jak potrafia? ;)

btw. nie wazne jak bardzo programista bedzie sie staral, zawsze przemyci jakiegos bug'a.
Jacek Zieliński

Jacek Zieliński Project Manager/
Consulting Manager

Temat: Jak to jest z tą jakością

dokładnie. to programiście powinno zależeć, żeby oddać jak najlepsze coś :)

no ale nie ma programów bez błędów - są tylko źle sprawdzone.
Justyna Uminska

Justyna Uminska Senior Consultant,
GamCom Solutions Ltd

Temat: Jak to jest z tą jakością

Programista powinien robic jak najlepiej, po to aby umozliwic testerowi robic jego prace jak najlepiej.

Caly problem polega na tym ze do testerow trafia kod z bugami, ktore programista powinien wylapac na etapie unit testow. Tester traci czas na dokumentowanie podstawowych wad funkcjonalnosci programu, wraca toto do programisty, ten poprawia poprawia, kolejny release, kolejne prymitywne bugi. W wiekszosci projektow mamy fixed term, jakis deadline, wiec zwyczajnie czas dla testerow jest ograniczony. I to powoduje powazne braki w jakosci wiekszosci obecnych systemow. Tester nie ma czasu na niuanse, na detale ktore to wlasnie swiadcza o jakosci. Zamiast lapac bledy integracji systemu, bledy zwiazane z real environment i real data, bugi zwiazane z wydajnoscia systemu i wszelkimi innymi wplywami na aplikacje ktorych developer nie moze przewidziec i przetestowac - ten zwyczajnie sprawdza podstawowe spelnienie wymagan. A to nie jest jakosc. Jakosc nie oznacza ze noz ktory ma kroic - kroi. Jakosc oznacza jego profil, odpowienie wykonczenie uchwytu przyjemne dla uzytkownika, odpowiedni stop stali uzyty do produkcji ostrza, itd itd.
Dlatego dopiero kiedy programista i tester robia jak najlepiej - mozemy w ogole myslec o tym, ze nasz system bedzie mial JAKOSC.

konto usunięte

Temat: Jak to jest z tą jakością

Oj tak, bardzo trafne uwagi kolezanka poczynila
Zdarza/lo mi sie testowac funkcjonalnosci zgodne w max. 1/3 ze specyfikacja, ktora zreszta byla/jest bardzo porzadnie napisana. Tester nie powinien byc zaprzegany do testowania zupelnie podstawowych wymagan. Jego zadaniem wg mnie jest m.in. korzystanie z heurystyk podczas testowania, tj. stawianie otwartych pytan odnosnie testowanego produktu oraz tworzenie rowniez takich testow, ktorych kryteria pomyslnosci nie sa definiowane jedynie jako 'pass/fail'

konto usunięte

Temat: Jak to jest z tą jakością

Z punktu widzenia system testów:

Programista ma prawo zrobić błąd bo nie ma do czynienia z całym systemem a jedynie z jego fragmentem (błąd może także wynikać z wymagań albo z design’u, dlatego proces testowy powinien towarzyszyć projektowi od samego początku). Tester patrzy oczami klienta końcowego i nie powinien przepuścić żadnej usterki gdyż odpowiada za jakość. Tyle na ten temat mówi teoria ;-)

konto usunięte

Temat: Jak to jest z tą jakością

Tester tez ma prawo zrobic blad, nie odbierajmy mu tego ;)
Justyna Uminska

Justyna Uminska Senior Consultant,
GamCom Solutions Ltd

Temat: Jak to jest z tą jakością

Programista odpowiada za jakosc w takim samym stopniu jak i tester. Ich odpowiedzialnosc ma jedynie inny zasieg. Dobrym odzwierciedleniem jest V model produkcji i testowania oprogramowania, gdzie leb w leb od poczatku istnienia systemu tworzymy go i testujemy. Dbamy o jakosc na kazdym poziomie SDLC.

PS Pozdrawiam kolege Marcina z ktorym jak sie nie myle mialam przyjemnosc pracowac w jednej firmie ;-)

konto usunięte

Temat: Jak to jest z tą jakością

Justyna U.:
PS Pozdrawiam kolege Marcina z ktorym jak sie nie myle mialam przyjemnosc pracowac w jednej firmie ;-)

Zgadza się, mieliśmy przyjemność pracować razem w RTS Networks. Również pozdrawiam, teraz już z korporacji ;-)
Alek K.

Alek K. CEO @ offiserv.com -
Smooth your business
operations!

Temat: Jak to jest z tą jakością

Hmm.... jakość nie powstanie sama - nawet jeśli zarówno programiści jak i inżynierowie testów bardzo się starają.

Wiele zależy również od tego, jak zorganizowany jest proces wokół ich trudnej pracy: czy zostały zebrane właściwe wymagania, czy mają realistyczny plan, czy mają zaalokowany czas na dodatkowe działania zapewniania jakości (np code review, unit testy), czy jest odpowiednie zarządzanie konfiguracją i czy ktoś na bieżąco tę jakość obiektywnie monitoruje, wprowadzając w razie potrzeby akcje naprawcze.
Bartosz Ślepowronski

Bartosz Ślepowronski Problem? Jaki
problem?

Temat: Jak to jest z tą jakością

Wydaje mi się, że pytanie jest źle postawione - bo sugeruje, że jeśli programista zrobi dobrze to tester nie będzie miał nic do roboty. Prawda jest taka, że programiści robią dobrze według swojej najlepszej wiedzy ale

1/ Wymagania nie zawsze są precyzyjne (ba, czasami zwyczajnie nie mogą być precyzyjne)
2/ Nie ma takiej możliwości, żeby napiać kod bez bugów. Nie w komercyjnych warunkach (ograniczony czas, budżet, zasoby)

Pracuję jako analityk biznesowy, programista i tester - zależnie od projektu - i korzystając z tej szerokiej perspektywy mogę powiedziedzieć, że bez QA zwyczajnie się nie da, niezależnie od tego jak dobrze robić będzie analityk (wymagania) i programista :>Just User edytował(a) ten post dnia 15.09.07 o godzinie 12:17
Ireneusz Jaworski

Ireneusz Jaworski Pełnomocnik Zarządu
ds. Systemu Jakości,
UPOS System sp. ...

Temat: Jak to jest z tą jakością

Jacek Z.:
Czy programista powinien robić dobrze, czy dać zajęcie testerowi?
Jak sie coś robi to zawsze powinno sie to robić jak najlepiej potrafi.
Ireneusz Jaworski

Ireneusz Jaworski Pełnomocnik Zarządu
ds. Systemu Jakości,
UPOS System sp. ...

Temat: Jak to jest z tą jakością

Just U.:
Wydaje mi się, że pytanie jest źle postawione - bo sugeruje, że jeśli programista zrobi dobrze to tester nie będzie miał nic do roboty. Prawda jest taka, że programiści robią dobrze według swojej najlepszej wiedzy ale

1/ Wymagania nie zawsze są precyzyjne (ba, czasami zwyczajnie nie mogą być precyzyjne)
2/ Nie ma takiej możliwości, żeby napiać kod bez bugów. Nie w komercyjnych warunkach (ograniczony czas, budżet, zasoby)

Pracuję jako analityk biznesowy, programista i tester - zależnie od projektu - i korzystając z tej szerokiej perspektywy mogę powiedziedzieć, że bez QA zwyczajnie się nie da, niezależnie od tego jak dobrze robić będzie analityk (wymagania) i programista :>Just User edytował(a) ten post dnia 15.09.07 o godzinie 12:17

Kontrola jakości przydaje się wszędzie, no niestety nie sposób uniknąć błędów, ważne aby walczyć z błędami a nie przeciwko sobie jak to sie czaszami dzieje.

Temat: Jak to jest z tą jakością

Recami i nogami podpisuje sie pod tym co napisalas.
I jeszcze jeden kwiatek mi przyszedl do glosy. Odpowiedz programisty na zgloszony. nie koniecznie blad ale nazwijmy to rozbieznosc dzialania systemu w "" zeby system dzialal ladnie - skoro tak to dziala od dawna (czyt. nikt na to nie zwrocil uwage lub analiza pominela taka pier..ke) to tak ma byc :)

Justyna U.:
Programista powinien robic jak najlepiej, po to aby umozliwic testerowi robic jego prace jak najlepiej.

Caly problem polega na tym ze do testerow trafia kod z bugami, ktore programista powinien wylapac na etapie unit testow. Tester traci czas na dokumentowanie podstawowych wad funkcjonalnosci programu, wraca toto do programisty, ten poprawia poprawia, kolejny release, kolejne prymitywne bugi. W wiekszosci projektow mamy fixed term, jakis deadline, wiec zwyczajnie czas dla testerow jest ograniczony. I to powoduje powazne braki w jakosci


wiekszosci
obecnych systemow. Tester nie ma czasu na niuanse, na detale ktore to wlasnie swiadcza o jakosci. Zamiast lapac bledy integracji systemu, bledy zwiazane z real environment i real data, bugi zwiazane z wydajnoscia systemu i wszelkimi innymi wplywami na aplikacje ktorych developer nie moze przewidziec i przetestowac - ten zwyczajnie sprawdza podstawowe spelnienie wymagan. A to nie jest jakosc. Jakosc nie oznacza ze noz ktory ma kroic - kroi. Jakosc oznacza jego profil, odpowienie wykonczenie uchwytu przyjemne dla uzytkownika, odpowiedni stop stali uzyty do produkcji ostrza, itd itd.
Dlatego dopiero kiedy programista i tester robia jak najlepiej - mozemy w ogole myslec o tym, ze nasz system bedzie mial JAKOSC.



Wyślij zaproszenie do