Testowanie - podstawy koncepcyjne

July 27, 2023

Pewnie nieraz spotkaliście się z określeniem „jak chcesz wejść do branży IT, to zacznij od bycia testerem”. O ooo .. Już niektórym robi się gorąco 😉 O co chodzi w tym całym „testowaniu” i byciu testerem czy QA? Bo rzecz nie jest tylko o przeklikiwaniu i wykrywaniu błędów, ale, a w zasadzie przede wszystkim, o zapewnieniu jakości oprogramowania. Dziś chcielibyśmy prześwietlić istotę testowania i bycia testerem, QA’em, przyjrzeć się jak podejmuje się decyzje w tych procesach, na co obecnie trzeba położyć nacisk by testować efektywnie. Zerkniemy na ten temat trochę z lotu ptaka i trochę subiektywnie rzecz jasna 😉 - Okiem JellyTech.

^{Słowem wstępu. Często używamy tutaj słowa tester jako określenie osoby, która testuje, choć wiemy, że testy i ich planowanie mogą przeprowadzać różne osoby. Czasem na potrzeby artykułu używamy też skrótów myślowych i upraszczamy opis. Temat oczywiście jest złożony i z pewnością można wskazać wyjątki od przykładów, które podajemy 😉}

‍

Kompetencje i doświadczenie

‍

Jakie kompetencje i doświadczenie będzie mile widziane w zespole testerskim i/lub u osoby, która odpowiada za testy i testuje? Oczywiście w zależności od funkcji i metodologii zarządzania w której pracuje, naszym zdaniem są to:

- umiejętność planowania (czasem testy planuje tester czasem lider testów czy kierowniku projektu)

- umiejętność dostosowania zakresu i typów testów jakie trzeba i/lub, które warto wykonać -> do celu zdefiniowanego przez Klienta oraz do wymagań funkcjonalnych i niefunkcjonalnych zdefiniowanych przez analityków,

- napisanie Use Case’ów w oparciu o warunki brzegowe -> aby sam proces testowy był efektywny i nie narażał budżetu projektu na zbytnie nadwyrężenie, jednocześnie zapewniając, że cel jaki przyświecał Klientowi, zostanie spełniony.

‍

‍

Planowanie, wykonanie i analiza

‍

Planowanie to tak naprawdę kluczowy element całego procesu wytwarzania oprogramowania. Odpowiednio położony nacisk w określonych obszarach realizacji projektu, daje gwarancję realizacji celów w czasie i w określonym budżecie. Jak wygląda planowanie w samym testowaniu?

1) Analiza wymagań i projektowanie

- analiza wymagań - analiza specyfikacji i wymagań dotyczące oprogramowania, aby zrozumieć, jak powinno ono działać (jeśli tester jest częścią zespołu developerskiego, jest względnie na bieżąco),

- projektowanie testów - na podstawie wymagań i ustaleń, testerzy lub osoby za to odpowiedzialne projektują zestaw przypadków testowych, które obejmują warunki graniczne, różne scenariusze i kombinacje danych wejściowych.

2) Wykonanie testów. Tester/QA/osoba wskazana wykonuje zaprojektowane przypadki testowe.

3) Analiza wyników i ewentualne retestowanie

- testerzy przekazują feedback do zespołu o znalezionych błędach (czyt. szeroko jako funkcjonalności niezgodne z wymaganiami). Testerzy mogą też przeprowadzić ocenę błędów, co może przybliżyć zespół developerski do ich szybszej poprawy i podjęciu dalszych decyzji o przeprowadzeniu retestów (czyli ponownego testowania w celu sprawdzenia, czy błędy zostały poprawione).

Ok, mamy zaplanowany cały proces. Dzięki pogłębionej pracy na etapie analizy wymagań i projektowania, ale także na etapie retestów, osoba wykonująca testy będzie umiała podjąć decyzje jakie testy użyć na wybranym etapie projektu. A ma z czego wybierać 😉Czas odwołać się do doświadczenia i typologii testów.

‍

Rodzaje i typy testów

Możemy roboczo podzielić testy:

- ze względu na sposób realizacji: testy manualne, automatyczne, kombinacja obu,

