Blog & articles

Imagine that you are a color-blind person, trying to adapt to a life without color. Unfortunately, our world is dependent on uniformly perfect color vision, and when some can’t meet the standard, a tremendous emotional rift is often created. To bridge this divide, society makes all sorts of accessibility accommodations. Similarly, as testers, we need to be empathetic when we test an application. A common misconception is that accessibility testing is not required if nobody asks for it.

Video games provide entertainment for all ages and have significantly evolved over the years. Pixelated screens, limited color palettes, simple sounds, and basic AI are now just memories. Video games become more realistic every day. Today, we have access to better screen quality, more computing power, better graphics processors, and more memory. As technology improves, so do video games.

Some time ago, university software engineering teachers showed the traditional test phases using the waterfall process: the sequential line of unit test (UT), functional verification test (FVT), system verification test (SVT), and global verification test (GVT) to check the user-readable text. More enthusiastic teachers also showed black box and white box testing for test cases with and without access to the source code, respectively.

As quality engineers, we're ready to test applications in the staging environment. But what happens before code lands there? Understanding the development lifecycle—from commit to production—shapes our testing strategies. This understanding starts with unit testing in DevOps. Let's explore the tools and technologies—including AWS, Terraform, Docker, Ansible, Grafana, and Kibana—that drive this process. We'll also tackle the key question: what is the definition of a unit test from a DevOps perspective? Follow along to discover the behind-the-scenes magic of software development.

Fundamentally, test automation and the use of a codeless automation testing tool are still a considerable challenge; coded tests are executed within the usual workflows, developers and SDETs receive the feedback within the build process; these tests only cover a limited amount of test scenarios. On average, 20-30% of functional test scenarios are not part of this process. On top of these difficulties, traditional testing, like any individual process, is prone to error, which can cause more significant issues down the road.

Since 2004, Selenium has become one of the top open-source frameworks for automating testing. This framework helps validate and test web applications using several languages such as Java, C#, or Python to create the scripts of the tests.