Skip to main content

Types of tests [DSP2017 #04]

As a java developer with more than 3 years of experience I had opportunity of participating in few projects. To be honest only in a last one a testing strategy is on high level.  I encourage you for introduce and put more pressure on testing strategy during a delivery process. As with all new things the beginnings are difficult but I'm sure that it is worth.

As almost testers know undermentioned pyramid I need to put it for people who have not seen it.

In a big amount of projects we can meet this pyramid in inverted order. What can impact of quality of a system. For example when we have a lot of manual tests it is boring for users and sometimes they can be skipped what can missed bug.

So in the lowest level we see the Unit tests and the count of this should be the bigger and on the highest level, there are manual tests. As we can expect the count should of them should be the lowest.

A few words about each of them:
  • Unit tests - should be quick and small. They check just one method or part of code.
  • Component tests - should test one module/component/functionality of your project and not depend from other modules.
  • Integration tests - should test a connectivity between components, modules, databases etc.
  • E2E (End to End) tests - should test the all flow from beginning to the end of process.
  • Manual tests - tests which are impossible to automate.


Comments

  1. Beautiful theory :: cruel world ;) Did you ever worked with system, where were a lot of automated tests and only few scenarios were tested manually? ;) Best begards (from tester;))

    ReplyDelete
    Replies
    1. Thanks for your comment. Yes now we work on this kind of system where we try to automate each new manual test :) I will continue this topic in next posts.

      Delete

Post a Comment

Popular posts from this blog

Nany - opis projektu [DSP2017 #03]

" Nany " Wymagania: Użytkownik może podłączyć/odłączyć się do detektora wysyłającego powiadomienia. Użytkownik musi zostać poinformowany o dochodzącym dźwięku z pokoju dziecka. Powiadomienia powinny zostać wysłane do wszystkich zarejestrowanych urządzeń. Użytkownik musi zareagować na powiadomienie. Schemat:   Pierwszy etap prac (13.03.2017): [Telefon*] Prosta aplikacja android umożliwiająca odbieranie powiadomień. [Detektor*] Obsługa detekcji dźwięku. *Telefon - urządzenie z systemem android. *Detektor - Raspberry Pi B  wraz z mikrofonem.

Do odważnych świat należy [DSP2017 #01]

Witam wszystkich uczestników ;) Od jakiegoś czasu chodziło mi po głowie założenie bloga niestety nie miałem do tego wystarczającej motywacji. Wtedy wpadł mi w ręce artykuł zachęcający do wzięcia udziału w DSP 2017. Myślę, że jest to fantastyczna okazja na powstanie (od dawna planowanego) projektu oraz spróbowania własnych sił w tworzeniu bloga :) Projekt "Nany" Celem projektu jest stworzenie aplikacji zbierającej dźwięk z pokoju dziecka. W momencie wykrycia dźwięku system powinien informować rodziców o zaistniałej sytuacji. Projekt prowadzony będzie w metodologii Agile, a o wszystkich rezultatach oraz zmianach będę informował na blogu. Technologie: Python – aplikacja do zbierania dźwięku i wysyłania sygnału do serwera, Java – implementacja serwera aplikacji.