Differences

This shows you the differences between two versions of the page.

--- report:dvp [2026/05/27 21:54] – [7.8.4 Tests & Results] team1
+++ report:dvp [2026/06/03 16:00] (current) – [7.8.2 Hardware] team1
@@ Line 32: / Line 32: @@
 <WRAP centeralign>
 <figure fig:sketch_brainstorm_1>
-{{ :report:img_419711.png?300x300 |Sketch brainstorm 1}}
+{{ :report:sketch_brainstorm1.png?300x300 |Sketch brainstorm 1}}
-<caption>Sketch brainstorm 1 <color #ed1c24>(Rotate image and replace it)</color></caption>
+<caption>Sketch brainstorm 1</caption>
 </figure>
 </WRAP>
@@ Line 284: / Line 284: @@
 <WRAP centeralign>
 <figure fig:detailed_packaging_solution>
-{{ :report:packaging_solution_detailed_.jpg?700 |Detailed packaging solution}}
+{{ :report:screen2green_packaging_detailed_.png?700 |Detailed packaging solution}}
 <caption>Detailed packaging solution</caption>
 </figure>
@@ Line 297: / Line 297: @@
 <WRAP centeralign>
 <figure fig:final_packaging_solution>
-{{ :report:packaging_solution.jpg?500 |Final packaging solution}}
+{{ :report:screen2green_packaging_final.png?500 |Final packaging solution}}
 <caption>Final packaging solution</caption>
 </figure>
@@ Line 316: / Line 316: @@
 Figure {{ref>fig:blackbox_diagram}} presents a block diagram for Screen2Green pot. At the core is an ESP32 board that is working as "brain" of the whole system connecting it with sensors and watering system. Soil moisture sensor gives information through the microcontroller when opening the valve is needed. Additional sensors like temperature one are appearing on the screen of the app user.
 <WRAP centeralign>
 <figure fig:blackbox_diagram>
-{{ :report:blackbox_diagram.jpg?600 |Blackbox diagram}}
+{{ :report:blackbox_diagram_updated.jpg?nolink&600 | |Blackbox diagram}}
 <caption>Blackbox diagram</caption>
 </figure>
@@ Line 549: / Line 550: @@
 == 7.8.4.1 Hardware tests ==
-The first assembly of electrical circuit with solenoid valve on breadboard is presented in Figure {{ref>c1m}}.
+The first assembly of electrical circuit with solenoid valve on breadboard is presented in Figure {{ref>fig:c1m}}.
 <WRAP centeralign>
@@ Line 558: / Line 559: @@
 </WRAP>
+The circuit begins as introduced on electrical schematic with 12 V power supply with Female DC adapter connected with yellow (ground) and red (plus) wires visible in Figure {{ref>fig:powerbuck}}. The red wire is connected to switch and later to input in step-down converter used to drop voltage from 12 V to 5 V.
+<WRAP centeralign>
+<figure fig:powerbuck>
+{{ :report:powersupplybuckconverter.jpeg?600 |powerbuck}}
+<caption>Power supply with step-down converter and switch.</caption>
+</figure>
+</WRAP>
+Next the relay module needed to operated with solenoid valve giving the information from ESP32 board, when to open and when to close the valve is visible in Figure {{ref>fig:relay}}. Input of step-down converter is connected using blue wire with OM channel of relay module. The red wire is connected to blue relay module normally open channel by red wire. The black wire of the solenoid valve is connected to ground.
+<WRAP centeralign>
+<figure fig:relay>
+{{ :report:relay.jpeg?600 |relay}}
+<caption>Relay module connected to step-down and to the solenoid valve.</caption>
+</figure>
+</WRAP>
+Second part of the relay module presented in Figure {{ref>fig:esprelay}} used green wire to communicate with ESP32 and receive the information about action related to solenoid valve, black wire is connected to the GND and orange one of VCC is connected to 5 V power supply located on ESP32.
+<WRAP centeralign>
+<figure fig:esprelay>
+{{ :report:esprelay.jpeg?600 |esprelay}}
+<caption>Second part of relay module connected to ESP32 board.</caption>
+</figure>
+</WRAP>
 == 7.8.4.2 Software tests ==
+The application has been tested on functional user tests, UI performance, back-end load handling and system usability using SUS-tests.
 Software tests comprise:
@@ Line 567: / Line 596: @@
 (iii) usability tests according to the [[https://www.usability.gov/how-to-and-tools/methods/system-usability-scale.html|System Usability Scale]].
+**Performance:**
+Testing an application on performance requires the developer to look at the disparity between the UI build and the raster build.
+UI performance refers to how quickly the application processes input, updates state, and completes layout and rendering decisions on the main thread. Slow UI performance usually results in delayed interactions and unresponsive or janky behavior.
+Raster performance refers to how efficiently the system converts rendered layers into actual pixels on the screen, often using the GPU. Poor raster performance leads to visual stuttering, dropped frames, or delays in what is actually displayed even if the UI logic is fast.
+The Screen2Green app performed on high speed, reaching an average UI build speed below 2 ms and an average raster build speed below 5 ms.
+<WRAP centeralign>
+<figure fig:performance_test_overview>
+{{:report:app:tests:perf_test_example.png|}}
+<caption>Screenshot of the application being performance tested using Dart DevTools. This image shows a generally fast rendering time.</caption>
+</figure>
+</WRAP>
+Occasionally, the app would experience jank, meaning some widgets would slow down the app. These occasions include the following:
+  * Creating a social media post
+  * Opening the social zone and seeig images load
+  * opening the register or sign-in page
+<WRAP centeralign>
+<figure fig:jank_time>
+<WRAP group>
+<WRAP half column>
+{{:report:app:tests:perf_test_choosing_img_on_upload.png|}}
+</WRAP>
+<WRAP half column>
+{{:report:app:tests:perf_test_fetching_new_post.png|}}
+</WRAP>
+</WRAP>
+<caption>Screenshots of the application's performance when meeting either one of the 3 priorly named conditions.</caption>
+</figure>
+</WRAP>
+<WRAP clear></WRAP>
+**Load:**
+The team used k6 to load test the back-end of the application. First, a script was written with the purpose of creating a large amount of accounts to enable load testing. 200 user profiles were created using a script written in JavaScript and ran using k6.
+At the time of writing this report, it's not possible to load test further due to API shortage prevention in Supabase. The idea is to test the following 3 items:
+  * log-ins in abundance
+  * creating social media posts in abundance
+  * retrieving them in abundance
+The team will continue this type of test in the near future.
+**System Usability Scale - SUS**
+The SUS-test is made to measure the scale of a product's necessity and ease of use and is measured using a small questionnaire of 10 questions where a tester gives a score between 1 and 5 on each question. Odd questions have their answer subtracted by one and even questions have the answer subtracted from 5. Lastly, the new answers get counted up and multiplied by 2.5.
+After questioning 6 users, the application in its current state is seen as a mix between neutral and good. The average score of all results, which are in the deliverables and Microsoft Teams, is 74.17.
 ==== 7.9 Summary ====