Testaus. Se jää usein viimeiseen hetkeen, sitten leikataan, koska olet myöhässä, ylibudjetti tai mikä tahansa muu.

Johto ihmettelee, miksi kehittäjät eivät voi vain 'saada sitä oikein ensimmäisellä kerralla', ja kehittäjät (varsinkin suurten järjestelmien kohdalla) voidaan jättää turhaan, kun eri sidosryhmät kuvaavat järjestelmän eri osia, kuten tarinan sokeat miehet kuvaavat norsua .

On kuitenkin väistämätöntä, että jokaisen projektin ensimmäinen askel on keskustelu rakennettavan ohjelmiston tai ominaisuuden käyttäytymisestä. Asiakas tai liikemies hakee jonkun kehitystiimiin ja selittää mitä hän haluaa.

Joskus nämä vuorovaikutukset tapahtuvat Ketterä käyttäjän tarina . Joskus ne tulevat muotoiluasiakirjoina, kuten Chris Foxin blogimerkintä viime vuonna. Ne voivat myös tulla vuokaavioina tai mallina Keynotessa tai jopa kiireisiä puheluita.

Pelkästään tästä viestinnästä kehittäjä on vastuussa 'vain toimivan' järjestelmän rakentamisesta.

Pelkästään tästä viestinnästä kehittäjä on vastuussa 'vain toimivan' järjestelmän rakentamisesta. Tämä on erityisen vaikeaa freelancereita työskentelee suuremman järjestelmän ulkopuolella.

Miksi testausta leikataan?

Tässä on ilmeinen aukko: jos yrityksen omistaja on suunnitellut järjestelmän käyttäytymisen alussa, miksi testataan, että nämä käyttäytymät todella työ usein vaihe, joka leikataan?

Vastaus voi olla sokaisevan yksinkertainen: testejä ei usein pidetä jaettu pääoma ; Niiden ei katsota olevan projektille arvokasta, koska 'he ovat vain insinöörejä varten' tai vastaavasti tuottavat arvoa yhdelle osastolle tai ihmisryhmälle.

Kuinka testataan tämä jaettu pääoma, tämä luettelo järjestelmän käyttäytymisestä? Hyväksymällä paitsi testivetoisen kehityksen (TDD) myös käyttäytymislähtöisen kehityksen (BDD).

Mikä on BDD?

Käyttäytymislähtöisen kehityksen tulisi keskittyä liiketoimintatapoihin, joita koodisi toteuttaa: 'miksi' koodin takana . Se tukee ryhmäkeskeistä (erityisesti rajat ylittävää) työnkulkua.

Olen nähnyt ketterän BDD: n toimivan todella hyvin, kun kehittäjä ja joko ketterä tuotteen omistaja tai yritysanalyytikko istuvat yhdessä ja kirjoittavat odottavia teknisiä tietoja (jotka kehittäjä täyttää myöhemmin) pelkkään tekstieditoriin:

1. Bisneshenkilö määrittää käyttäytymisen, jonka he haluavat nähdä järjestelmässä.
2. kehittäjä esittää kysymyksiä, jotka perustuvat heidän käsitykseensä järjestelmästä, samalla kun kirjoitetaan muistiin tarvittavat lisäkäyttäytymät kehityksen näkökulmasta.

Ihannetapauksessa molemmat osapuolet voivat viitata nykyisten järjestelmäkäyttäytymisten luetteloon nähdäksesi, rikkooko tämä uusi ominaisuus olemassa olevia ominaisuuksia.

Olen havainnut, että tämä yksinkertainen teko antaa minulle tarpeeksi rajoituksia, jotta voin ajatella kuin kehittäjä: 'Koska minun on toteutettava nämä testit, miten se pakottaa minut / kaikki spesifikaatioihin, jotka voin toteuttaa koodissa'? Koska he ovat odottavia teknisiä tietoja, he ovat nopeasti ja helposti kirjoitettavissa yhteistyön keskellä.

