TL; DR
I bug non in crash influenzano sempre la funzionalità, nonostante influiscano anche su altri attributi di qualità? Oppure esiste un attributo di qualità più specifico che i bug non in crash influiscono sempre, come l'idoneità funzionale?
Questa potrebbe sembrare una domanda ambigua o poco chiara, ma tieni presente che gli attributi del software di base sono molto ben definiti da standard come ISO / IEC 9126 , che descrive:
- Funzionalità
- Affidabilità
- Usabilità
- Efficienza
- Maintainability
- Portabilità
C'è anche una vera lista di grandi dimensioni su Wikipedia , ma molti di questi approcci la terra sfocata e flessibile della blogosfera. Voglio mantenere questa domanda inequivocabile e legata alle definizioni accettate.
Sto cercando un attributo software che colpisca qualsiasi bug di applicazione non-crash . Ad esempio, ritengo che un bug che causa un arresto anomalo sia un problema di affidabilità, ma non sono sicuro di come classificare generalmente un bug non in blocco.
Correggimi se pensi che io abbia torto, ma ecco perché i bug che si bloccano sono in genere problemi di affidabilità. Se un'applicazione si arresta in modo anomalo (si chiude inaspettatamente, si blocca e non si ripristina, ecc.), potrebbe essere un problema di sicurezza se le risorse protette vengono esposte o distrutte in qualche modo. potrebbe essere anche un problema di sicurezza se l'applicazione è, ad esempio, un pannello di controllo della macchina a raggi X. Ma un crash è sempre un problema di Affidabilità, indipendentemente da dove cadrà.
Ma un bug non-crash? Esempi:
-
alcuni input validi sono considerati non validi
EX: il 29 febbraio 2012 non è correttamente consentito, ma è un giorno bisestile.
-
alcuni input validi sono rappresentati in modo errato
EX: 11:59 AM + 1 minuto viene mostrato come 11:60 AM anziché 12:00 PM.
-
la configurazione o le risorse che dovrebbero essere persistenti non persistono
EX: l'utente deve accedere a ogni visita, nonostante selezioni "Ricordami"
-
l'input viene ignorato in alcuni casi
EX: l'estensione del file viene ignorata se trascinata e rilasciata
Tutti questi fattori incidono sull'usabilità, ma potrebbe non essere sempre così, quindi l'usabilità non è una classificazione completamente generale. Mi sto orientando verso la funzionalità, perché la funzionalità riguarda le esigenze degli utenti e l'adempimento dei requisiti, e io penso un bug non-crash sempre deviato dal comportamento previsto e / o dal comportamento corretto . Ma qualcosa di più specifico della Funzionalità è desiderabile.
ISO / IEC 25010, la revisione 2011 fornisce queste definizioni per l'idoneità funzionale:
4.2.1
functional suitability
degree to which a product or system provides functions that meet stated and implied needs when used under specified conditionsNote 1 to entry: Functional suitability is only concerned with whether the functions meet stated and implied needs, not the functional specification (see C.6).
4.2.1.1
functional completeness
degree to which the set of functions covers all the specified tasks and user objectives4.2.1.2
functional correctness
degree to which a product or system provides the correct results with the needed degree of precision4.2.1.3
functional appropriateness
degree to which the functions facilitate the accomplishment of specified tasks and objectivesEXAMPLE:A user is only presented with the necessary steps to complete a task, excluding any unnecessary steps.
... che sembra adattarsi. Non riesco a capire un bug non-crash che non influisce sulla completezza funzionale o sulla correttezza funzionale o su entrambi.
E infine, per bug , mi riferisco a tutti i tre passaggi nella catena di affidabilità: l'errore nel codice sorgente, gli stati errati del programma causati dall'errore e l'errore dell'interfaccia causato dall'errore.
Whew, è stato un sacco di lavoro per la terminologia!