Lean Summer of 2015 – Week 5

27. July 2015 — 1 Comment

Can 6 tech students help a telecom giant innovate in 6 weeks? Telenor Norway wants to solve real problems for real people. As summer interns in Iterate – the lean startup consultancy in Norway – we’ve been hired to build, measure and learn how to unleash the power of future telco technology. Every week we blog about what we’ve learned.

Here’s week 5.

Navigating the corporate jungle.

Compared to the real world, student life is easy. We are free to do almost whatever we want, when we want to. You never really have guilt-free time off, but you also don’t have to get up early every day.

For many of us, summer internships are the first taste of a real job. We would soon discover that getting up early would be the easy part.

How many interns does it take to fire up a grill? One to light it and four to watch it in silence and scare away the seagulls

Lean Summer of 2015 – Week 3

13. July 2015 — 4 Comments

Here’s week 3.

We knew from the beginning this internship was going to be different.

Most tech student summer internships follow a standard format: You show up the first day to a round of introductions, you get assigned a workstation, a task, and maybe some company swag. The first week is focused on workshops and courses, and then you are set to work. For the next few weeks you work on your project in order to bring it to completion on time.

Certainly a cool internship when you get to brew your own beer and design a matching label.

Lean Summer of 2015

29. June 2015 — 4 Comments

Here’s week 1.

Continuous Delivery Digest: Ch.9 Testing Non-Functional Requirements

8. January 2015 — Leave a comment

Digest of chapter 9 of the Continuous Delivery bible by Humble and Farley. See also the digest of ch 8: Automated Acceptance Testing.

(“cross-functional” might be better as they too are crucial for functionality)

f.ex. security, usability, maintainability, auditability, configurability but especially capacity, throughput, performance
performance = time to process 1 transaction (tx); throughput = #tx/a period; capacity = max throughput we can handle under a given load while maintaining acceptable response times.
NFRs determine the architecture so we must define them early; all (ops, devs, testers, customer) should meet to estimate their impact (it costs to increase any of them and often they go contrary to each other, e.g. security and performance)
das appropriate, you can either create specific stories for NFRs (e.g. capacity; => easier to prioritize explicitely) or/and add them as requirements to feature stories
if poorly analyzed then they constrain thinking, lead to overdesign and inappropriate optimization
only ever optimize based on facts, i.e. realistic measurements (if you don’t know it: developers are really terrible at guessing the source of performance problems)

A strategy to address capacity problems:

Notes On Automated Acceptance Testing (from the Continuous Delivery book)

8. January 2015 — 2 Comments

These are my rather extensive notes from reading the chapter 8 on Automated Acceptance Testing in the Continuous Delivery bible by Humble and Farley. There is plenty of very good advice that I just had to take record of. Acceptance testing is an exciting and important subject. Why should you care about it? Because:

We know from experience that without excellent automated acceptance test coverage, one of three things happens: Either a lot of time is spent trying to find and fix bugs at the end of the process when you thought you were done, or you spend a great deal of time and money on manual acceptance and regression testing, or you end up releasing poor-quality software.

JavaScript tests on your Continous Integration server

19. December 2012 — 8 Comments

A modern web page does a lot of things, hence the term web application has become more commonly used over the last year. A consequence of this is that we are crafting widgets and entire modules using JavaScript, or at least in some language that eventually ends up being “compiled” to JavaScript.

Where there is code there should also be tests. And the tests need to go green every time the code is changed. You are testing your client side code, right?

Continue reading

Do You Know Why You Are Testing?! (On The Principles Underlying TDD)

30. October 2012 — 1 Comment

Kent Beck in his recent post Functional TDD: A Clash of Cultures summarizes well the key principles and benefits that underlie test-driven development. I think it is really worthwhile becoming aware of and thinking over these foundation stones of TDD (and testing in general). Knowing them enables you to apply TDD in the most effective way with respect to a particular context to gain the maximum of these benefits. People that do not really understand the value of their tests and TDD tend to write hard to maintain tests of limited (and occasionally even negative) value. Are you one of them?

Programming Like Kent Beck

20. June 2012 — 11 Comments

Three of us, namely Stig, Krzysztof, and Jakub, have had the pleasure of spending a week with Kent Beck during Iterate Code Camp 2012, working together on a project and learning programming best practices. We would like to share the valuable lessons that we have learnt and that made us better programmers (or so we would like to think at least).

Er nye bygninger trygge?

21. March 2012 — Leave a comment

Vi er vant til at programvare har feil. Bare husk de grufulle minnene fra Windows sin blåskjerm “blue screen of death”, som selv for Bill Gates kom på det mest ubeleilige tidspunkt (da Windows 95 krasjet under en demonstrasjon for pressen). Som brukere har vi forsonet oss med at programvare ikke er perfekt.

Enkelte av oss har nylig erfart ubehageligheter med selvangivelsen. Problemer mer alvorlige enn de vanlige ytelsesproblemene som kommer når halve kongeriket sjekker restskatten samtidig: Enkelte har til sin store overraskelse fått anledning til å se en annen person sin selvangivelse. Det er kanskje å ta offentlige skattelister en smule langt?

Vi stoler ikke på nye IT-systemer. Vi har lært oss å ikke oppgradere noe som helst rett før vi tar med oss laptoppen på hytta, eller før vi går i et viktig møte. Jo eldre programvare, desto tryggere føler vi oss, fordi tiden har luket ut de styggeste feilene.

Det er anderledes med bygninger. Selv føler jeg meg mindre trygg desto eldre bygning. En kompis bodde en gang i en loftsleilighet fra 1800-tallet, og etasjeskillerne besto av knusktørr halm. Én flamme på feil sted i første etasje, og hele bygningen hadde blitt en stor skorstein. Nye bygninger derimot, de står støtt. Bygget etter moderne metoder, og gjennomgått grundig ettersyn. Iallefall de fleste av dem.

Hva skiller disiplinene bygg og programvare? I byggeindustrien må man sikre kvalitet i hvert ledd. Du kan ikke bygge andre etasje før du vet at første etasje holder. Det er man (dessverre) ikke nødt til i programvareindustrien. Istedenfor å bygge integritet inn i løsningen, tester vi kvaliteten etterpå. Da finner vi selvfølgelig masse feil, som vi ikke har tid til å rette opp. Det er et paradoks: Vi tester for å finne feilene vi har laget, når det åpenbare alternativet er å unngå feilene i utgangspunktet.

Empire State Building ble bygget på ett år, men kanskje ikke utelukkende i små sikre steg ..

Hvorfor er det slik?

Få betalt for feil du ikke finner!

1. March 2012 — 5 Comments

På dagens frokostmøte ble det ytret frustrasjon rundt testere i ett prosjekt som så det som sin oppgave å finne flest mulige feil i applikasjonen. Og det er greit nok det, om man har rigget prosjektet sitt på en måte som gjør at det er mulig å implementere feil i utgangspunktet. Kollegaen min refererte hele tiden til “oss” og “dem” når vi snakket om situasjonen. Noe som forsterket muren som stod mellom utviklere og testere i dette prosjektet.

Dette er fra et prosjekt med den klassiske designe-alt-utvikle-alt-teste-alt-produksjonsette-alt-tankegangen (også kjent som vannfall). Ett av problemene er jo selvsagt strategien som er valgt, men hovedproblemet til min stakkars kollega er at utvikling kommer før test i et slikt sekvensielt løp. Det må jo være bedre om utviklere og testere samarbeider i større grad, tenker jeg? Noe man kan dra nytte av helt uavhengig av metode og strategi.