piątek, 9 września 2016

Dzień Testera Oprogramowania


A co takiego zdarzyło się 9 września 1945? Zarejestrowany zostal pierwszy BUG oprogramowania...

Nawet data jest niepewna: 1945, czy 1947? Raczej jednak 1947, bo w 1945x jeszcze nie było tego komputerta. Za rok - OKRĄGŁA, 70 ROCZNICA!

 http://thenextweb.com/shareables/2013/09/18/the-very-first-computer-bug/#gref

środa, 7 września 2016

Analiza biznesowa, czy inżynieria wymagań?

Reklamując swój kurs, przygotowujący do certyfikatu analizy biznesowej BCS (BCS BA Foundation), dostałem następujące pytanie:
"Panie Bogdanie, a co z IREB i REQB?"
Odpowiedziałem:
Dzień dobry,
Terminologicznie:

  • Inżynieria wymagań (RE), czyli IREB & REQB, to analiza systemowa (wymagania wobec systemu IT)
  • Analiza biznesowa (BA), czyli m.in. BCS BA, to piętro wyżej: jakie są potrzeby / wymagania biznesowe? Dopiero po ich określeniu i stwierdzeniu, że najlepiej te potrzeby zrealizować budując czy modyfikując system IT (a nie, na przykład, zatrudniając 20 nowych hostess albo 10 facetów z łopatami), przechodzimy do etapu określania wymagań dla systemu.
W praktyce:
  • Firmom i osobom nagminnie się myli, co jest co; tak zwany "analityk", to zwykle hybryda "systemowego" i "biznesowego";
  • Analizę biznesową w ogóle powinno się uprawiać systematycznie i ciągle na poziomie CXO, ze wsparciem fachowców, a w praktyce często (zbyt często) jest albo częścią zarządzania kryzysowego ("ratunku, sprzedaż spada, co robić?"), albo - ZUPEŁNIE BŁĘDNIE, ALE NAGMINNIE - częścią projektu IT ("zbudujmy jakiś system, tylko pomyślmy najpierw, do czego właściwie ma służyć"). Przykładem takiego podejścia jest "Chcesz zostać analitykiem, ale nie wiesz gdzie zacząć?" Analityk (biznesowy), to nie goniec od wypytywania biznesu, czego potrzebują i chcą, lecz przedstawiciel tegoż biznesu, który umie fachowo ocenić, czego biznes potrzebuje. Potem analityk SYSTEMOWY będzie ten biznes wypytywał (pozyskiwanie wymagań), porządkował opisy np, w formie diagramów UML, ale "praktyki na analityka (biznesowego)" to coś jak "praktyki dla studentów na stanowisko CEO".
W szkoleniach:
  • BCS BA oraz IIBA dotyczą właściwej analizy biznesowej, czyli tego, jak określać strategie biznesowe, konkurencję, możliwości (więcej) - to nie są  i nie mają być w żadnym razie działania informatyczne. Ich sylabusy wchodzą wprawdzie trochę na temat inżynierii wymagań / analizy systemowej, ale powściągliwie.
  • IREB & REQB dotyczą - zgodnie ze swymi nazwami - analizy systemowej, czyli wymagań dla systemu IT, określanych na podstawie zdefiniowanych przez analizę biznesową celów i założeń biznesowych. Oczywiście, te sylabusy wchodzą trochę na obszar BA, ale też w miarę oszczędnie (np. analiza interesariuszy, określanie kontekstu systemu - tymi sprawami powinna się zajmować analiza biznesowa, nie RE).
  • IQBBA to nie BA, tylko takie trochę szersze ujęcie RE. Nawet dostawcom szkoleń się to myli i np. na stronie IT Training można przeczytać "Szkolenie IQBBA jest dedykowane projektantom usług i produktów, product ownerom oraz wszystkim osobom pracującym z analizą systemową". Uwaga: moim zdaniem, sylabus IQBBA jest bardzo dobry merytorycznie, ale w zakresie analizy systemowej (inżynierii wymagań), nie analizy biznesowej. Ponadto, jakość certyfikacji to nie tylko wiedza autora/ki sylabusa, ale także powaga organizacji.
  • Sylabus PMI BA nie jest zły, ale zanadto (to przecież PMI) projektowo zorientowany (PMBOK). BA jako część projektu to wprawdzie praktyka powszechna, ale niedobra - jak pisałem wyżej, powinna być przede wszystkim ciągła.
  • Agile BA jest ciekawe (zakłada, zgodnie z ideą agile, że analizę biznesową można i należy kontynuować także w czasie projektu), ale jest (a) znów zbyt projektowo zorientowany; (b) specyficzny dla metod agile w IT; (c) powiązany ze specyficzną metodyką DSDM, co jeszcze bardziej ogranicza jego ogólność.
  • CSBA - OK, ale "softwarecertifications" jest niemal nieznane w Europie; w Stanach, co innego.
