Prawo Conway'a w testowaniu

Prawo Conway'a to powiedzenie, które mówi, że organizacje projektują systemy odzwierciedlające ich własną strukturę komunikacyjną. Jego nazwa pochodzi od programisty komputerowego Melvina Conway'a, który wprowadził ten pomysł w 1967 r. Jego oryginalne sformułowanie brzmiało:

Każda organizacja, która projektuje system, wytworzy projekt, którego struktura jest kopią struktury komunikacyjnej organizacji.

Patrząc na to zagadnienie z perspektywy testów, można projektować testy dla samego rozwiązania, bazując na znanej nam architekturze firmy odbiorców tegoż rozwiązania. 

Prawo opiera się na rozumowaniu, że aby produkt mógł funkcjonować, autorzy i projektanci jego części składowych muszą się ze sobą komunikować, by zapewnić kompatybilność między poszczególnymi jego elementami. Z tego też powodu struktura techniczna systemu będzie odzwierciedlać granice społeczne organizacji, które go wytworzyły, w poprzek których komunikacja jest trudniejsza. Mówiąc kolokwialnie, oznacza to, że złożone produkty kończą "ukształtowane jak" struktura organizacyjna, w której lub dla której zostały zaprojektowane. Idąc tym tropem, osoba odpowiedzialna za planowanie, projektowanie i wykonywanie testów, mając wiedzę na temat organizacji jest w stanie lepiej poprowadzić projekt testowy. Nie jest to oczywiście nic nowego i świadomość kontekstu funkcjonowania organizacji zawsze była przydatna w prowadzeniu weryfikacji jakości. Tu jednak idziemy krok dalej, bo mówimy o odwzorowaniu organizacji w oprogramowaniu, łącznie z bardzo szczegółowymi elementami, jak np. architektura kodu czy też interfejs graficzny. 

Dowody na poparcie prawa Conway'a zostały opublikowane przez zespół badaczy z Massachusetts Institute of Technology (MIT) i Harvard Business School, którzy, używając "hipotezy lustrzanej" jako odpowiednika prawa Conway'a, znaleźli silne dowody na jej poparcie oraz udowodnili, że "produkt opracowany przez organizację luźno sprzężoną jest znacząco bardziej modułowy niż produkt pochodzący z organizacji ściśle sprzężonej". Autorzy podkreślają wpływ "organizacyjnych decyzji projektowych na techniczną strukturę artefaktów, które te organizacje następnie rozwijają". Z tego mniej więcej powodu aktualnie prawo stosowane jest przede wszystkim w dziedzinie architektury oprogramowania, co jest ograniczeniem pierwotnych założeń Conway'a. Ukierunkował je on znacznie szerzej, a jego ustalenia i wnioski dotyczyły większości dziedzin technicznych. Wracając więc do fundamentów, możemy lepiej zrozumieć zamysł twórcy tego prawa, który widział podobieństwo na różnych warstwach i poziomach tworzonego oprogramowania. 

Eric S. Raymond, zwolennik open-source, przedstawił prawo Conway'a w The New Hacker's Dictionary pisząc: "Organizacja oprogramowania i organizacja zespołu programistów będą zgodne". Idąc dalej, przykład wpływu Prawa Conway'a można znaleźć w projektowaniu niektórych stron internetowych organizacji. Nigel Bevan stwierdził w pracy z 1997 roku, dotyczącej kwestii użyteczności stron internetowych:

Organizacje często tworzą strony internetowe o zawartości i strukturze odzwierciedlającej raczej wewnętrzne obawy organizacji niż potrzeby użytkowników strony.

W tym obszarze możemy znaleźć ważną weryfikację jakości tworzonego produktu, gdzie testerzy użyteczności muszą przekonać interesariuszy projektowych do próby przełamania prawa Conway'a. Rolą eksperta UX będzie tu zaadresowanie problemów użytkowników, a nie obsługa „problemów” organizacji, które zapłaciły za stworzenie oprogramowania. Przykładem powodzenia może być rewolucja na stronach internetowych sprzedawców samochodów. Przez wiele lat odzwierciedlały one potrzeby biznesowe pokazania wszystkich produktów na pierwszej stronie, co kończyło się przeładowaniem treściami i niechęcią odwiedzających do kupowania samochodów. Dzisiejsze strony są już bardziej wyważone, z dużym naciskiem na ograniczenie informacji tylko do tych niezbędnych oraz łatwe dotarcie do szczegółów. 

Reasumując, Prawo Conway'a działa i ciągle ma się dobrze, ale świadomi testerzy oprogramowania mogą je wykorzystać do prowadzenia testów. Po pierwsze, poprzez użycie zrozumienia organizacji do testowania dedykowanego mu rozwiązania. Testy te mogą przebiegać na wielu poziomach od architektury kodu, poprzez integrację modułów po testy akceptacyjne. Po drugie, testerzy, poprzez uświadamianie, że prawo to może prowadzić do wytworzenia produktu niedopasowanego do odbiorcy, mogą prowadzić do jego przełamania.