<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>Testing — Articles | WebPro Company OÜ</title>
    <link>https://webpro.company/blog/tag/testing/</link>
    <atom:link href="https://webpro.company/blog/tag/testing/rss.xml" rel="self" type="application/rss+xml" />
    <description>Automated testing for Drupal projects — how to start small and reduce the need for manual verification after every change.</description>
    <language>en-US</language>
    <lastBuildDate>Wed, 27 May 2026 06:00:00 GMT</lastBuildDate>
    <item>
      <title>Visual regression testing for websites</title>
      <link>https://webpro.company/blog/visual-regression-testing-for-websites</link>
      <guid isPermaLink="true">https://webpro.company/blog/visual-regression-testing-for-websites</guid>
      <pubDate>Wed, 27 May 2026 06:00:00 GMT</pubDate>
      <category>Testing</category>
      <description>A normal automated test checks whether a button works. Visual regression testing helps check whether the button, form or component is still in the right place and readable. How it works Playwright opens the page in a browser, takes a screenshot and compares it to a saved baseline image. If the pixel difference exceeds the allowed threshold, the test fails. On first run a baseline image is created. All future screenshots are compared against it. When design changes intentionally, the baseline is updated manually. Visual testing helps when: design changes often; the site must work on mobile and desktop; components come from several systems; previous releases caused layout defects; accessibility depends on visible focus and readable text. What not to over-test Not every page needs…</description>
    </item>
    <item>
      <title>Playwright tests for forms, menus and carts</title>
      <link>https://webpro.company/blog/playwright-tests-for-forms-menus-and-cart</link>
      <guid isPermaLink="true">https://webpro.company/blog/playwright-tests-for-forms-menus-and-cart</guid>
      <pubDate>Wed, 20 May 2026 06:00:00 GMT</pubDate>
      <category>Testing</category>
      <category>E-commerce</category>
      <description>Automated testing does not need to start with a large suite. Forms, menus, search and carts are often enough for the first useful step. What to test first Playwright is a good fit for testing real browser user journeys. In a Drupal project, the first test suite should cover the most important actions. Start with: the contact form opens and validates fields; the menu works on mobile and desktop; search or filters return results; the cart adds and removes a product; a critical content page loads without JavaScript errors. Why a small test is better than no test A small, clear test suite creates value quickly. It does not cover everything, but it catches regressions that people forget to check manually after every update. WebPro provides automated testing for Drupal projects. We usually…</description>
    </item>
    <item>
      <title>Why we automate Drupal work as much as possible</title>
      <link>https://webpro.company/blog/git-composer-and-automated-drupal-workflow</link>
      <guid isPermaLink="true">https://webpro.company/blog/git-composer-and-automated-drupal-workflow</guid>
      <pubDate>Tue, 12 May 2026 06:00:00 GMT</pubDate>
      <category>Drupal</category>
      <category>Development</category>
      <category>Testing</category>
      <description>Good Drupal work is not only about writing code. It is also about how a change moves from a developer machine to a test environment and then to the public website. Drupal projects can easily drift into a risky pattern: small fixes are made directly on the server, files are moved manually and nobody remembers exactly what changed or when. That may feel fast at first, but it becomes dangerous when the website is business-critical, includes an online store, uses integrations or has more than one developer. That is why WebPro tries to make as much work as possible automated and repeatable. This does not remove people from the process. The opposite is true: people stay responsible, while repeated steps are written down and can be checked. Git gives the project memory Git is not only a…</description>
    </item>
    <item>
      <title>Automated tests do not need to start big</title>
      <link>https://webpro.company/blog/automated-tests-for-drupal</link>
      <guid isPermaLink="true">https://webpro.company/blog/automated-tests-for-drupal</guid>
      <pubDate>Sat, 09 May 2026 06:00:00 GMT</pubDate>
      <category>Testing</category>
      <category>Drupal</category>
      <description>Testing does not have to cover the whole system from day one. A small set that checks the most important workflows often gives the highest value. When is the right moment to start Testing does not need to wait until the system is large. The best time is when: an update or change broke something in production and nobody noticed immediately; developers are afraid of updates because they do not know what might break; a Drupal version upgrade is coming and you want confidence that core workflows still work. A useful first test set the homepage and key content pages open; the contact form or request path works; mobile view does not create horizontal scrolling; important external links are not broken; a critical admin or client workflow can be completed. These five tests can fit in a single…</description>
    </item>
    <item>
      <title>Screen reader testing — how to check accessibility in practice</title>
      <link>https://webpro.company/blog/screen-reader-testing-practice</link>
      <guid isPermaLink="true">https://webpro.company/blog/screen-reader-testing-practice</guid>
      <pubDate>Wed, 06 Mar 2024 06:00:00 GMT</pubDate>
      <category>WCAG</category>
      <category>Testing</category>
      <description>WCAG checklists and automated tools are a good start — but screen reader testing shows what actually works and what does not. Why screen reader testing is necessary Automated accessibility tools (axe, Lighthouse, WAVE) check code structure — whether alt texts exist, whether headings are in order, whether colour contrast meets the standard. This covers roughly 30% of accessibility issues. The remaining 70% — whether navigation is logical, whether focus moves sensibly, whether modal dialogs behave as expected, whether dynamic content is accessible — can only be discovered through real use. Screen reader testing shows the site as a user who does not use a mouse experiences it. Which screen readers exist NVDA (Windows, free) — the most widely used screen reader on Windows. Ideal for…</description>
    </item>
  </channel>
</rss>