Dziękuję za dobre pytanie i pozdrawiam!

środa, 17 sierpnia 2016

Przyszłość testowania oprogramowania

Wkrótce w czasopiśmie "Professional Tester" ukaże się artykuł Bogdana Berezy pod tytułem "The Futurology of Software Testing".

Prenumerata jest darmowa, więc warto mieć dostęp do tego najstarszego w Europie pisma dotyczącego testowania oprogramowania.

A jaka to będzie przyszłość, zdaniem autora artykułu?

The Futurology of Software Testing [fragmenty]

[...]
So, let the show begin! I have chosen four crystal balls, each looking into a different possible future.

[...]
It happens to me that I teach an [...] ISTQB course  from Monday to Wednesday, and a BPM or BPMN course on Thursday and Friday. Then an abyss of realisation opens in front of me – why, for God’s sake, neither ISTQB nor PRINCE 2, nor PMI, nor ITIL, uses BPMN diagrams to describe their “fundamental(istic) processeses”, but relies on logorrhea instead? [...]

[...]

Testing has developed and grown very, very much indeed during the last 20 years, but alas the development has gone in the direction of what I called test hacking rather than in the direction of quality thinking on all levels. Testing as profession has become the domain of nimble-fingered test execution tools’ programmers, with really great ability to automate anything. However, testing as a general approach, [...] has not developed at all. On business analysis level, and on requirements engineering level, testing is still in its infancy, with naïve, stone age gut-feeling approach dominant.

[...]
Sometimes, while explaining the intricacies of 2-switch coverage in state transition testing to some poor victims of HR departments’ ISTQB obsession, I get a very good question: “how does the choice between 1-switch and 2-switch coverage translate into customer satisfaction?”.
Needless to say, my answer is “it depends”
[...].

[...]
When everything changes, nothing changes

In the summer of 1628, the captain responsible for supervising construction of the ship, Söfring Hansson, arranged for the ship's stability to be demonstrated […]. Thirty men ran back and forth across the upper deck to start the ship rolling, but the admiral stopped the test after they had made only three trips, as he feared the ship would capsize. […] Fleming remarked that he wished the king – who had been sending a steady stream of letters insisting that the ship put to sea as soon as possible - were at home.

 

wtorek, 16 sierpnia 2016

Newsletter 2/2016

Link do Newsletter'a
Zapisy na semestr jesienny wrzesień - grudzień 2016 już ruszyły.
   
W polskiej branży IT nagminnie mylone są ze sobą zawody i zadania informatyka, programisty, technika instalatorainżyniera oprogramowania, projektanta systemów, a nawet specjalisty w dziedzinie, dla której tworzone jest dane oprogramowanie. To jakby mieszać kompetencje sprzedawcy samochodów z umiejętnościami budowniczego, który zbudował sklep z samochodami >> więcej

Według The Standish Group Chaos Report 2015, główną przyczyną niepowodzeń projektów IT są niedostatki analizy biznesowej, inżynierii wymagań oraz organizacji i współpracy.

Od wielu lat, w Szwecji funkcjonuje system yrkeshögskolor, czyli "zawodowych szkół wyższych". Programy nauczania w yrkeshögskolor tworzone są w ścisłej współpracy z przedstawicielami gospodarki, zgodnie z rzeczywistymi potrzebami firm, na czym korzystają oczywiście firmy, ale najbardziej absolwenci, których ponad 85% otrzymuje pracę zaraz po ukończeniu szkoły.
>> więcej


Czy wobec tego trzeba koniecznie zatrudniać nowych pracowników? Jak wiadomo, koszty rekrutacji, a zwłaszcza koszty nieudanej rekrutacji, są ogromne... >> więcej

Jesteśmy dla Ciebie, jeśli albo pracujesz już od wielu lat, albo właśnie skończyłeś studia, albo szkołę średnią... i dowiedziałeś się, że w Twojej dziedzinie nie ma pracy. >> więcej