Posts

After the second sprint

  During this sprint, our team focused on setting up automated testing tools within our development environment, working with Vitest and Playwright. Unlike the previous sprint where we mainly researched tools, this time we attempted to implement them into our actual project workflow using Docker. A large portion of the work involved configuring the environment, installing dependencies, and troubleshooting issues that prevented the tools from running correctly. Although there are limited successful GitLab commits due to setup failures, the effort was focused on building the foundation for testing integration. However, we were able to get a working version that can be used as a base for every test. First half-working git commit : https://gitlab.com/LibreFoodPantry/client-solutions/theas-pantry/guestinfosystem/guestinfofrontend/-/commit/9382538b27224d0d6ffc4815798cfe0207040781 One thing that worked well during this sprint was persistence in troubleshooting. Even though the setu...

Equivalence Partitioning Testing

  The article “Comprehensive Guide to Equivalence Partitioning Testing” from TestGrid explains an important software testing technique used to design efficient test cases. Equivalence partitioning is a black-box testing method where input data is divided into groups, or “partitions,” that are expected to behave the same way in the system. Instead of testing every possible input value, testers can choose one representative value from each partition to verify the system’s behavior. This approach reduces the number of test cases while still maintaining good test coverage. The article explains how the equivalence partitioning is useful when the range of possible inputs is large and testing every value would be wasting time. By grouping similar inputs together, testers assume that if one value in the group works correctly, the rest of the values in that group should behave the same way. For example, if a form only accepts ages between 18 and 59, the test cases can be divided into thr...

After our First Sprint session ends

          During this sprint, our team focused primarily on researching and evaluating automated testing tools that could be used in our project. Since our team was the first to create a test, using tools for future use, much of our work involved reviewing documentation, checking for updates and if it is opensource, experimenting with different testing frameworks, and discussing which tools would best support our development workflow. Although there are currently no major commits or issues in GitLab yet, the sprint involved important groundwork for establishing our testing strategy. Even though there are no GitLab commits yet, the following resources were the main candidates for the tools we will use and evaluate the most visiting numerous documentations, videos, review and blogposts.: https://playwright.dev/docs/intro   – Reviewed documentation to understand how Playwright performs end-to-end testing and browser automation. https://v...