Litigio sui test

[Alkabar]

beh spezzo una lancia a favore di Hador. Bisognerebbe sempre farsi il cartone animato, ovvero simulare l'esecuzione, ma oltre un certo numero di righe di codice rischi di non poterlo fare per cui sostituisci la perfetta conoscenza dei processi dell'applicazione con una serie di test che ne assicurino almeno la correttezza in probabilità, serve ormai molto meno tempo a creare un set di ingressi di test e controllare le uscite che farsi tutto lo schema del codice.

Meglio avere il culo parato insomma, perchè sulla carta i programmi son tutti giusti ma quando vengono eseguiti sbarellano tutti, e questa è la prima direttiva della creazione di software

La correttezza in probabilità ? Cioè intendi dire che statisticamente va almeno per il 95% di quello che l'utente normale vorrebbe andasse. Si questo è corretto.

[Alkabar]

hai centrato il problema
E' una discussione da tech, se hai tempo ti passo materiale te lo leggiucchi e poi mi dici, ma come si dice "hope is not a strategy". Un ingegnere non progetta un ponte sperando che regga perchè lui è bravo, allo stesso modo il software critico (arei ad esempio) è dimostrato matematicamente. La via di mezzo sono le strategie di testing, che non è solo test unitario, che servono a garantire che quel che hai fatto funzioni se non al 100% che è impossibile almeno nella stragrande maggioranza dei casi, e a scoprire facilmente i bug più comuni.
Il programmatore genio che fa tutto lui è roba da 20 anni fa, che ha portato a diversi disastri su diversa scala, tanto per citarne uno ecclatante c'era un modello di respiratore controllato da un software che qualcosa come il 0.00001% dei casi crashava. Risultato? morti. Poi vabbè se uno fa programmazione web su piccola scala ok, altrimenti è tutto un altro cazzo di discorso.

Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.

La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.

[Karidi]

Beh per questo che ci sono più fasi di test
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.

- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi

- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.

TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.

Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.

La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.


Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.

[Hador]

Scusa Hador, non vorrei darti contro, ma stai confondendo il test con l'affidabilità. Sono due cose differenti.
Il test ti fa sapere che la data funzionalità si comporta correttamente, ma non ti dice niente sulla stabilità del software.
La stabilità del software dipende da quanti bug ci sono che non sei riuscito a trovare.

Siccome i bug si distribuiscono in maniera esponenziale (si chiama reliability growth model) tu non puoi sapere niente sull'affidabilità del software che hai scritto,
visto che se volessi fare realmente tutto il test e il debugging necessario per togliere ogni bug, il costo del software ti esploderebbe nelle mani (perchè i bug si distribuiscuno secondo legge esponenziale nel tempo, piu' ne trovi, piu' è difficile trovarne altri).

sei tu che fai casino, i test mica servono a provare il software, servono a garantire l'assenza di bug (a seconda della strategia in maniera matematica o probabilistica). La ricerca infatti sta nel trovare le strategie di test migliori per minimizzare lo sforzo e ottimizzare la probabilità di identificare i bug, l'esempio del coglione è il partition testing, se ho un metodo che processa una numero intero quali sono i test migliori che posso fare? Gli input sono infiniti, scriverò un test però per i casi significativi, -1, 0, 01, 1.1, numero random. Ho coperto tutti gli stati? no. Ho coperto gli stati sensibili? Si.
Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa

Sei un po' troppo spocchioso Hador, Vegeta non ha detto niente di scorretto. I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.

La cosa piu' importante è il processo di debugging, che puo' essere aiutato coi test.

non è questione di esser spocchiosi, è questione che sbagli

[Amiag]

non far casino, i processi agili sono fondati sui test, cioè tipo il primo punto del manifesto agile è tests first, "utilizza i test come specifica". E anche in italia in medie piccole realtà è ormai comune trovare lo sviluppo organizzato con xp, scrum o derivati.