- pod względem celu doboru właściwych metod testowania (typy wg. ISTQB): funkcjonalne, testowanie charakterystyk niefunkcjonalnych jakości, takich jak wyjdaność lub niezawodność, testowanie struktury lub architektury oprogramowania lub systemu, lub testowanie powiązane ze zmianami, np. potwierdzenie, że defekt został naprawiony (testy potwierdzające) i szukanie niepożądanych skutków zmian (testy regresji).

*należy bez dwóch zdań dodać gwiazdkę, gdyż podział testów jest naprawdę bardzo szeroki i powyższy podział nie wyczerpuje tematu, niemniej na potrzeby tego artykułu skupiamy się tylko na tych dwóch poziomach

Testy manualne i automatyczne

W kwestii sposobu realizacji testów sprawa wydaje się być prosta. Testy można wykonać bowiem ręcznie, tj. manualnie, przeklikujące dane funkcjonalności i sprawdzając systemy lub napisać/wykorzystać skrypt testowy i użyć go w testach automatycznych. Najczęściej spotykane rozwiązanie to kombinacja obu tych technik. Zalety testowania manualnego to przede wszystkim intuicyjne podejście, elastyczność, ocena aspektów związanych z UX. Niemniej jest to metoda czasochłonna i podatna na ludzkie błędy. Nie sposób sobie wyobrazić (choć nie mam pewności, patrząc na kreatywność ludzką 😊), że testujemy wielopłaszczyznową aplikację ręcznie… Po pierwsze czas, po drugie pieniądze… Przypomnijmy jeszcze - podstawową testowania jest założenie, że może ono ujawniać usterki, ale nie może dowieść ich braku.

‍

Są typy testów które należy automatyzować jak chociażby unit testy (niezbędne do wdrożenia procesu CI/CD), ale ich celem nie jest potwierdzenie działania funkcjonalności, celem jest natomiast potwierdzenie, że zmiany wykonane w kodzie przez developera nie zepsuły już obecnie działających funkcjonalności. Manualna odsłona pozwala na utrzymanie tak ważnej interakcji między człowiekiem, a oprogramowaniem. Naszym zdaniem testerzy manualni mogą spać spokojnie - są i będą potrzebni.

Wiele firm decyduje się zatem na kombinacje testowania manualnego i automatyczne. Automatyzacja testów może bowiem cały proces przyspieszyć.

Zastanawialiśmy jak testować, teraz odpowiedzmy na pytanie co testy mają dać, czyli jaki ma być ich cel?

W ustrukturyzowaniu wiedzy pomoże nam podział na typy testowania.

Typy testów:

1) Testowanie funkcjonalne:

Testy czarnej skrzynki - polegają na testowaniu funkcjonalności systemu bez wiedzy na temat wewnętrznej struktury kodu. Nasza analiza zatrzymuje się więc na dostępnych dla oprogramowania interfejsach.

2) Testowanie niefunkcjonalne np.:

wydajnościowe - polega na testowaniu wydajności systemu pod kątem czasu odpowiedzi, obciążenia, skalowalności i zużycia zasobów.
niezawodności - obejmuje testowanie systemu pod kątem odporności na awarie, utratę danych i możliwości ich szybkiego odzyskiwania.

3) Testowanie bezpieczeństwa - w ramach tego testowania dokonywana jest ocena podatności systemu na zagrożenia. Podczas testowania można sprawdzić czy możliwe jest np. kopiowanie aplikacji lub danych bez upoważnienia czy nieautoryzowany dostęp do naszego systemu.

4) Testowanie strukturalne (biała skrzynka) - mogą być wykonane na wszystkich poziomach testowych. Technik strukturalnych używa się w celu wsparcia pomiarów dokładności testowania poprzez ocenę pokrycia danego typu struktury.

5) Testowanie regresji - ma na celu sprawdzenie, czy wprowadzenie zmian w oprogramowaniu nie spowodowało regresji, czyli nie spowodowało błędów w już wcześniej przetestowanej funkcjonalności.

6) Testowanie integracyjne - ma na celu sprawdzenie, czy poszczególne komponenty oprogramowania współpracują ze sobą poprawnie, gdy są integrowane w większą całość.

