Esiste un attributo software (come l'affidabilità) che descrive un'esperienza senza bug?

1

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 conditions

Note 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 objectives

  • 4.2.1.2
    functional correctness
    degree to which a product or system provides the correct results with the needed degree of precision

  • 4.2.1.3
    functional appropriateness
    degree to which the functions facilitate the accomplishment of specified tasks and objectives

    EXAMPLE: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!

    
posta kdbanman 04.09.2015 - 19:30
fonte

1 risposta

2

Definirei bachi non in crash anche un problema di "Affidabilità", perché non devi solo poter contare su un programma per stare in piedi; devi fare affidamento su di esso per fare ciò che deve fare.

Immagina un programma che non si è mai schiantato, ma a volte ha pensato che 2 + 2 = 5 quando sono stati colpiti alcuni casi limite. Non considererei affidabile un programma del genere. Vuoi?

    
risposta data 04.09.2015 - 21:42
fonte

Leggi altre domande sui tag