INF3121: Lesson 3

Static Techniques

Reviews, static analysis and dynamic testing have the same objective – identifying defects. They are complementary. Compared to dynamic testing, static techniques find causes of failures (defects) rather than the failures themselves.

1. Static techniques and the test process

Dymanic testing: requires the execution of software (gjennomføring av programvare)

Static testing: manual examination and automated analysis of the code or documentation.

Reviews: A way of testing software products (including code) and can be performed well before dynamic test execution.

Reasons to make reviews: Defects detected during reviews early in the life cycle are often cheaper to remove than those detected while running tests.

Tools: The main manual activity is to examine a work product and make comments about it.


Objects of reviews: Any software product can be reviewed:
- requirement specifications
- design spesicifations
- code
- test plans, test spesification, test cases, test scripts
- user guides
- web pages

Benefits:
- Early defect detection and correction
- development productivity improvements
- reduced development timescales
- reduced testing cost and times
- lifetime cost reduction
- fewer defects and improved communication

Typical defects: (easier to find in reviews than in dynamic testing)

- deviations from standard (avvik fra standar)

- requirement defects

- design defects

– insufficient maintainability (utilstrekkelig vedlike)

- incorrect interface specifications (feilaktige grensesnitsspesifikasjoner)

2. Review process

INF3121: Lesson two

Testing throughout the software life cycle

1. Software development models

Sequential development model (The V-model)

- Testing needs to begin as early as possible in the life cycle. 

- Testing can be integrated into each phase of the product life cycle. 

- The V model (sequential development model), testing especially takes place in the early stages, and late in the life cycle.

The interactive-incremental development is the prosess of: 

- establishing requirements
- designing
- building
- testing a system
(Done as a series of shorter development cycles)

- An increment, added to others developed previously, forms a growing partial system, which should also be tested.

- Regression testing is increasingly important on all iterations after the first one.

Testing within a lifecycle model:

- In any life cycle model, there are several characteristics of good testing:

- Test levels can be combined or reorganized depending on the nature of the project or the system architecture.

2. TEST LEVELS

Component testing

Component testing includes testing of functionality and specific non-functional characteristics, such as: resource behavior, robustness testing and structural testing.

Integration testing

It tests:

- interfaces between components

- interaction with different parts of a system, such as: the operating system, file system, hardware, interfaces between components.

System tests

Testing the behavior of the whole system as defined by the scope of the project.

Acceptance testing

To establish confidence in the system/part of system/non-functional characteristics of the system.

3. TEST TYPES

Learning goals: Compare the following test type: fictional, non-functional, structural and change related.

Fuctional testing (black box testing)

What the system does:

Suitability
Interoperability
Security
Accuracy
 Compliance

Non-functional testing

How the system works

Performance, load, stress

Reliability

Usuability

Efficiency

Maintainability

Portability

Related to change

Confirmation testing

Regression testing

Structural

Code coverage

4. MAINTANCE TESTING

Maintance testing is done on an existing operational system, and is triggered by modifications, migration, or retirement of the software or system.

INF3121: First lesson

Fundamental concepts in testing

1. WHY IS TESTING NECESSARY?

Software systems are an important part of life. Most people had experienced with software not working as expected, and if the system doesn't work correctly, it can lead to problems like less of money, loss of business reputation, injury or death.

Causes of software defects

Internal: fatigue, lack of training, lack of understanding, lack of interest
external: time pressure, complex code, many system interactions, changed technologies.

There are also non-controlleble events that can happen: radiation, magnetism, pollution etc. it's not necessary human failure.

Causes of software defects:

Both codes of errors produce defects (faults, bugs) in the code.

- Defects, it executed, may result in failures of the SW, the system will fail to to what it should.

- Failures can affect seriously the users of the SW system: break pedal not working in some cars, miscalculations in financial sw systems.

Role of testing

Testing has an important role inn all the stages of SW products life cyckle:
- development
- maintenance
- operations

Testing and quality

How much testing is enough?

