Zwolnienie ich. (sądząc po błędnych stosach ..., które wychodzą z głównych instytucji)
Orbling
Mają bardzo agresywną kampanię sprzedażową i marketingową, zlecają rozwój innym krajom i unikają wszelkich możliwych błędów ... dopóki „nieoczekiwanie” nie stracą ogromnego udziału w rynku.
Job
Jak myślisz, dlaczego jest inaczej w przypadku dużych firm niż małych?
JohnFx
Odpowiedzi:
30
Oto niektóre techniki, których używa Google.
Zatrudnij dobrych programistów, którzy prawdopodobnie produkują niezawodny kod.
Posiadaj dedykowane działy kontroli jakości. Oznacza to zarówno osoby testujące, jak i zautomatyzowane programy (na przykład wykorzystujące Selenium), które symulują użytkowników końcowych.
Monitoruj produkcję, aby uchwycić dowody niewłaściwego zachowania.
Uszeregowałem je według tego, co podejrzewam, według malejącej kolejności skuteczności w wykrywaniu błędów.
Chociaż nie jest to zła odpowiedź, używasz wielu terminów, takich jak „QA”, „test jednostkowy” i „ciągła kompilacja”, które prawdopodobnie nie będą znane takiej osobie, która zadałaby takie pytanie. Byłoby lepiej, gdybyś powiązał lub podał definicje.
Gabe,
@ gabe: Dodałem wskaźniki do używanej terminologii.
btilly,
3
+1 - W rzeczywistości jest to całkiem niezła kolejność (1-> 6), kiedy jest NAJLEPSZE (tj. Najtańsze, pod względem czasu i złożoności) również łapanie błędów.
ozz
1
może także testowanie użyteczności, zanim wstążka 90% żądań funkcji słów dotyczyło funkcji, które słowo już posiadało, użytkownicy po prostu nie mogli ich znaleźć
jk.
@jk: czyja to statystyka? cytat proszę.
JBRWilkinson
19
Większe firmy zwykle mają całe całe działy Q / A, które są odpowiedzialne za testowanie kodu i upewnianie się, że działa tak, jak powinien. Zazwyczaj jest tak, jak opisałeś - grupa ludzi testuje wiele maszyn. Czasami testy są zautomatyzowane, a czasem nie. Zobacz Quality Assurance - Wikipedia
Wiele razy sami programiści znajdą błędy podczas procesu programowania. Ponadto klienci często jako pierwsi znajdują błąd.
Tak, a ludzie z działu kontroli jakości tworzą plany testów.
Job
+1: Dokładnie tak to robimy, zespół testowy (na którym jestem) pisze plany testów i cały kod testowy, z wyjątkiem trywialnych testów jednostkowych (deweloperzy piszą te, z których niektóre ćwiczą TDD, ale nie jest to obowiązkowe). Koncentrujemy się na akceptacji, integracji i regresjach. Gdy deweloperzy znajdą błędy, zarejestrują je, naprawią, a my przetestujemy i napiszemy automatyzację.
Steven Evers,
18
Powiedziałbym, że chodzi o dojrzałość firmy, a nie o wielkość :) Są duże firmy, które mają słabe praktyki rozwojowe i małe firmy, które są w czołówce.
Ogólnie rzecz biorąc, dojrzały zespół programistów zaangażuje się w następujące działania do 1; zminimalizować wprowadzanie nowych błędów do systemu i 2; znajdź błędy w istniejącym systemie.
Testy jednostkowe: są to „mini-sterowniki” dla poszczególnych metod, aby upewnić się, że metoda robi to, co mówi. Są to zawsze testy automatyczne.
Testy integracyjne: testy te mają na celu sprawdzenie, czy w systemie działa większa jednostka funkcjonalności. Może to obejmować testowanie integracji bazy danych lub integracji z bibliotekami stron trzecich. Są to również testy automatyczne.
Testy akceptacyjne: testy akceptacyjne są zapisywane w celu przetestowania wymagań użytkownika. Zazwyczaj testują one „szczęśliwą ścieżkę”. W moim zespole testy te mają na celu wykazanie, że jeśli użytkownik będzie korzystał z funkcji zgodnej z przeznaczeniem, nie będzie miał problemów. Może być ręczny lub automatyczny.
Testy funkcjonalne: testy te są podobne do testów akceptacyjnych, ale testują także „nieszczęśliwą ścieżkę”. Testy te oznaczają przetestowanie mało oczywistych scenariuszy. Może być ręczny lub automatyczny.
Testy regresyjne: używamy tego terminu do „pełnego testowania” systemu przed udostępnieniem go klientom. Ręczny lub automatyczny.
Testy goryla: (tylko ręczne). Jest to rodzaj testowania, gdy bardzo inteligentni ludzie celowo próbują przerwać aplikację.
Testy wydajności Celem jest upewnienie się, że wydajność jest akceptowalna i nie zmniejsza się z czasem. Zwykle zautomatyzowany.
Testy stabilności: testy te mają na celu zapewnienie stabilności systemu w czasie. Zautomatyzowane.
Ciągła integracja: jest to system, który automatycznie sprawdza kod, kompiluje go i uruchamia automatyczne testy. Twoje szybsze testy (jednostka, integracja) będą uruchamiane za każdym razem, gdy programista zatwierdzi kod. Niektóre inne są uruchamiane co noc (akceptacja, funkcjonalność) lub co tydzień (wydajność, stabilność).
Raporty pokrycia kodu: pokazuje, ile części kodu jest testowane. Kod, który nie jest objęty testem, jest bardziej podatny na uszkodzenie.
Różne narzędzia analizujące kod: Zazwyczaj pokazują one, gdzie kod musi zostać ponownie podzielony na faktury, aby był mniej podatny na potencjalne błędy.
Programowanie w parach: dwóch programistów współpracujących w celu zapewnienia funkcjonalności. „Spójna para jest lepsza niż suma jej części”.
Najważniejsze do zabrania to: automatyzacja i ciągła integracja .
Nie zgadzają się co do dojrzałości firmy - jest całkiem możliwe, że kierownik ds. Rozwoju oprogramowania dba o jakość również w małej / młodej firmie, a przesłanie to jest odgórne. Dojrzałość inżynierów, tak, to możliwe.
JBRWilkinson
1
@JBRWilkinson: Myślę, że możemy zacząć mówić o tym, co to znaczy, że firma jest „dojrzała”. Nie chciałem sugerować, że ma to związek z wiekiem, bardziej jak „mądrość”. Autostart może być dojrzały / mądry, nawet jeśli ma dopiero rok lub dwa lata.
c_maker 25.01.12
4
To zależy od firmy i opracowywanych produktów.
Po pierwsze, wiele firm egzekwuje praktyki kodowania, takie jak przeglądy kodu i obowiązkowe podszywanie się (narzędzia do automatycznego wykrywania błędów), aby zmniejszyć liczbę błędów w repozytorium. Wiele firm przyjęło również testy jednostkowe. Tak jest w przypadku mojej pracy (Google). Po wpisaniu kodu testy są przeprowadzane na wszystkich elementach, aby upewnić się, że nie zostaną wprowadzone żadne nowe błędy.
Po drugie, wiele firm ma działy kontroli jakości odpowiedzialne za sprawdzanie poprawności zachowań. Jest to szczególnie powszechne w finansach (gdzie błędy mogą być kosztowne, a zasady sprawdzania poprawności są złożone), ale występuje również w firmach, które sprzedają produkty użytkownikom, których wycofanie może być kosztowne (np. Intel, Microsoft itp.).
Po trzecie, ilekroć jest to możliwe, firmy przeprowadzają Dogfooding (ich użytkownicy używają produktu wewnętrznie), a następnie wypuszczają ograniczone wersje beta. Na tym etapie wychwytuje się wiele błędów. Na przykład ludzie pracujący w firmie Microsoft używają nowszych wewnętrznych wersji pakietu Office, Windows i DevStudio niż to, co masz na zewnątrz. Następnie ograniczone grupy użytkowników lub zakontraktowane firmy mogą pobrać próbkę. Podobnie w Google używamy wewnętrznych wersji Gmaila i Dokumentów przed wydaniem. Firmy produkujące gry organizują otwarte bety w celu przetestowania swoich produktów i obciążenia serwerów itp.
Oczywiście odpowiedź brzmi „It dpends”, ale dam próbkę z mojego największego do tej pory projektu, w którym w szczycie zaangażowanych było około 50 programistów.
Podstawowa konfiguracja: oprogramowanie zaplecza do przetwarzania dużych ilości danych za pomocą BizTalk.
Pierwszą linią obrony są testy jednostkowe. W naszym przypadku były one wykonywane codziennie dla wszystkiego sprawdzanego w kontroli źródła i zwykle niektóre z nich były wykonywane ręcznie przez programistę przed odprawą. Testy jednostkowe zostały napisane głównie przez programistów, ale czasem poprawione przez dodatkowe testy przez testerów.
Kolejnym krokiem była cotygodniowa kompilacja Virtual PC, w której testerzy przeprowadzili serię głównie zautomatyzowanych kompleksowych testów przepływu danych w oparciu o dokumenty specyfikacji dla każdego komponentu.
Następnie ten sam wirtualny komputer został wzbogacony o pewne dane biznesowe całkiem zbliżone do rzeczywistych i przetestowany ponownie z pewnymi konkretnymi przypadkami użycia.
Następnie Virtual PC został połączony z innymi komponentami systemu (również głównie wirtualnymi) z innych działów do cyklu testów integracyjnych opartych na kompleksowych testach od użytkownika wprowadzającego dane do końca przepływu danych.
Na innej ścieżce pakiety instalacyjne zostały przetestowane przez dostawcę systemów, aby sprawdzić, czy zostały poprawnie zainstalowane w środowisku produkcyjnym i czy można je przywrócić, jeśli coś się nie powiedzie.
Po instalacji w środowisku produkcyjnym przeprowadziliśmy testy obciążenia i obciążenia, aby przetestować ogólną stabilność (nie należy tego lekceważyć, gdy uruchomisz 10 serwerów BizTalk, 8 serwerów SQL i kilka innych specjalistycznych urządzeń, takich jak akcelerator XML oraz dedykowane Archiwum - wszystkie oczywiście skupione).
Kiedy byliśmy zadowoleni ze wszystkich testów, kod został wprowadzony do produkcji. Dostajesz dość duże opóźnienie, aby naprawić błędy w kodzie (na przykład 4-6 tygodni dla całego cyklu testowego), i wykonanie wszystkich tych testów jest drogie, ale ogólna stabilność była całkiem dobra. W rzeczywistości najlepsze, jakie widziałem do tej pory. Znowu jest to dość ważne w systemie, który każdego dnia przetwarza kilka milionów dolarów. Twoje wymagania mogą się różnić, ale tak to zrobiliśmy i działało.
Oryginalne pytanie wydaje się bardziej ogólne pod względem koncepcyjnym niż większość bardzo szczegółowych odpowiedzi, które zostały udzielone.
Spójrzmy na to z wyższego poziomu (mniej szczegółowe). Oprogramowanie jest opracowywane w celu zaspokojenia określonych potrzeb od kogoś (osoby, firmy, cokolwiek).
Potrzeby te muszą zostać zamapowane na poszczególne historie / wymagania, które zostałyby ostatnio (w fazie budowy) zaimplementowane w kodzie źródłowym.
Dobrze zdefiniowane historie / wymagania są niezbędne dla zespołu zapewniania jakości (QA) (rzeczywistych testerów oprogramowania), aby zweryfikować ostateczny kod, gdy zostanie wykonany, odpowiada wymaganiom tych historii i wymagań. W tym celu zespół ds. Kontroli jakości tworzy „przypadki testowe” w celu przeprowadzenia tej weryfikacji.
Kod, po wydaniu zespołowi ds. Kontroli jakości, zostanie przetestowany i wykryte zostaną błędy. Błędy różnych typów i ciężkości. Błędy są śledzone, a programiści przydzielają je, aby w końcu je naprawić.
Korzystanie z maszyn wirtualnych umożliwia obecnie testerowi uruchamianie różnych środowisk na tym samym prawdziwym sprzęcie. Czasami jednak potrzebujesz niektórych komputerów poświęconych fazie kontroli jakości.
Mam nadzieję, że to pomoże ci zrozumieć (z grubsza) cały proces.
Cóż, nie znoszę być cyniczny, ale przy liczbie otwartych błędów w pewnym systemie operacyjnym „urządzenia” wydaje się, że im większa i bogatsza firma, tym więcej błędów są w stanie stworzyć i dostarczyć do użytkownika końcowego. Jeśli oprogramowanie działa i wygląda fajnie, po prostu i tak je wypuszcza. Jeśli menedżerowie uważają, że jest gotowy, to jest gotowy. To wtedy naprawdę paskudne robaki zaczynają wychodzić z stolarki, a użytkownicy końcowi stają się świnkami morskimi. Dziesięć lat później większość błędów zostanie opracowana (i kilka dodanych dla lepszej oceny), a firma będzie gotowa przejść do następnego wielkiego pomysłu.
Odpowiedzi:
Oto niektóre techniki, których używa Google.
Uszeregowałem je według tego, co podejrzewam, według malejącej kolejności skuteczności w wykrywaniu błędów.
źródło
Większe firmy zwykle mają całe całe działy Q / A, które są odpowiedzialne za testowanie kodu i upewnianie się, że działa tak, jak powinien. Zazwyczaj jest tak, jak opisałeś - grupa ludzi testuje wiele maszyn. Czasami testy są zautomatyzowane, a czasem nie. Zobacz Quality Assurance - Wikipedia
Wiele razy sami programiści znajdą błędy podczas procesu programowania. Ponadto klienci często jako pierwsi znajdują błąd.
Mniejsze firmy, takie jak te, w których obecnie pracuję, stosują praktykę Agile Testing
źródło
Powiedziałbym, że chodzi o dojrzałość firmy, a nie o wielkość :) Są duże firmy, które mają słabe praktyki rozwojowe i małe firmy, które są w czołówce.
Ogólnie rzecz biorąc, dojrzały zespół programistów zaangażuje się w następujące działania do 1; zminimalizować wprowadzanie nowych błędów do systemu i 2; znajdź błędy w istniejącym systemie.
Testy jednostkowe: są to „mini-sterowniki” dla poszczególnych metod, aby upewnić się, że metoda robi to, co mówi. Są to zawsze testy automatyczne.
Testy integracyjne: testy te mają na celu sprawdzenie, czy w systemie działa większa jednostka funkcjonalności. Może to obejmować testowanie integracji bazy danych lub integracji z bibliotekami stron trzecich. Są to również testy automatyczne.
Testy akceptacyjne: testy akceptacyjne są zapisywane w celu przetestowania wymagań użytkownika. Zazwyczaj testują one „szczęśliwą ścieżkę”. W moim zespole testy te mają na celu wykazanie, że jeśli użytkownik będzie korzystał z funkcji zgodnej z przeznaczeniem, nie będzie miał problemów. Może być ręczny lub automatyczny.
Testy funkcjonalne: testy te są podobne do testów akceptacyjnych, ale testują także „nieszczęśliwą ścieżkę”. Testy te oznaczają przetestowanie mało oczywistych scenariuszy. Może być ręczny lub automatyczny.
Testy regresyjne: używamy tego terminu do „pełnego testowania” systemu przed udostępnieniem go klientom. Ręczny lub automatyczny.
Testy goryla: (tylko ręczne). Jest to rodzaj testowania, gdy bardzo inteligentni ludzie celowo próbują przerwać aplikację.
Testy wydajności Celem jest upewnienie się, że wydajność jest akceptowalna i nie zmniejsza się z czasem. Zwykle zautomatyzowany.
Testy stabilności: testy te mają na celu zapewnienie stabilności systemu w czasie. Zautomatyzowane.
Ciągła integracja: jest to system, który automatycznie sprawdza kod, kompiluje go i uruchamia automatyczne testy. Twoje szybsze testy (jednostka, integracja) będą uruchamiane za każdym razem, gdy programista zatwierdzi kod. Niektóre inne są uruchamiane co noc (akceptacja, funkcjonalność) lub co tydzień (wydajność, stabilność).
Raporty pokrycia kodu: pokazuje, ile części kodu jest testowane. Kod, który nie jest objęty testem, jest bardziej podatny na uszkodzenie.
Różne narzędzia analizujące kod: Zazwyczaj pokazują one, gdzie kod musi zostać ponownie podzielony na faktury, aby był mniej podatny na potencjalne błędy.
Programowanie w parach: dwóch programistów współpracujących w celu zapewnienia funkcjonalności. „Spójna para jest lepsza niż suma jej części”.
Najważniejsze do zabrania to: automatyzacja i ciągła integracja .
źródło
To zależy od firmy i opracowywanych produktów.
Po pierwsze, wiele firm egzekwuje praktyki kodowania, takie jak przeglądy kodu i obowiązkowe podszywanie się (narzędzia do automatycznego wykrywania błędów), aby zmniejszyć liczbę błędów w repozytorium. Wiele firm przyjęło również testy jednostkowe. Tak jest w przypadku mojej pracy (Google). Po wpisaniu kodu testy są przeprowadzane na wszystkich elementach, aby upewnić się, że nie zostaną wprowadzone żadne nowe błędy.
Po drugie, wiele firm ma działy kontroli jakości odpowiedzialne za sprawdzanie poprawności zachowań. Jest to szczególnie powszechne w finansach (gdzie błędy mogą być kosztowne, a zasady sprawdzania poprawności są złożone), ale występuje również w firmach, które sprzedają produkty użytkownikom, których wycofanie może być kosztowne (np. Intel, Microsoft itp.).
Po trzecie, ilekroć jest to możliwe, firmy przeprowadzają Dogfooding (ich użytkownicy używają produktu wewnętrznie), a następnie wypuszczają ograniczone wersje beta. Na tym etapie wychwytuje się wiele błędów. Na przykład ludzie pracujący w firmie Microsoft używają nowszych wewnętrznych wersji pakietu Office, Windows i DevStudio niż to, co masz na zewnątrz. Następnie ograniczone grupy użytkowników lub zakontraktowane firmy mogą pobrać próbkę. Podobnie w Google używamy wewnętrznych wersji Gmaila i Dokumentów przed wydaniem. Firmy produkujące gry organizują otwarte bety w celu przetestowania swoich produktów i obciążenia serwerów itp.
źródło
Oczywiście odpowiedź brzmi „It dpends”, ale dam próbkę z mojego największego do tej pory projektu, w którym w szczycie zaangażowanych było około 50 programistów.
Podstawowa konfiguracja: oprogramowanie zaplecza do przetwarzania dużych ilości danych za pomocą BizTalk.
Pierwszą linią obrony są testy jednostkowe. W naszym przypadku były one wykonywane codziennie dla wszystkiego sprawdzanego w kontroli źródła i zwykle niektóre z nich były wykonywane ręcznie przez programistę przed odprawą. Testy jednostkowe zostały napisane głównie przez programistów, ale czasem poprawione przez dodatkowe testy przez testerów.
Kolejnym krokiem była cotygodniowa kompilacja Virtual PC, w której testerzy przeprowadzili serię głównie zautomatyzowanych kompleksowych testów przepływu danych w oparciu o dokumenty specyfikacji dla każdego komponentu.
Następnie ten sam wirtualny komputer został wzbogacony o pewne dane biznesowe całkiem zbliżone do rzeczywistych i przetestowany ponownie z pewnymi konkretnymi przypadkami użycia.
Następnie Virtual PC został połączony z innymi komponentami systemu (również głównie wirtualnymi) z innych działów do cyklu testów integracyjnych opartych na kompleksowych testach od użytkownika wprowadzającego dane do końca przepływu danych.
Na innej ścieżce pakiety instalacyjne zostały przetestowane przez dostawcę systemów, aby sprawdzić, czy zostały poprawnie zainstalowane w środowisku produkcyjnym i czy można je przywrócić, jeśli coś się nie powiedzie.
Po instalacji w środowisku produkcyjnym przeprowadziliśmy testy obciążenia i obciążenia, aby przetestować ogólną stabilność (nie należy tego lekceważyć, gdy uruchomisz 10 serwerów BizTalk, 8 serwerów SQL i kilka innych specjalistycznych urządzeń, takich jak akcelerator XML oraz dedykowane Archiwum - wszystkie oczywiście skupione).
Kiedy byliśmy zadowoleni ze wszystkich testów, kod został wprowadzony do produkcji. Dostajesz dość duże opóźnienie, aby naprawić błędy w kodzie (na przykład 4-6 tygodni dla całego cyklu testowego), i wykonanie wszystkich tych testów jest drogie, ale ogólna stabilność była całkiem dobra. W rzeczywistości najlepsze, jakie widziałem do tej pory. Znowu jest to dość ważne w systemie, który każdego dnia przetwarza kilka milionów dolarów. Twoje wymagania mogą się różnić, ale tak to zrobiliśmy i działało.
źródło
Oryginalne pytanie wydaje się bardziej ogólne pod względem koncepcyjnym niż większość bardzo szczegółowych odpowiedzi, które zostały udzielone.
Spójrzmy na to z wyższego poziomu (mniej szczegółowe). Oprogramowanie jest opracowywane w celu zaspokojenia określonych potrzeb od kogoś (osoby, firmy, cokolwiek).
Potrzeby te muszą zostać zamapowane na poszczególne historie / wymagania, które zostałyby ostatnio (w fazie budowy) zaimplementowane w kodzie źródłowym.
Dobrze zdefiniowane historie / wymagania są niezbędne dla zespołu zapewniania jakości (QA) (rzeczywistych testerów oprogramowania), aby zweryfikować ostateczny kod, gdy zostanie wykonany, odpowiada wymaganiom tych historii i wymagań. W tym celu zespół ds. Kontroli jakości tworzy „przypadki testowe” w celu przeprowadzenia tej weryfikacji.
Kod, po wydaniu zespołowi ds. Kontroli jakości, zostanie przetestowany i wykryte zostaną błędy. Błędy różnych typów i ciężkości. Błędy są śledzone, a programiści przydzielają je, aby w końcu je naprawić.
Korzystanie z maszyn wirtualnych umożliwia obecnie testerowi uruchamianie różnych środowisk na tym samym prawdziwym sprzęcie. Czasami jednak potrzebujesz niektórych komputerów poświęconych fazie kontroli jakości.
Mam nadzieję, że to pomoże ci zrozumieć (z grubsza) cały proces.
źródło
Cóż, nie znoszę być cyniczny, ale przy liczbie otwartych błędów w pewnym systemie operacyjnym „urządzenia” wydaje się, że im większa i bogatsza firma, tym więcej błędów są w stanie stworzyć i dostarczyć do użytkownika końcowego. Jeśli oprogramowanie działa i wygląda fajnie, po prostu i tak je wypuszcza. Jeśli menedżerowie uważają, że jest gotowy, to jest gotowy. To wtedy naprawdę paskudne robaki zaczynają wychodzić z stolarki, a użytkownicy końcowi stają się świnkami morskimi. Dziesięć lat później większość błędów zostanie opracowana (i kilka dodanych dla lepszej oceny), a firma będzie gotowa przejść do następnego wielkiego pomysłu.
źródło