Beh non direi che sono il primo punto, ma di certo sono importanti. Pero' sono test usati in fase di sviluppo ed eseguiti dagli stessi sviluppatori, tante' vero che una delle critiche mosse a questi processi e' cosi' si rischia di ridurre l'importanza dei test di integrazione e quality assurance.

[Karidi]

Uno dei problemi maggiori non è la funzionalità ma trovare dev. capaci di fare software tunati a dovere.

[Alkabar]

sei tu che fai casino, i test mica servono a provare il software, servono a garantire l'assenza di bug (a seconda della strategia in maniera matematica o probabilistica). La ricerca infatti sta nel trovare le strategie di test migliori per minimizzare lo sforzo e ottimizzare la probabilità di identificare i bug, l'esempio del coglione è il partition testing, se ho un metodo che processa una numero intero quali sono i test migliori che posso fare? Gli input sono infiniti, scriverò un test però per i casi significativi, -1, 0, 01, 1.1, numero random. Ho coperto tutti gli stati? no. Ho coperto gli stati sensibili? Si.

Ti stai impelagando male:
Il test di per se ti dice solo che lo stato del sistema è corretto o no dati certi input, non ti garantisce l'assenza di bug anche dentro ai componenti stessi che ti hanno computato il risultato corretto. Se vai avanti a dir di ste cose mi fai pensare male.

Posso infatti utilizzare diversi criteri per valutare la mia test suite, dai diversi criteri di copertura (codice, controllo, data flow) a metodi attivi quali il fault injiection.
vammi pure contro, ci sto a fare la tesi su questa cosa non è questione di esser spocchiosi, è questione che sbagli

O magari sei tu che hai studiato male il corso di ingegneria del software. Tutto sommato molto probabile considerando che arrivi a confondere imperativo con procedurale.

[Alkabar]

Beh per questo che ci sono più fasi di test
- Sviluppo, ma molte volte non si usano gli ambienti predisposti ma si usano i propri portatili o Mac per fare figo poi quando rilasciano sui sistemi di Release Management ti trovi di tutto e fioccano le madonne.

- IAT/UAT ambienti di integrazione accettazione che nella maggior parte delle volte sono mononodi