testing should provide sufficeient information for the stakeholders to take informed decisions about: release of the software, next development steps etc.

2. WHAT IS TESTING?

Defenistion: The prosess consisting:

- all of life cycle activities, both static and dynamic, concerned with planning, preparation and evaluation of software products and related work products to determine that they satisfy specified requirements, to demonstrate that they are fit for purpose and to find defects.

Depending on the objectives of the test process, testing can be focused on:

3. TEST PRINCIPLES

There are seven principles we should learn, these testing principles offer some guidelines common for all testing:

4. FUNDAMENTAL TEST PROCESSES

There are five fundamental test activities:

1. Plan and control:

2. Analysis and design

3. Implementation and execution

4. Evaluate exit criteria and report

5. Test closure activities

5. THE PSHYCOLOGY OF TESTIN

Independence test levels:

- A certain degree of independence is often more effective at finding defects and failure. However, the developer can very efficiently find bugs in their own code.

- Applying a certain level of indolence of the testing depends on the objectives of testing.

Independence levels:

Tips and tricks:

Looking for failure requires:

- curiosity

- professional pessimism

- attention to details

- good communication skills

- excperience on error guessing

Estimering

I IT-bransjen i dag er det ca 30% underestimering av kostnader. Dette kan føre til misfornøyde kunder, gjennomføringsproblemer og tap for leverandør.

Hvorfor har vi disse problemene?
Iboende problemer

-       Komplekse produkter (mye nytt = lite erfaringer = kompleksiteten øker raskere enn størrelsen på prosjektet)

-       Komplekse organisasjonsendringer ofte en del av leveransen

-       Komplekse prosjekter

-       Uklare krav (skal prosjektet vente til alle krav er ferdige vil de aldri bli ferdige)

-       Menneskelige svakheter

Oppdragsgiverproblemer

-       Uklare krav

-       Lite kunnskap om IT

-       Kommunikasjonsproblemer med leverandør

-       Setter av lite tid til til oppfølgning av prosjekt

-       Andbud = fører til overoptimistiske leverandører

Winners course (ROSING formelen)

Kunde fokuserer for mye på pris så det blir høyere overskridelse

Prosjektledelse, prosjektplanlegging, teamarbeid

Risikohåndtering

En risiko er en sannsynlighet for at uønskede omstendigheter skjer. Deles opp i ulike kategorier:

Prosjekt-risiko: vil ha effekt på tidsplaner/budsjett

Produkt-risiko: vil ha effekt på kvaliteten eller av programvaren som utvkles.

Forrestings-risiko: vil ha effekt på organisasjonen som utvikler/eier programvaren.

Ledelse av mennesker

Mennesket er organisasjonens støreste ressurs. En leders oppgave er orientert til mennesker. Dårlig ledelse er stort sett hovedgrunnen til at et prosjekt feiler.

En gruppe

Motivasjon er viktig for et prosjekt. Det finnes ulike former for motivasjon som er basert på basise behov som søvn og mat, sosiale behov og personlige behov.

I en gruppe mennesker er det alltid en rekke ulike personlighetstyper.  Den oppgaveorienterte, den selvorienterte og den samspillorienterte. Mennesker i en gruppe utgjør et team. Et team er en gruppe mennesker med felles mål og ulike komplimentere ferdigheter. Systemutvikling er et nytt felt og dette kan gjøre Software-team ekstra utfordrende. Det er hyppige og ofte endringer som kan gjøre planleggingen vanskelig, det er komplekse sosiale og tekniske systemer og det er få etablerte teorier om systemutvikling fra før av.

Et godt teammedlem kjennetegner ved at teamets mål er viktigere enn sine egne personlige mål. Kommunikasjon er en nøkkelfaktor. Det er viktig å ha et effektivt team. Man må ha variasjon av teammedlemmer fordi systemet består av en rekke ulike aktiviteter. Teamet bør være godt organisert.