7) Testowanie akceptacyjne lub odbioru - mogą być wykonywane także przez klienta. Testowanie akceptacyjne jest przeprowadzane w celu oceny, czy oprogramowanie spełnia wymagania klienta i jest gotowe do przyjęcia przez użytkowników końcowych.

8 ) Inne - zależne od: narracji, szkoły testerskiej, doświadczenia, fantazji testera, QA 🙂

Testujemy

To co przetestujemy coś razem? 😎

Aplikacja do sprzedaży jabłek. A co - sezon za chwilę 😁 Niestety nie posiadamy takiej aplikacji w portfolio, ale jeśli czyta to jakiś sadownik - zapraszamy do kontaktu 🙂

‍

Dane aplikacji:
🍎 aplikacja do sprzedaży jabłek (dostępna zarówno webowo jak i mobilnie)
🍏 użytkownicy: kupujący i sprzedający (osoby prowadzące sprzedaż owoców, sadownicy, skupy)

‍

Podstawowe funkcjonalności i systemy, które powinny być gotowe na tym początkowym etapie projektu to:
✔ rejestracja na stronie (imię, nazwisko, adres email)
✔ logowanie i wylogowanie
✔ weryfikacja linku aktywacyjnego

Aplikacja będzie jeszcze udoskonalana, ale na tym etapie potrzebujemy sprawdzić ten wycinek - skupiony jak widzicie, głównie na obszarach UX/UI. Co byście przetestowali?

Zrobimy na początek testy funkcjonalne i sprawdzimy czy:
✔ okienko w formularzu przyjmuje liczby i litery i czy użyty regex działa. W polu imię i nazwisko będziemy mogli zatem wpisać tylko litery (małe i duże, w polu email litery i cyfry. Sprawdzimy też czy aplikacja w polu email przyjmie email bez kropki i @
✔sprawdzamy czy udaje nam się na stronie zarejestrować, zalogować i wylogować
✔sprawdzamy czy przychodzi do Nas link aktywacyjny, czy przekierowuje nas na stronę aplikacji i czy udaje się potwierdzić tożsamość

Następnie zrobilibyśmy podstawowe testy bezpieczeństwa (aplikacja będzie przetwarzać dane, musimy mieć pewność, że nigdzie się one nie wydostaną). Sprawdzamy np.:
✔ czy aplikacja korzysta z nagłówków bezpieczeństwa takich jak m.in:
Strict-Transport-Security, X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection,
mechanizmy utrudniające ataki typu brute-force.

✔Testując formularze logowania, zwracamy uwagę, jak zachowuje się aplikacja po wielokrotnym wprowadzeniu nieprawidłowych danych. Dobrze zaprojektowana aplikacja nie pozwoli na przeprowadzenie zmasowanego ataku w celu odgadnięcia hasła.

‍

‍

Jak widać na przykładzie aplikacji do sprzedaży jabłek, typów testów jest wiele, natomiast nie wszystkie użyjemy naraz.

Podsumowanie

Temat testowania i bycia tester czy QA jest naprawdę złożony. Staraliśmy się nakreślić Wam podstawowe aspekty tej pracy i dziedziny. Dużo w pracy osób odpowiedzialnych za testy to planowanie. Na podstawie ich sugestii i raportów, mogą zadziać się w aplikacji ważne zmiany, jeśli wykryto by je później, mogłyby przynieść zespołowi i klientowi duże straty. Tester musi chcieć zrozumieć ważne dla klienta aspekty funkcjonowania jego produktów. Dobrze by było, aby taka osoba starała się być na bieżąco, śledziła trendy świata testów i QA.

Mamy świadomość, że testowanie może być jak góra lodowa😉 Na pierwszy rzut oko widać tylko jego fragment, a jak się zanurzysz to dopiero widzisz ogrom założeń i wytycznych. Nie damy się jednak zatopić 😁W kolejnych artykułach pochylimy się nad konkretnymi typami testów, ich wykorzystaniem i dalszą analizą specyfiki testowania oprogramowania.

Koniecznie śledźcie zatem naszego bloga 😉

‍

‍

Galeria zdjęć

No items found.

Wideo

Back to previous site

Testing - conceptual foundations

Magdalena Piątkowska

July 27, 2023

You've probably heard the phrase "if you want to enter the IT industry, start by being a tester". Oh ooo .. Some people are already getting hot 😉 What is this whole "testing" and being a tester or QA thing? Because the thing is not only about clicking through and detecting errors, but, and basically above all, about ensuring the quality of the software. Today, we would like to explore the essence of testing and being a tester, QA, and look at how decisions are made in these processes, which currently needs to be emphasized in order to test effectively. We'll take a look at it a bit from the bird's eye view and a bit subjectively, of course 😉 - Through the eye of JellyTech.

_{A word of introduction. We often use the word tester here to describe the person who tests, although we know that tests and their planning can be carried out by different people. Sometimes, for the purposes of the article, we also use mental abbreviations and simplify the description. The topic is, of course, complex and exceptions can certainly be made to the examples we give 😉}

‍

Competence and experience

What competences and experience would be welcome in a testing team and/or in a person who is responsible for testing and testing? Obviously depending on the function and the management methodology in which he/she works. In our opinion, these are:

‍
- the ability to plan (sometimes tests are planned by the tester sometimes by the test leader or project manager)

‍
- the ability to match the scope and types of tests that need to be done and/or that are worth doing -> to the objective defined by the customer and to the functional and non-functional requirements defined by the analysts,

- writing Use Cases based on boundary conditions -> so that the testing process itself is efficient and does not put the project budget under too much strain, while ensuring that the client's objective is met.

Let's look at these points in more detail.

‍

Planning

‍

A key element really of the entire software development process. Adequate emphasis in specific areas of project execution ensures that goals are achieved on time and within budget. What does planning look like in testing itself?

1) Requirements analysis and design
- Requirements analysis - analysing the specifications and requirements for the software to understand how it should work (if the tester is part of the development team, they are relatively up to date),
- test design - based on the requirements and findings, testers or those responsible design a set of test cases that include boundary conditions, different scenarios and combinations of inputs.