Tämän yhteistyöhön perustuvan lähestymistavan avulla voin keskittyä siihen, mitä ominaisuus tarjoaa loppukäyttäjälle, ja yrittäjän pitäminen siellä pakottaa minut puhumaan käyttäytymisestä, ei toteutuksesta. Tämä korostaa BDD: n ja TDD: n eroja.

Katsotaanpa esimerkki käyttäytymislähtöisestä kehityksestä

Skenaario: Olet kehittäjä tiimissä, joka vastaa yrityksen kirjanpitojärjestelmästä, joka on toteutettu Railsissa. Eräänä päivänä liikemies pyytää sinua ottamaan käyttöön muistutusjärjestelmän muistuttamaan asiakkaita heidän odottavista laskuistaan. Koska harjoittelet BDD: tä tämän tutorian mukaan; (vs. TDD), istut alas kyseisen liikemiehen kanssa ja aloitat käyttäytymisen määrittelyn.

Avaat tekstieditorin ja alat luoda odottavia teknisiä tietoja liiketoiminnalle, jota yritys haluaa:

it 'adds a reminder date when an invoice is created' it 'sends an email to the invoice's account's primary contact after the reminder date has passed' it 'marks that the user has read the email in the invoice'

Keskittyminen käyttäytymiseen kehityksen aikana tekee testistä hyödyllisen sen varmistamiseksi, että rakennat oikean ominaisuuden, eikä vain koodisi oikeellisuutta. Huomaa, että muotoilu tapahtuu yrityskielellä, ei järjestelmän sisäisellä kielellä. Et näe laskua belongs_to tai välitä siitä tili, koska kukaan kehitystiimin ulkopuolella ei välitä siitä.

Lauseke on yrityskielellä, ei järjestelmän sisäisellä toteutuskielellä. Et näe tai välitä, että lasku kuuluu tiliin, koska kukaan dev-tiimin ulkopuolella ei välitä siitä.

Jotkut kehittäjät haluavat kirjoittaa testitapauksia paikan päällä, kutsua menetelmiä järjestelmään, asettaa odotuksia, kuten:

it 'adds a reminder date when an invoice is created' do current_invoice = create :invoice current_invoice.reminder_date.should == 20.days.from_now end

Testipaketti epäonnistuu, koska emme ole vielä kirjoittamassa koodia reminder_date: n asettamiseksi.

Puuttuvien teknisten tietojen suhteen

Ymmärrän kehittäjiä, jotka kirjoittavat epäonnistuneita teknisiä tietoja, mutta liikemiehen rinnalla tämä ei ole koskaan toiminut minulle. Väärä yrittäjä joko hämmentyy yksityiskohdista tai ottaa tämän uuden tiedon ja yrittää hallita asioita, joista kehittäjä tietää enemmän (oikea tietokannan suunnittelu, koodin uudelleenkäyttö).

Kokemukseni mukaan liikemiehen tylsyys on enemmän kuin yhden rivin yleiskatsauksen kirjoittaminen tietystä käyttäytymisestä. He pitävät sitä aikansa huonona käyttönä tai haluavat kuvata seuraavaa käyttäytymistä heidän mielessään.

Miten BDD eroaa TDD: stä?

Katsotaanpa tätä toisella tavalla testipohjaisen kehityksen lähestymistavalla ja kirjoitetaan vireillä olevat testit:

it 'after_create an Invoice sets a reminder date to be creation + 20 business days' it 'Account#primary_payment_contact returns the current payment contact or the client project manager' it 'InvoiceChecker#mailer finds invoices that are overdue and sends the email'

Nämä testit ovat hyödyllisiä, mutta hyödyllisiä vain yhdelle ihmisryhmälle: insinööreille. BDD on hyödyllinen yhteydenpitoon joka toimivan tuotetiimin jäsen.

Voit varmasti tehdä testikehityksen BDD-ajattelussa odottavien käyttäytymisten avulla. Kirjoita ensin testi; suorita sitten se (punainen); tee sitten se toimimaan (vihreä); tee sitten oikea (refaktori) .

