Dlaczego nie piszemy wymagań i testów w Wordzie (albo jakimś typowym edytorze tekstu)?

Zarządzanie wymaganiami i przypadkami testowymi zapisanymi w zwykłym pliku tekstowym jest bardzo trudne (wolałabym napisać niemożliwe, ale dla ludzi upartych i zdeterminowanych nie istnieją niemożliwe zadania).

Warto mieć powiązania między wymaganiami, testami, planami i wykonaniami testów, ponieważ:

• łatwiej jest wszystko edytować w przypadku zmian
• łatwiej zauważyć błędy i braki w dokumentacji
• łatwiej przygotować podsumowanie, zobaczyć jak długo znajmuje testowanie, które testy są dla aplikacji problemowe.

Mineło dużo czasu odkąd ostatnio sensownie pracowałam nad testami i wymaganiami. Żałuję - to ważna praca, którą najchętniej odkłada się na kiedyś, a bywa, że "kiedyś" jednak nie nadchodzi. 

Teraz chciałam, żeby dokumentacja była ładna - byłam zachwycona całą ideą identyfikacji wizualnej marki, tak dużo radości dawało mi robienie rzeczy ładych, że dostały zbyt wysoki priorytet i dokumentacj powstała w Wordzie.

Na szczęście projekty są jeszcze małe, mają niewiele funkcji.

Chciałabym, żeby zdumiewały - i projekty, i wszystko co jest obok - dokumentacja też, więc jest ładna. Niemniej zaczęłam poszukiwania odpowiedniego dla mnie teraz narzędzia do zarządzania testaliami.

Czego nauczył mnie kompilator cz.1

1. Gdy łączę tekst w pętli (np. z listy z bazy danych) to zamiast String (+) stosować StringBuilder (.append)
2. Mogę zwrócić w funkcji wartość pętli if - nie muszę tam zapisywać true i false.

Dobre praktyki - Lekcja 2

1. Commituj gdy kończysz pracę w danym momencie (nawet w wyniku przerwania).
2. Weryfikuj wywołania funkcji - czy na pewno tylko raz (rozsądne logi).
3. Porównuj Stringi przez .equals() a nie przez "=="

Jak zrobić aplikację bez górnego paska tytułowego?

W głównym stylu aplikacji należy dodać:

        <item name="windowNoTitle">true</item>
        <item name="windowActionBar">false</item>


Plik styles.xml może wtedy wyglądać tak:

<resources>

    <!-- Base application theme. -->
    <style name="AppTheme" parent="Theme.AppCompat.Light.DarkActionBar">
        <!-- Customize your theme here. -->
        <item name="colorPrimary">@color/colorPrimary</item>
        <item name="colorPrimaryDark">@color/colorPrimaryDark</item>
        <item name="colorAccent">@color/colorAccent</item>
        <item name="android:fontFamily">@font/italianno</item>
        <item name="android:textColor">@color/black</item>
        <item name="windowNoTitle">true</item>
        <item name="windowActionBar">false</item>
    </style>

</resources>

Szablon Planu Jakości

Kilka lat temu uczestniczyłam w szkoleniu ISTQB. Uważam, że prezentowana tam wiedza, schematy i procesy są bardzo sensowne - dlatego, że moja mentorka od początku mojej proacy pokazywała mi jak z nich korzystać.

Poniżej znajduje się schemat Planu Testów - my nazwaliśmy go Planem Jakości Projektu. Dopracowaliśmy go, zautomatyzowaliśmy wypełnianie go w naszym systemie Redmine i wielokrotnie szkoliliśmy nasz zespół w sposobie jego wypełniania. Dlaczego wielokrotnie? Plan jest długi i podczas jego wypełniania trzeba przemyśleć wiele aspektów jakości projektu (a nie każdy chce i potrafi to zrobić).
Przemyśleć, sprawdzić, ustalić - to najważniejszy cel wypełniania Planu Jakości.
Manifest Agile (który bardzo cenię) stawia dokumentację i przestrzeganie planu na drugim miejscu - zgadzam się z tym całkowicie - nie wypełniajmy planu dla smego wypełniania i generowania niepotrzebnej dokumentacji. Wypełniamy tyle, ile trzeba, a myślimy o wszystkim bo od nas zależy Jakość w projekcie.

1. Identyfikator
2. Wstęp
1. autoryzacja projektu
2. plan projektu
3. plan QA
4. plan zarządzania konfiguracją
5. polityka testów
6. standardy testów
3. Przedmiot testów
1. specyfikacja wymagań
2. specyfikacja projektowania
3. instrukcja obsługi/instalacji/funkcji
4. Testowane funkcje
5. Nietestowane funkcje
6. Podejście do testów
7. Kryteria przejścia/niezaliczenia testów
8. Kryteria zawieszenia/wznowienia testów
9. Rezultaty testów
1. plan testów
2. specyfikacja projektów testowych
3. specyfikacja przypadków testowych
4. przekazanie przedmiotu testów
5. logi z testów
6. raport incydentu testowego
7. podsumowanie raportu testów
10. Testowane zadania
11. Niezbędne środowisko testowe
12. Odpowiedzialność
13. Zapotrzebowanie na personel i szkolenia
14. Harmonogram
15. Ryzyka i nieprzewidziane wydatki
16. Pozwolenia/zatwierdzenia

Screen size - czyli jaki rozmiar powinna mieć grafika tła

Przygotowałam moją Bardzo Ważną Aplikację.
Pracowałam nad nią długo, nadszedł dzień premiery i... nie dało się jej otworzyć na niektórych urządzeniach.
Okazało się, że dodane przeze mnie grafiki były za duże - urządzenia nie radziły sobie z ich dopasowaniem.

Podstawa, tak, jednak jakoś przeoczyłam.

Poczytałam trochę, między innymi:
https://vinsol.com/blog/2014/11/20/tips-for-designers-from-a-developer/
https://blog.prototypr.io/designing-for-multiple-screen-densities-on-android-5fba8afe7ead
https://medium.com/@sashaserg/a-mysterious-density-independent-pixel-a-quick-introduction-to-android-design-111d68be7cf5

I od tamtej pory wielkość grafik tła w moich projektach to około:

• mdpi - 360x480 px
• hdpi - 480x800 px
• xhdpi - 720x1280 px
• xxhdpi - 1080x1920 px
• xxxhdpi - 1440x2560 px

Zazwyczaj nie mam odzielnych plików dla każdej wielkości ekranu - mam tylko jeden i dodaję go do katalogu, do którego najbardziej pasuje.

Staram się mimo wszystko nie mieć za dużych plików - to zazwyczaj one zwiększają rozmiar aplikacji, więc jeśli grafika nie jest najważniejszym elementem, dbam o oszczędność pamięci użytkownika

Dobre praktyki - Lekcja 1

1. Testuj małe elementy - im mniej, tym lepiej, nawet jeśli to tylko zmiana koloru - upewnij się, że się zmienił tam gdzie powinien.
2. Testuj małe elementy - nawet jeśli nie powodują widocznej zmiany wyglądu lub zachowania - sprawdzaj, czy nic nie popsuły.
3. Czytaj materiały branżowe regularnie - warto się uczyć od innych.
4. Porządnie planuj - najpierw zgrubnie, później coraz dokładniej, im mniejsze zadania tym łatwiej je wykonać nawet przy zmęczeniu.
5. Usuwaj logi, których nie potrzebujesz.
6. Upewnij się, że element, którego używasz !=null