2) Test execution. The tester/QA/designated person executes the designed test cases.

3) Analysis of results and possible retesting
- Testers provide feedback to the team on bugs found (read broadly as functionality not meeting requirements). The testers can also perform a bug assessment, which can bring the development team closer to correcting the bugs faster and making further decisions about retesting (i.e. re-testing to see if the bugs have been corrected).

Ok, we have the whole process planned out. Thanks to the in-depth work at the requirements analysis and design stage, but also at the retest stage, the test developer will know how to decide which tests to use at the chosen stage of the project. And he has a lot to choose from 😉 It is time to refer to experience and test typologies.

‍

Types and kinds of tests

‍
We can workfully divide tests:
- in terms of the method of execution: manual tests, automated tests, a combination of both,
- in terms of the purpose of selecting appropriate testing methods (types according to ISTQB): functional, testing of non-functional quality characteristics, such as output or reliability, testing the structure or architecture of the software or system, or testing related to changes, e.g. confirming that a defect has been fixed (confirmation tests) and looking for undesired effects of changes (regression tests).
The *significant asterisk should be added, because the division of tests is really very broad and the above division is not exhaustive, but for the purpose of this article we focus only on these two levels

Manual and automatic tests

When it comes to how tests are implemented, the matter seems to be simple. Tests can be performed manually, i.e. manually, crossing given functionalities and checking systems, or a test script can be written/used and used in automatic tests. The most common solution is a combination of both techniques. The advantages of manual testing are mainly the intuitive approach, flexibility, assessment of UX aspects. Nevertheless, it is a time-consuming method and prone to human error. It is impossible to imagine (although I am not sure, looking at human creativity 😊) that we test a multifaceted application manually... Firstly time, secondly money... Let's remind again - the basic assumption of testing is that it can reveal faults, but cannot prove their absence.

‍

There are types of tests that need to be automated, such as unit tests (necessary for the implementation of the CI/CD process), but their purpose is not to confirm that functionality works, the purpose is instead to confirm that the changes made to the code by the developer have not broken the functionality already in place. Manual review allows such an important interaction between humans and software to be maintained. In our opinion, manual testers can rest assured - they are and will be needed.

Many companies are therefore opting for a combination of manual and automated testing. This is because test automation can speed up the whole process.