Paljon työtä BDD-yhteisössä on tehty tekemään väitteentarkistukset testin sisällä englanninkielisiksi. Tässä on stereotyyppinen RSpec-testi:

a = 42 a.should == 42

Tämä muoto helpottaa asioiden lukemista myöhemmin. Mutta muista, että emme tee tätä täällä - tarkoitus on saada käyttäytyminen alas mahdollisimman nopeasti - ja noudattaa periaatetta 'yksi testattu käyttäytyminen per spec'. Ihannetapauksessa odottavan spec-otsikon pitäisi kertoa sinulle mitä testaat.

BDD ei ole hienoja tapoja vahvistaa tuloksia; Kyse on odotettujen käytösten jakamisesta kaikkien tiimin jäsenten kesken.

Käyttäytymislähtöinen kehitys on yhteistyötä ja viestintää

Palataan takaisin skenaarioomme: työskentelemme yrityksen kirjanpitojärjestelmän parissa.

Kävelet läpi yrityksen toiminnallisuuden liikemiehen kanssa, kun analysoit järjestelmää sen sisäosien kautta (kuinka objektit sopivat yhteen sisäisesti) ja heidän analysoi järjestelmää ulkopuolelta.

Ajattelet joitain ehtoja ja kysyt liikeanalyytikosta, mitä tapahtuu seuraavissa tilanteissa:

* What's the default reminder date going to be? How many days before the invoice due date? * Are those business days or just calendar days? * What happens if there's not a primary contact associated with the account?

Ja saat vastauksia . On tärkeää, että liikeyritys ymmärtää, ettet yritä lyödä reikiä lemmikkieläinten ideaansa tai että olet liian pedanttinen.

Tällä tavalla käyttäytymislähtöinen kehitys on työkalu, joka auttaa yhteistyötä ja aloittaa keskustelun kahden osaston välillä. Se on myös tapa selvittää halutun ominaisuuden laajuus ja saada parempia arvioita kehitystiimiltä. Ehkä ymmärrät, että 10 työpäivää ei ole mahdollista laskea tietystä ajankohdasta; tämä on erillinen lisäominaisuus, joka sinun on otettava käyttöön.