- PreProduzione, enviroment scalati dalla produzione ma con architetture di Cluster e Multistanze integrate tra loro nei vari mondi (Web/PRV etc.etc.) i DB sono le copie fisiche o restore effettuati tramite Storage.
(in questo ambiente vengono fatti gli stresstest e le prove di deploy in cluster mode, che sono i maggiori bagni di sangue/caporetto che hanno i software rilasciati.

TEST: Dipende dalla bravura dei gruppi di QA dalle specifiche che seguono la CR o il progetto e qui vengono redatti i TESTCase che sono gli scenari, che vengono studiati sui documenti che arrivano dall'analisti, dalla fattibilità dagli Architetti e i PM etc.etc.

Per questo che ci sono strumenti molto diffusi come la suite Mercury etc.etc.

La maggior parte dei problemi che si hanno nelle architetture enterprise è che chi si fregia di titolo di Architetto non sa una ceppa di nulla di Sistemi/Network e architetture, quindi fa il suo Software superfunzionante sul suo MAC, poi quando vai a fare integrazione/deploy scopri che non va una bega per poi sdraiarlo in pochi secondi quando lo bombardi con LoadRunner.

Che non clasha per niente col fatto che i test sono un aiuto al debugging, non sono il debugging. Altrimenti perchè mai faresti dei test...

Alka: 10 anni fa si chiedeva che un Software Funzionasse ora si chiede che un Software sia PErformante ed Efficace c'è una differenza abissale tra i due concetti.

Perchè poppi e assumi cose che non ho detto?

Certo non l'ho detto e rileggendo: non l'ho detto. E rileggendolo di nuovo: non l'ho detto quello che scrivi.
Ho detto che il test ti dice solo se un componente funziona o no, dove per funziona o no intendo che finisce nello stato corretto dato un certo input.

[Karidi]

I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.

[Alkabar]

I test ovviamente servono, ma ti dicono solo che qualcosa funziona o non funziona, spesso non ti dice molto sull'interazione nel tempo dei vari componenti.

E quindi stai capendo cazzi per mazzi.

[Eltarion]

ma che cazzo di seghe mentali vi state facendo? Ha chiesto se c'era qualche linguaggio veloce da imparare da usare non in ambito profesisonale. Non ci sono altre risposte se non C# o VB.NET. L'ottimizzazione della gestione della memoria, il multithreading in ambito distribuito e la gestione delle concorrenze non credo siano una sua priorità. State solamente facendo una gara a chi ce l'ha più lungo e duro. LOL

[Alkabar]

Aggiungo, tanto per concludere, citando dal sommerville:

il software ha caratteristiche funzionali e non funzionali.

Le caratteristiche funzionali, riguardano la funzione del software. Quello che fa.

Le caratteristiche non funzionali, riguardano:

-performance
-Speed
-Resource Usage
-altro

E sono caratteristiche emergenti del software. Cioè sono cose che si possono valutare solo a posteriori, dopo che il software è in piedi e gira, perchè hanno senso solo alla fine del processo.

I test, si fanno per la parte funzionale. Perchè non esiste un test, nel mentre che si programma, per vedere se il software è perfomante è semplicemente stupido.

Senza rancore eh, ma seriamente ora vi state impelagando davvero davvero male.

[Alkabar]

ma che cazzo di seghe mentali vi state facendo? Ha chiesto se c'era qualche linguaggio veloce da imparare da usare non in ambito profesisonale. Non ci sono altre risposte se non C# o VB.NET. L'ottimizzazione della gestione della memoria, il multithreading in ambito distribuito e la gestione delle concorrenze non credo siano una sua priorità. State solamente facendo una gara a chi ce l'ha più lungo e duro. LOL

Beh, in tutta onestà non mi sono piaciute le uscite di Hador a gamba tesa su Vegeta sulla questione dei test e ho risposto, del 3D mi interessava davvero poco. Magari foste un po' piu' civili in generale invece che fare i galletti del quartiere, dico forse, la gente non risponderebbe.

[Hador]

quel che a me pare probabile è che tu non abbia idea di che cosa si stia parlando invece
devo andare a pappa, ma tu non insegnavi sta roba? Se tu potessi provare tutti i valori di input avresti la garanzia dell'assenza di bug, in quanto hai verificato tutte le transizioni possibili a partire da quello stato. Dato che non puoi utilizzi delle strategie, o ottimistiche (es partition testing), o pessimistiche (es analisi statica), o di astrazione (model checking). Il debug non centra una sega, il software critico secondo te è controllato a mano facendo debug? Ma che stai dicendo alka.
E giga lol sul fatto che il testing si fa solo su caratteristiche funzionali, la validazione che fa scusa? Va bene fare il tuttologo ma fino ad un certo punto.

Non esiste un modo per testare le performance o usabilità mentre fai le cose? ma tutta la sega sui processi iterativi a che minchia serve allora, per sport? Mha...

[Karidi]

E quindi stai capendo cazzi per mazzi.

No, sto parlando delle fasi che vengono dopo i rilasci del software e nelle sue fasi , e delle problematiche.
Grazie, che non puoi provare il carico (che fa parte del mondo dei TEST, visto che si chiamano STRESSTEST) perchè non hai l'architettura per poterlo fare, non hai un architettura scalata della produzione con apparati di rete e integrata etc.etc.
Non sto rispondendo a te, sto rispondendo in generale su una discussione che è ormai andata OT, parlando da NON programmatore, ma da chi deve subirsi gli ABORTI che tanti pseudo Architetti/ingegneri del software producono.

L'ultima frase era una conclusione quando ti dicevo la differenza con 10anni fà, ma come al solito la prendi sul personale.