We have discussed how to test, now let us answer the question of what the tests are supposed to do, i.e. what is their purpose?

A division into testing types will help us to structure our knowledge.

‍

Testing types

‍

1) Functional testing:
Black box testing - involves testing the functionality of the system without knowledge of the internal structure of the code. Our analysis therefore stops at the interfaces available to the software.

2) Non-functional testing e.g:

- performance - involves testing system performance in terms of response time, load, scalability and resource consumption.
- reliability - involves testing the system for robustness to failures, data loss and the ability to recover quickly.

3) Security testing - this testing assesses the vulnerability of the system. During testing, it is possible to check whether it is possible, for example, to copy applications or data without authorisation or to gain unauthorised access to our system.

4) Structural testing (white box) - can be performed at all test levels. Structural techniques are used to support the measurement of testing accuracy by assessing the coverage of a given type of structure.

5) Regression testing - aims to check that the introduction of changes to the software has not caused regression, i.e. has not caused errors in the functionality already tested.

6) Integration testing - aims to check that individual software components work together correctly when integrated into a larger whole.

7) Acceptance or acceptance testing - can also be performed by the customer. Acceptance testing is carried out to assess whether the software meets the customer's requirements and is ready for adoption by end users.

8 ) Other - dependent on: narrative, testing school, experience, tester's imagination, QA 🙂

‍

Let's test something

So what shall we test together? 😎

An app to sell apples. Yes - the season is about to start 😁 Unfortunately we don't have such an app in our portfolio, but if any fruit growers are reading this - feel free to contact us 🙂

‍

Application details:
🍏app for apple sales (available both web and mobile)
🍎users: buyers and sellers (fruit sellers, fruit growers, buyers)

‍

The basic functionalities and systems that should be ready at this initial stage of the project are:
✔ website registration (name, surname, email address)
✔ log-in and log-out
✔ verification of the activation link

‍

The application will still be refined, but at this stage we need to test this section - focused, as you can see, mainly on UX/UI areas. What would you test?

‍

We will do functional tests to start with and check that:
✔the form box accepts numbers and letters and that the regex used works. So in the name field we will only be able to enter letters (upper and lower case, in the email field letters and numbers. We will also check that the application in the email field will accept email without a dot and @
✔we check if we manage to register on the site, log in and log out
✔we check if the activation link comes to us, if it redirects us to the application site and if we manage to confirm our identity

‍

We would then do some basic security tests (the app will process data, we need to make sure it doesn't get out anywhere).

‍
✔We check, for example:whether the application uses security headers such as: Strict-Transport-Security, X-Frame-Options, Content-Security-Policy, X-Content-Type-Options, Referrer-Policy, Permissions-Policy, X-XSS-Protection, mechanisms to make brute-force attacks more difficult.

✔When testing login forms, we pay attention to how the application behaves after repeatedly entering incorrect data. A well-designed application will not allow a massive attack to be launched to guess the password.

‍

As you can see from the apple sales application, there are many types of tests, whereas we will not use all of them at the same time.

Summary

The topic of testing and being a tester or QA is really complex. We have tried to outline for you the basic aspects of this job and field. A lot of the work of testers is planning. Based on their suggestions and reports, important changes can happen in the application, if detected later, they could bring big losses to the team and the customer. The tester must want to understand the important aspects of the client's products. It would be good for such a person to try to keep up to date, to follow the trends of the testing and QA world.

We are aware that testing can be like an iceberg😉 At first glance you only see a fragment of it, and when you dive in you only see the enormity of the assumptions and guidelines. However, we won't let it sink in 😁In future articles we will lean into specific types of testing, their use and further analyse the specifics of software testing.

So be sure to follow our blog 😉

‍

‍

Gallery

No items found.

Testowanie - podstawy koncepcyjne

Kompetencje i doświadczenie

‍

Planowanie, wykonanie i analiza

‍

Rodzaje i typy testów

Testy manualne i automatyczne

Typy testów:

Testujemy

Podsumowanie

Galeria zdjęć

Wideo

Testing - conceptual foundations

Competence and experience

Planning

‍

Types and kinds of tests

Manual and automatic tests

Testing types

‍ Let's test something

Summary

Gallery

Wideo

‍

Let's test something