Kehittäjillä on kehittäjähuomioita ('Mitä tarkalleen tarkoitat, kun sanot' päivä '?), Liikemiehillä on omat näkökohdansa (' Älä käytä termiä myöhässä, se tarkoittaa jotain erilaista '). Jos yksi tai toinen ryhmä menee pois ja yrittää kirjoittaa nämä liiketoimintalogiikan käyttäytymistestit itse (lupaus) Kurkku ) leikkaa kummankin osapuolen arvokkaan panoksen.

Se on myös hyvä valmiustila, kun ketterä asiakas ei ole enää fyysisesti huoneessa: heidän toiveensa on paperilla sekoitettuna kehittäjäanalyysiin (ja käännökseen) rakennettavastasi.

Suunnitteludokumentit

An aikaisempi ApeeScape-blogiviesti Chris Fox puhuu suunnitteludokumenteista , varsinkin projektin alussa. Yrityskäyttäytymisen ymmärtäminen ja purkaminen pienenee hankkeista, joissa järjestelmä on jonkin verran tiedossa, sellaisiin, joiden toteuttaminen vaatii vuosikymmeniä ohjelmoijavuosia ja joilla on satoja tai tuhansia käyttäytymismalleja.

Chrisin artikkelissa mainitaan myös näytön käyttäytyminen elementtejä, ja tämä on alue, jolla olen jatkuvasti ristiriidassa suunnittelijoiden kanssa: 'miltä tämä painike näyttää himmeänä' tai 'miltä tämä näyttää 11 näytöltä', koska tämä sivu on tietysti suunniteltu 24: lle ' näytöt? ' Tämä edestakaisin liikemiehen kanssa voi löytää aukkoja projektin grafiikkaomaisuudessa tai sivun asettelussa.

Hyvin suurissa rajat ylittävissä tiimeissä on monia tiimin jäseniä, joilla on omat huolenaiheensa: suunnittelijat, kehittäjät, mahdollisesti joku toiminnoista, tietokannan ylläpitäjä - ehkä laadunvalvontaviranomaiset ( kyllä, TDD: ssä ja BDD: ssä on paikka kaikille! ), jokaisella on omat huolenaiheensa ja kysymyksensä. BDD voi ohjata tätä yhteistyötä enemmän kuin testipohjainen kehitys. Kohdasta 'mitä tapahtuu, kun tiedot ovat liian suuria tälle taulukolle?' 'Hmmm, se on kallista kyselyä, haluamme välimuistin tallentaa sen jollain tavalla', 'Odota, jos käyttäjä näkee kaikki luottamuksellisia tietoja? ”, voi olla vaarassa enemmän kuin vain kehittäjä ja yritysanalyytikko, joilla on kysyttävää tästä uudesta ominaisuudesta

Käyttäytymislähtöinen kehitys koskee yhteisiä esineitä

Mikä on jaettu esine?

Haluan ajatella ohjelmistosuunnittelun 'esineitä' mahdollisesti fyysisiksi asioiksi, jotka kuvaavat projektia tai projektiryhmää ja jotka ovat löydettävissä kuusi kuukautta. Hyvät esineet selittävät miksi asiat ovat niin kuin ne ovat.

Hyvät esineet selittävät miksi asiat ovat niin kuin ne ovat. Artefakti on jokin lähdekoodi, joka on tallennettu arkistoon tai jaettuun tilaan, tai liput lippujärjestelmään.

Käytäväkeskustelut eivät ole esineitä. Eikä taulupiirustuksia. Taulupiirustukset, jotka muuttuvat suuriksi pitkän luokan dokumenteiksi tai suunnitteludokumenteiksi nämä ovat esineitä. Kokouspöytäkirjat ovat myös esineitä.

Artefakti on jokin arkistoon tai jaettuun tilaan tallennettu lähdekoodi ja liput lippujärjestelmässä tai muistiinpanot sisäisessä Wikissä - tai jopa pysyvät chat-lokit.

Jaetut artefaktit ovat mielestäni parhaat esineet . Ne osoittavat paitsi miksi jokin on tapaa, mutta miksi se on olemassa sovelluksessa ollenkaan .

Kuinka käytät niitä BDD: ssä?

Käyttäytymisen tulisi olla yhteinen tiimiartefakti - testien ei pitäisi olla vain kiireisiä ohjelmoijille! Vaikka on parasta, että sinulla on järjestelmä, jossa koko tiimi voi helposti tarkastella nykyisiä tietoja (ehkä käyttöönottojärjestelmä myös poimii ja tallentaa käyttäytymisluettelon sivuston yksityiselle alueelle tai wikiin), voit tehdä sen myös manuaalisesti sprintti.

Pelin nimi on 'auta kehittäjiä luomaan tarvittavat tiedot, jotta voimme tuottaa liiketoiminnan arvoa nopeammin, tehdä yhteistyötä yksiköiden välillä ja tehdä parempia arvioita'.

Tämä koko yrityksen käsitys siitä, mitä järjestelmä tekee on myös pääoman muoto. Se on 'miksi' koodin 'miten'.

Johtopäätös

Kuinka voimme ratkaista ongelman, että asiakkaille toimitetaan bugisia ohjelmistoja? Varmistamalla, että testausta ei pidetä jotain 'vain kehittäjät välittävät'.

Järjestelmän tarpeiden kuvaamisella ja ymmärtämisellä on runsaasti etuja koodin virheellisyyden lisäksi: osastojen välisen vuoropuhelun luominen ja kaikkien sidosryhmien huolenaiheiden (eikä vain sidosryhmien, joilla on suuret fantasiat) täyttäminen. Käyttäytymislähtöisen kehityksen avulla näiden tarpeiden ymmärtäminen alusta alkaen ja koko tiimille välitettävän ulkoisen liiketoiminnan testaaminen - että on loistava tapa varmistaa laadukas projekti.