Metryki:
1. Szybkość dostępu do zaawansowanych opcji ustawień systemu.
Jeżeli użytkownik dostanie się do żądanej opcji w 4-ech lub mniej kliknięciach = 1
Jeżeli użytkownik dostanie się do żądanej opcji w 5-ciu kliknięciach = 0.75
Jeżeli użytkownik dostanie się do żądanej opcji w 6-ciu lub więcej kliknięciach = 0
Przyczyny Wyboru metryki :
W przypadku urządzeń telefonicznych kluczową sprawą jest długość jaki użytkownik spędza na znalezieniu i dostania się do żądanej opcji. Skrócenie czasu (ilości kliknięć), stworzenie skrótów dostępowych jest kluczowym wobec mnie elementem jakościowym systemu.
2. a) Niezawodność (stabilna praca bez wieszania się):
Dobry telefon to taki który się nie zawiesza. Wiadowo, że nie ma rzeczy doskonałych więc w tym aspekcie możemy iść na pewne ustępstwa:
- telefon zawiesza się po pierwszym roku pracy - metryka 1
- telefon zawiesza się po pół roku pracy - metryka 0,75
- telefon zawiesza się po 3 miesiącach (raz na trzy miesiące) - metryka 0,4
- telefon zawiesza się raz na miesiąc - metryka 0
b) Szybkość działania
Bardzo ważne przynajmniej dla mnie jest to aby menu w telefonie działało jak
najszybciej, ponieważ nie lubię czekać zanim mi się otworzy np. Książka telefoniczna.
Podczas poruszania się po menu przejście do kolejnego poziomu następuje:
- natychmiast - metryka 1
- po 0,5 sekundy - metryka 0,75
- 1 sekundę - metryka 0,5
- 2 sekundy - metryka 0,3
- powyżej 5 sekund - metryka 0
Apekty systemu do przetestowania:
1.Wg mnie najwazniejszym aspektem systemu jest niezawodnosc. Jest to najwazniejsza cecha nowoczesnych telefonow. System nie moze sie zawieszac, blokowac, zrywac polaczen. Klientowi najbardziej zalezy na niezawodnym telefonie
2. Ważnym aspektem systemu jest bezpieczeństwo przed dostąpem niepożądanych osób i programów. Chodzi o to aby na nasz telefon nie dostały się wirusy i żeby inni nie byli w stanie włamać się na nasz telefon, dzwonić z niego lub podsłuchiwać nasze rozmowy.
3. Odp. Istnieje sześć podstawowych cech charakteryzujących dobre produkty software'owe. Są to:
Funkcjonalność,
Niezawodność,
Użyteczność,
Efektywność,
Pielęgnowalność,
Przenaszalność.
W tym konkretnym przypadku ważnym aspektem może okazać sie niezawodność. To znaczy, że musi istnieć gwarancja, że wszystkie zaprogramowane funkcje będą działać odpowiednio sprawnie. Nawet jeżeli wystąpi błąd, musimy pomyśleć o obronie przed takimi błędami (ważny czas naprawy błędów!). Po co? Po to, aby nie frustrować klientów takich telefonów i zachęcić do ewentualnej zmiany na nowszy model w przyszłości.
4. Zakładam, że nasza firma ma wytworzyć oprogramowanie dla telefonów działających w systemie UMTS, tzn. Nie dla konkretnego producenta ani modelu tylko uniwersalny program dla wszystkich. Uważam iż w takim przypadku bardzo ważna jest przenaszalność oprogramowania, ponieważ ma to być soft uniwersalny i musimy zadbać o jego zgodność dla poszczególnych modeli telefonów. Technologia UMTS jest to bardzo zaawansowana technologia oferująca wiele zaawansowanych i użytecznych możliwości dla użytkownika. Aby można było wymieniać dane między telefonami niezbądny do tego jest uniwersalne oprogramowanie.
5. Myśle, że najistotniejszym aspektem systemu do przetestowania będą własności operacyjne systemu tj.wymagania logistyczne,organizacyjne, uzyteczność/stopień skomplikowania instrukcji kierowanych do systemu, czytelnośc ekranów,jakośc komunikatów, jakość pomocy itd.
Te wcześniej wyliczone przeze mnie rzeczy w dużym stopniu stanowią o jakości produktu oraz przede wszystkim o dobrym przyjęciu produktu przez użytkownika dzięki wysokiej jakości jego użyteczności i komunikacji z użytkownikiem.
Wiadomo, że klient woli produkt prosty w obsłudze i komunikacji z nim.
6. Testowaniu poddałbym aspekt stabilności oprogramowania. Jest to kluczowy aspekt dla użytkowników telefonów, gdyż „wieszający się telefon to zły telefon”. Zyskanie takiej opinii producenta telefonów wśród klientów może bardzo niekorzystnie wpłynąć na wizerunek marki. Roszczenia producenta z tego tytułu do wytwórcy oprogramowania mogą być równie nieprzyjemne.
7. Według mnie w przypadku telefonów komórkowych bardzo istotnym aspektem jest interfejs użytkownika. Istnieje całe mnóstwo modeli telefonów, a każdy z nich ma swój własny interfejs, który powinien go w pewien sposób wyróżniać i identyfikować. Jeżeli to ma być nowa generacja telefonów, to również ich interfejs powinien być unikalny świeży, , funkcjonalny i wygodny w obsłudze dla przyszłego użytkownika.
8. Test dostępności oprogramowania, systemu operacyjnego.
Dlaczego?
Osoba kożystająca z telefonu potrzebuje szybkiego dostępu do informacji (książka adresowa);
Szybko i sprawnie chce przechodzić pomiędzy poszczególnymi funkcjami telefonu.
Szczególnie ważny jest szybki dostęp do e-mail'a, książki addresowej, wiadomości.
Mniej istotny jest dostęp do gier itp.
9. Moim zdanie podstawowym aspektem testowania do tego systemu sa własności operacyjne systemu np. wymagania logistyczne,organizacyjne, uzyteczność oraz stopień skomplikowania instrukcji kierowanych do systemu, czytelnośc ekranów,jakośc komunikatów, jakość pomocy,
ktore sa miara jakosci oraz latwosci uzycia sytemu .
10. Wedlug mnie, istotnym aspektem do prowadzenia testow bedzie interfejs calego systemu. Chocby system spelnial najwieksze wymagania dotyczace sprawnosci i szybkosci dzialania to i tak liczy sie prosta i szybka dostepnosc poszczegolnych funkcji systemu. Wlasnie obsluga w pierwszym kontakcie uzytkownika z systemem decyduje o tym czy produkt staje sie przyjazny dla uzytkownika i tym samym czyni go produktem wysokiej jakosci.
11.
Plany testów:
1. System powinien byc przetestowany bardzo zetelnie, poniewaz gdy wypuscimy system do sprzedazy i okaze sie po jakims czasie ze jeden z modolow posiada bledy trzeba bedzie dokonac tej naprawy we wszystkich sprzedanych aparatach, taka „wpadka” takze zle zutuje na wizerunek naszej firmy (zreszta jak kazda wpadka)
Nalezy wykonac testy:
modułów: Kazdy z zrealizowanych modolow powinien zostac przetestowany (modol odpowiedzialny za wiadomosci tekstowe (SMS), EMS, MMS, modol odpowiedzialny za realizacje polaczen)
systemu: Po zintegrowaniu wszystkich systemow nalezy wykonac testy sprawdzajace czy oddzielne modoly po polaczeniu nie wplywaja negatywnie na siebie i czy poprawnie wspolpracuja.
akceptacji: gotowy i przetestowany przez nas system ma byc przekazany do testow beta. (ograniczona grupa uzytkownikow dostanie w pelni funkcjonalny system w celu przetestowania)
2. Przedmiotem testów będzie test zgodności oprogramowania osadzonego na różnych telefonach. Teste rozpoczął bym od testów statycznych w celu sprawdzenia czy stworzony system jest zgodny z założeniabi i czy dane na których będzie operował są poprawne na wszystkich testowanych telefonach.
Plan testów statycznych:
- losowa konstrukcja danych przesyłanych w systemie zgodna z założeniami
- określenie wyników działania systemu na tych danych
- uruchomienie systemu na wszystkich aparatach oraz porównanie jego działania z
założeniami
Następnie wykonał bym testy funkcjonalne, dając telefony testowe pewnej grupie użytkowników nie związanych z projektem. Z założenia mogli by oni wykonywać dowolne operacje umozliwiane przez system.
3. Testowany będzie system operacyjny, jak zachowuje się podczas uruchamiania poszczególnych aplikacji, mierzony będzie czas reakcji systemu.
Będę stosował tak zwaną metodę testowania wstępującego, czyli będę testował jak zachowują się poszczególne moduły (oddzielnie), jak przejdą testy pozytywnie będę je łączył w całość optymalizował.
4. Aspekt systemu - własności operacyjne systemu.
Wymagania logistyczne i organizacyjne - model czarnej skrzynki w celu znalezienia brakujących funkcji systemu oraz biała skrzynka w celu sprawdzenia wewnętrznej logiki programów
Użyteczność/stopień skomplikowania instrukcji kierowanych do systemu , czytelność ekranów, jakość pomocy, komunikatów - formalny przegląd oprogramowania w formie prezentacji wybranych funkcji produktu dla przyszłych potencjalnych klientów w celu uzyskania ich opinii
5. Testowaniu poddana zostanie wydajność systemu (czy nie ma żadnych opóźnień w czasie komunikacji telefonu z przekaźnikami rodzaj testów - WYKRYWANIE BŁĘDÓW oraz TESTY DYNAMICZNE oraz TESTY CZARNEJ SKRZYNKI) , interfejs systemu ( kilkaset próbnych telefonów rozdanych stałym klientom w programie testów a potem zebranie informacji i opinii od klientów TESTY AKCEPTACJI ), niezawodność oprogramowania ( czy telefon się nie zawiesza w trakcie rozmów, kiedy dodatkowo dochodzą sms'y, emms'y kolejne połączenia itp.TESTY DYNAMICZNE oraz WYKRYWANIE BŁĘDÓW )
Testowaniu poddałbym również odtwarzalność oprogramowania.
6. ponieważ Klient kładzie duży nacisk na wykrywanie błędów, należy przeprowadzać dużo testów na to ukierunkowanych
- należy zachęcać programistów, aby w trakcie kodowania od razu testowali poszczególne funkcje. Mogą to być zarówno testy formalne, jak i nieformalne.
- osoby projektujące interfejs (np. graficy) powinni już na etapie projektowania konfrontować swoje pomysły z grupą testową
- po ukończeniu każdego z modułów należy je przetestować (ewentualnie zastępując moduły współpracujące implementacjami szkieletowymi) przez osoby lub grupy osób testujących niezależnych od zespołu projektowego (testy funkcjonalne - black box), dobierając dane w taki sposób, aby uwzględnić klasy równoważności
- poszczególne funkcje powinny być również przetestowane przez samych twórców na zasadzie white box, a dane powinny być tak dobrane, aby prześledzić wszystkie ścieżki sterowania
- wskazane jest użycie wszelkiego rodzaju narzędzi wspomagających testowanie, np. debuggerów czy analizatorów przykrycia kodu.
- projekty i prototypy powinny trafić do wybranej grupy potencjalnych użytkowników, których zadaniem będzie wypowiedzenie się na ich temat. Ta grupa musi się składać z osób należących do różnych grup klientów telefonii komórkowej. Dane powinny zostać zebrane w formie czytelnej i szczegółowej ankiety, która ujawni ich gusta. Wyniki te muszą zostać uwzględnione przy tworzeniu ostatecznej wersji interfejsu.
- każdy kolejny prototyp (ilekolwiek ich będzie) interfejsu musi być oceniony przez niezależną grupę testerów, kierownictwo niższego i wyższego szczebla, ...
- testy muszą uwzględniać wydajność i prędkość działania, prawidłowość reakcji na nieoczekiwane poczynania przyszłego użytkownika („idiotoodporność”)
7. Testownie ma na celu wykrycie i usunięcie błedów z Systemu oraz jest to ocena niezawodności
Sytstemu.
Aspekt systemu - własności operacyjne systemu.
Użyteczność:
Stopień skomplikowania róznych instrukcji skierowanych do systemu,jakość pomocy,jakość komunikatów, operacje wymagające zbyt wielu kroków, jakość informacji o błędach, jest to formalny przegląd oprogramowania w formie prezentacji wybranych funkcji produktu dla przyszłych potencjalnych klientów w celu uzyskania ich opinii o systemie.
Wymagania logistyczne i organizacyjne:
Użycie modelu czarnej skrzynki w celu znalezienia brakujących funkcji systemu oraz biała skrzynka w celu sprawdzenia wewnętrznej logiki programów.
8. Aspekt - system pomocy
Testy akceptacji
W procesie atestowanie wyznaczylbym betatesterow w ilosci 500 i kazal bez instrukcji obslugi sprobuwac obsluzyc telefon uzywajac jedynie systemu pomocy wbudowanego w telefon. Normalne jest ze z systemu w telefonie ni powinno sie uczyc poslugiwania nim ale przynajmniej zobaczylbym jak bardzo jest pomocny.
Aspekt - system zrzucania na bierzaco do pamieci „trwalej” wprowadzanych danych
Testy odporności
Czy po odlonczeniu zasilania w momencie grania w gre system w telefonie bedzie pamietal stan zdobytych punktow przez uzytkownika tak samo jesli chodzi o wpisywany wlasnie adres lub inne wprowadzane a nie zatwierdzone dane
Przeglądy oprogramowania:
1. Dla tego systemu powinno sie dokonywac przegladow
Powinien to byc przeglad techniczny poniewaz prace powinny isc zgodnie z planem (projekt jest priorytetowy) a takrze powinnne byc przeprowadzane audyty ktore dostarczaja odbiorcy i dostawcy obiektywnych i aktualnych informacji o stanie całego projektu
2. Nalezałoby co pewnien czas (np 5 razy w czasie trwania calego projektu) zrobic przeglad techniczny, aby nagle nie okazalo sie, ze nie wyrabiamy sie z planem.
We wczesnych fazach nalezałoby zrobic przejscie i ocenic efekt naszej pracy. Mialoby to na celu wczesne wykrycie ewentualnych błędów i wybranie sposobu na ich poprawienie gdy jeszcze nie jest za pozno.
Potrzebne bylyby przeglady nieformalne - spotkania z ewentualnymi przyszlymi wlascicielmai telefonu. Podczas takich spotkan moglibysmy sie dowiedziec np czy interface uzytkownika jest odpowiedni.
Na zakonczenie mozna zrobic audyt zewnetrzny w renomowanej firmie - po audycie bedzie wiadomo, czy z naszej strony wszystko jest zrobione jak najlepiej.
3. Oczywiście warto byłoby dokonywać przeglądu technicznego w celu zgodności postępu prac z przyjętym planem oraz założeniami organizacji danego systemu. Dodatkowo można byłoby stwierdzić czy jest to zgodne z wymaganiami użytkowników (wcześniej założonym planem). Innym przeglądem mogłobybyć tzw. Przejście. Tzn. Jego zadanie polegałoby na tym, że można byłoby znaleźć i rozwiązać problemy np. Interfejsu użytkownika, zidentyfikowanie defektów itd. i późniejsze rozważenie możliwych rozwiązań. Jak wiadomo, mimo iż system operacyjny telefonu komórkowego jest zdecydowanie mniejszy niż systemy operacyjnekomputerów, napewno nie sposób ustrzec się w nim błędów. Jeśli chodzi o audyt to raczej sprowadzałby się on do sprawdzenia poprawności wykonywanych prac i czy ich rezultaty odpowiadają zdefiowanym wcześniej wymaganiom.
3. Przegląd oprogramowania jest jak najbardziej niezbędny w naszym przypadku,
ponieważ jest to nowy system i wszwelkie wskazówki są jak najbardzeij wskazane. My jako twórcy tego oprogramowania znamy jego założenia i mamy co do nich pewne wizje, które nie zawsze muszą byc najlepsze. Dobrym sposobem takich przeglądów byłoby pokazywanie wytworzonych przez nas kawałków oprogramowania w formie programów do przeglądania na komputerach osobistych (nawet w formie aplikacji flash). Taka forma mogła by w łatwy sposób dotrzeć do dużego grona osób zainteresowanych. Mniejszymi przeglądami jakie powinniśmy przeprowadzać to przeglądy techniczne, które powinniśmy przedstawią kierownictwu projektu. Na bieżąco powinny być wykonywane przejścia, które powinny byc wykonywane dla grona specjalistów w celu oceny kodu i defektów w oprogramowaniu. Miało by to na celu poprawienie błędów i zapropponowanie dla nich rozwiązań. Już na samym końcu powinien być wykonany audyt całego systemu.
4. Oczywiście, że dla wyżej wymienionego systemu należałoby dokonywać przeglądów oprogramowania.
Po wytworzeniu systemu operacyjnego z funkcjami odpowiadającymi za komunikację (bez programów użytkowych, gier itd.) należałoby zrobić formalny przegląd w postaci przejścia.
Dla oprogramownia użytkowego także należałoby zrobić przegląd w formie przejścia i dodatkowo należałoby przetestować te elementy z użyciem przyszłych potencjalnych klientów w celu uzyskania komentarzy, opinni i akceptacji.
Należałoby także przeprowadzać formalny przegląd techniczny w celu zweryfikowania zgodności postepu prac z przyjętym planem oraz powinien być przeprowadzony audyt.
5. Warto robić przeglądy oprogramowania. NA pewno warto przeprowadzać przegląd techniczny w trakcie tworzenia systemu żeby można było sprawdzić czy prace idą zgodnie z planem. Oraz przeprowadzić audyt na koniec projektu, dobrze jest jak system będzie oceniony przez osoby które nie pisały go ponieważ mogą wykryć błędy których my byśmy nie wykryli oraz dają w miarę obiektywną ocenę napisanego systemu. Można też robić inspekcje w trakcie trwania projektu w celu uniknięcia błędów w tworzeniu oprogramowania.
6. Proponowałbym dokonywać 1 raz na miesiąc przegląd techniczny oceniający zgodność postępów prac z przyjętym planem.
Proponowałbym także raz na 2 tygodnie wykonywać przejścia, gdyż jest to nowy system i częsty „feedback” jest wysoce wskazany.
Przed przekazaniem systemu proponowałbym dokonanie audytu w ceu ostatecznego potwierdzenia zgodności projektu i dokuentacji z wymaganiami.
7. - przejście (walkthrough), aby wcześnie wykryć wszelkie nieprawidłowości proceduralne, stylistyczne, itp. i rozważyć możliwe rozwiązania
- audyt przeprowadzony przez niezależnych audytorów, celem sprawdzenia zgodności z założeniami, standardami, procedurami, instrukcjami, specyfikacją. Ma on dostarczyć obiektywnych danych o stanie całego projektu. Audyt powinien być ukierunkowany zarówno na procesy projektu informatycznego, jak i na jego cząstkowe produkty.
- inspekcja, mająca wykazać ewentualne błędy w procesie programowym oraz monitorująca na bieżąco stan realizacji projektu. Inspekcje mogą również zwiększyć motywację pracowników, na których świadomość, że ich praca będzie oceniana może działać pozytywnie. Ważne aby były one przeprowadzane w sposób fachowy, bezstronny i bez kładzenia nacisku na pracowników, a jedynie na efekty ich pracy.
8. W trakcie realizacji systemu można przeprowadzać przeglądy techniczne, które pozwolą uzyskać informacje o postępie prac, oraz ewentualnie korygować plan bądź zasoby przydzielone do wykonania poszczególnych etapów. Po wytworzeniu pierwszej w pełni funkcjonalnej wersji oprogramowania warto dokonać przejścia, dzięki czemu odkryte zostaną błędy w systemie, które można będzie poprawić przed wypuszczeniem finalnej wersji. Dokonanie audytu po usunięciu wszelkich usterek umożliwiłoby sprawdzenie systemu pod względem zgodności z normami, standardami (np. UMTS) co może okazać się przydatne z punktu widzenia marketingu - np. „Ten system jest zgodny z ... normą” oraz zapewni, że system będzie działał poprawnie w określonych warunkach oraz zgodnie ze standardami założonymi na początku projektu.
9. Moim zdanie przglady jest potrzebne szczegolnie po zaistalowanu systemu w telefonie
Trzeba by dokonac przegladu technicznego ktory oceni zgodnosc systemu z przyjetym planem, nastepnie wykonac przeglad w postaci Przejscia czyli wczesna ocena dokumetacji,modeli projektow oraz kodu oraz dokonywac za kazdym razem dokonywac Przejscia po zainstalowniu zainstalowaniu nowego oprogramowania w telefonie.
A na samym koncu mozna takze wykonac Audyt czyli przegladu potwierdzajacego zgodnosc oprogramowania z wymaganiami,specyfikacjami,zaleceniami,standardami,proceduram,instrukcjami,kontraktami
8. Dla wyżej wymienionego systemu nalaży dokonywać przegłądów.Dla programów użytkowych należało by zrobić przegłąd w formie postaci przejścia a także należy przetestować te elementy systemu z użyciem przyszłych potencjalnych klientów w celu uzyskania opinii, komentarzy systemie.Natomiast dla systemów nie będącymi programami użytkowymi,itd.należy zarobić także przegląd w formie postaci przejścia.(funkcję odpowiadające z komunikacje).Należy także przeprowadzać formalny przegląd techniczny w celu zweryfikowania zgodności postepu prac z przyjętym planem oraz powinien być przeprowadzony audyt(Przeglądy potwierdzające zgodność oprogramowania z wymaganiami, specyfikacjami, zaleceniami, standardami, procedurami, instrukcjami, kontraktami i licencjami. Obiektywność audytu wymaga, aby był on przeprowadzony przez osoby niezależne od zespołu projektowego).
9. Określenie fragmentów systemu o szczególnych wymaganiach wobec niezawodności Powinny bys wykonane: Przegląd techniczny, aby ocenic czy orpogramowanie zostalo wykonene i zgadza sie z planami. Przejście - zeby sprawdzic defekty i moc im czesniej zaradzic. Potem poniewaz jest to tlefon powinnien byc przeglad juz w rekach potencjalnych uzytkownikow czyli beta testerow i tak powinni zrobic przeglad: niezawodnosci systemu w skrajnych przypadkach jak po przytrzymaniu klawisza przez bardzo dlugi kres, uzywanie nie wyznaczonych klawiszy w roznych aplikacjach.
10. Dla wiekszych systemow przegloądów warto uzywać przegladow.
Nieformalny przeglad techniczny.
Nieformalne (kolezenskie) przeglady kodu poprzez tworzenie zspolow, ktore wzajemnie robia sobie przeglady moze znacznie zwiekszyc wydajnosc zespolu oraz podniesc jakosc kodu.
Przejscie.
Warto stosować przeglady zwane przjsciami.
Aby odpowiednio wczesnie znalezc i zidentyfikować problem nalezy posluzyc sie przejsciem dla oceny dokumentow, projektow i kodu. Mozna dzieki przejsciom nie tylko znalezc defekty, ale takze polepszyc wiedze zespolu w zakresie rozwiazywania niektorych rodzajow problemow.
Audyt.
Przed wdrozeniem systemu warto (jesli budzet produkcji systemu na to pozwala) wykonac audyt systemu. Pozwoli to uzyskac dobre atuty w negocjacjach z klientam na wypadek niepowodzen podczas wdrozenia. Przez wykonanie audytu niejako zrzuca się część odpowedzialności na audytora, ktory najczesciej jest powszechnie uwazana instytucja. Audyt z pozytywnym wynikiem moze tez przyczynic sie do sukcesu rynkowego produktu - jelsi potencjalni klienci przykladaja duza wage do ekspertyz i zalecen firm audytorskich.