Plandreven utvikling

 I plandreven utvikling planlegges utviklingsprosessen i detalj. Hovedargumentet for plandreven tilnærming har vært at det å planlegge tidlig i prosessen har en rekke fordeler.  Tilgenglige ressurser blir tatt hensyn til, og at potensielle problemer blir avdekket tidlig. Hovedargumentet mot plandreven utvikling har vært at mange tidlige avgjørelser likevel må endres på grunn av endringer i omgivelsene uti prosjektet.

Smidig planlegging

 Smidige metoder er en iterativ tilnærming der programvaren blir utviklet og levert til kundene som tillegg. Funksjonaliteten til tilleggene (increment) er ikke planlagt på forhånd men avgjøres under utviklingen. Dette er hovedforskjellen mellom smidig og plandreven utvikling. I smidig tilnærming fokuseres det på at kundens krav og prioriteringer kan endre seg.

Historiebasert planlegging

XP og SCRUm baserer seg mye på brukerhistorier (user stories) som reflekterer egenskapene i systemet. (”som student ønsker jeg å melde meg opp i kurs”). Teamet diskuterer  historier og rangerer dem i forhold til tiden de tror det tar.

Testing av programvare

Hva er testing? Hva er hensikten?

For en gitt input forventer vi en viss output. Hensikten med å teste er å vise at systemet gjør det systemet er ment å gjøre og å oppdage feil før systemet blir tatt i bruk. Testing beviser ikke at systemet er feilfritt men viser feil du oppdager under kjøring av testen.

Validering og vertifisering:

Validering: Bygger vi det riktige produktet?

-       Programvaren bør gjøre det brukeren virkelig ønsker

-       Fokus på hele systemet

-       Gjøres som regel i ekte og virkelige omgivelser

Vertifisering: Bygger vi produktet riktig?

-       Stemmer det med kravspesifikasjonen?

-       Fokus på komponent/delsystem

-       Gjøres som regel i laberatorum

Ulike former av utviklingstesting

Testing foregår under utviklingsfasen. Her er det en rekke ulike måter å teste på:

1.     Enhetstesting: Individuelle programenheter eller objektklasser testes. Fokus på å teste funksjonaliteten til objekter og metoder.

2.     Integrasjonstesting: Ulike individuelle enheter er integrert til sammensatte komponenter. Fokus på å teste grensesnitt til komponenter.

3.     Systemtesting: Noen eller alle komponenter i et system er integrert og systemet testes som en helhet. Fokus på å teste interaksjonen mellom komponentene.

4.      Akseptansetesting: brukere eller potensielle brukere tester systemet i egne omgivelser

Typer av test

Black Box testing

Black box testing er en metode eller strategi som tester funksjonaliteten  til et system i motsetning til interne strukturen eller kildekoden. Tester er bygd rundt spesifikasjoner og krav, det vil si, hva programmet er ment å gjøre. Black-box testing kan brukes på alle nivåer av programvaretesting. Det er en rekke fordeler ved black box testing. Det krever ikke programmeringskunnskaper, man kan bruke uavhenige testere som ikke har vært involvert i utviklingen, man unngår at testingen gjør samme antagelser som utviklerne og testing gjøres fra et brukerpersepektiv og kan avsløre mangler i kravspesifikasjonen.

Whitebox testing

White box testing tester interne strukturer eller kode i et program, i motsetning til black box testing som tester funksjonalitet. Programmeringskunnskaper kreves. Brukes vanligvis under enhetstesting, men også systemtesting og integrasjonstesting. Fordeler: kan gjøres tidlig i systemet, testingen er grundig, optimaliserer koden, fjerner unødvendig kode. Ulemper: krever prog.kunnskaper, kan kun utføres av involerte utviklere,

Testdrevet utvikling (TDD:

1.     En tilnærming der testing og koding gjøres pararellt.

2.     Kode utvikles i steg (inkrementelt) sammen med en test for hvert inkrement. Går ikke vidre til neste inkrement før koden ”passerer” testen.

3.     TDD var i utgangspunkt en del av smidige Xp men brukes også i plandreven utvikling.