Skip to content
View Tlacenka's full-sized avatar

Organizations

@flowup
Block or Report

Block or report Tlacenka

Block user

Prevent this user from interacting with your repositories and sending you notifications. Learn more about blocking users.

You must be logged in to block users.

Please don't include any personal information such as legal names or email addresses. Maximum 100 characters, markdown supported. This note will be visible to only you.
Report abuse

Contact GitHub support about this user’s behavior. Learn more about reporting abuse.

Report abuse
Tlacenka/README.md

Hi there! I am Kate, a QA engineer and test architect at FlowUp.

🧪 About my role

Quality Assurance for me isn't just about testing - it is a mindset. Although quality means different things for different people, I believe that there are three main areas to optimise for - User Experience, Developer Experience (sadly often overlooked) and processes. Therefore, I help cultivate this quality mindset on my projects towards a shared ownership of quality among the whole team.

From a technical point of view, I develop a suitable testing strategy on a project and make sure that test quality is prioritised over quantity. I introduce and encourage good practices and principles towards maintainable product.

From a process perspective, I am an advocate for shifting left. Prevention and informed decisions in face of risks saves time and therefore money. So I aim to assess and communicate potential risks to the team in order to minimise refactoring in the future.

📰 Articles

📊 GitHub statistics

github_stats

Top Languages

📚 Tech stack

Here is a list of technologies and tools I use regularly. However, I am not a specialist and believe that it is important to learn about new technologies and use the right tool for the job, not the one I am most familiar with.

You might have noticed I have quite a long list of documentation tools. That is because I believe that documentation is one of the most important factors of a successful product. And by that I don't mean that investing weeks into writing (and later maintaining) an extensive documentation is the right way.

I simply believe that there should be a single source of truth. Good issue definition with a user story, clear test case descriptions that help understand a functionality and helps deduce test coverage and wiki with links and architectural diagrams are key to a successful product. It is always a bad sign when onboarding takes too long and developers are expected to hold all the product information in their memory.

Languages and frameworks

TypeScript Angular

Testing frameworks

cypress Cucumber.js Jest Vitest

Quality tooling

ESLint CodeCov

Versioning

Git GitHub Azure DevOps

DevOps

GitHub Actions Azure Pipelines PowerShell

Project management

GitHub projects Jira

Design

Storybook Figma

Documentation

LaTeX Markdown Notion Confluence

Other technologies and tools

Nx Linux Vim Visual Studio Code Slack

Pinned

  1. code-pushup/cli code-pushup/cli Public

    A CLI to run all kinds of code quality measurements to align your team with company goals

    TypeScript 19 8