Julia Lazar's miscellaneous blog

I feel confident in JavaScript. I've been using it for years, and I understand both the language itself and how it behaves (often in weird ways). I understand the differences between var, let, and const, including scope, hoisting, and the temporal dead zone. I'm also familiar with closures, promises, async/await, and the event loop, including the call stack, microtasks, and macrotasks. I can also write plain vanilla JavaScript without relying on a framework.

I understand this design pattern and its benefits: one class per page that keeps its locators and actions, readable tests, less duplication, and only one place to fix when the UI changes. I know how to use it in a real project, because I have already used it in several projects during my internship.

I was thinking of setting this skill to 100%, but then I recalled that there may be errors in my judgement and I can never be 100% sure that there are no bugs in my brain ;)

I have been using it for ages, mostly when I work on a project on my own. I know how to create branches and how to get changes from a remote repo with both git fetch and git pull. I run most commands from the command line in bash. I can resolve merge conflicts (although almost always through the GUI in VS Code). I know how to write semantic commit messages, and undoing changes is no problem (I just peek at Stack Overflow to remind myself, or these days ask a good LLM which commands to run and how they differ). I know what a pull/merge request on GitHub/GitLab is and how to give developers the right permissions. I also keep a .gitignore, use git stash when I have to switch tasks mid-work, and git log / git diff to see what actually changed.

Easy to learn, hard to master. I know how to create interfaces and types and use them to define the type of a variable or object, or what a function takes in and returns. I know the basic difference between an interface and a type (use an interface to define the shape an object or class should follow, and types for the rest, since they're more flexible and can represent unions, primitives, tuples and much more; if both work equally well for an object shape, follow your team's conventions and stay consistent). I know why TypeScript is useful, but I know things like generics only in theory and haven't used them on a real project. I also don't know when I'd need to use infer, instanceof, or some of TypeScript's other more advanced features.

I know what they are and when they are useful.

After a nine-month internship in testing and test automation, I'm pretty sure I know the basics of software testing (or at least I really should by now).

I write good assertions by validating meaningful, user-facing outcomes, using specific locators and Playwright's web-first assertions. They retry automatically, which makes tests more reliable and less flaky. I avoid hard waits and assertions that depend on implementation details. I know how to parametrize tests and what the advantages are: code reusability, less duplication, better test coverage (valid inputs, invalid inputs and edge cases) and easy maintenance.

I know what they are. I know the seven phases of the SDLC, the roles and events in Scrum, and how Scrum differs from Kanban. I don't really try to memorize all 12 principles of the Agile Manifesto, and I honestly struggle to remember the four core values of Agile (maybe I'll remember them if I write them down here xd): - Individuals and interactions over processes and tools - Working software over comprehensive documentation - Customer collaboration over contract negotiation - Responding to change over following a plan I'd rather learn what Agile actually feels like by working on a project that uses it.

I know how to write E2E tests in Playwright for both UI and API testing. I understand web-first assertions and their auto-retrying mechanism. I know what browser instances, browser contexts, and pages are in Playwright, and I understand fixtures and how to create them. I also know how to organize test suites using describe blocks and define tests using test blocks, as well as what test.step, test.only, and test.use do. I appreciate Playwright's support for cross-browser testing, its resilient locators, and its ability to run tests in parallel. The Trace Viewer is a wonderful GUI for debugging, and the Playwright VS Code extension is great for writing tests.

Sometimes I know stuff but have trouble putting it nicely in English, although I try to tackle the question as well as I can. I know I might be a little chaotic (working on it, though), and it's easier for me to write something down or show an example in code. I mean, how do you explain the Factory design pattern just in words?

I still need some practice figuring out when to use, for example, a beforeEach hook and when to create a fixture instead. But wait, give me a second… *Comes back 10 minutes later.* I've done some research with the help of a large language model, and the oracle has spoken: use hooks for actions tied to the test lifecycle, and fixtures for reusable dependencies that need setup, injection, and possibly teardown. When you're asking yourself **WHEN** an action should happen, think hooks. When you're asking yourself **WHAT** resource a test needs, think fixtures. See how easy it is with AI these days? You've got your own little professor who can explain concepts to you as if you were 10 years old. I just hope this professor won't steal my job, haha, because AI is like the invention of the calculator: it's just a tool. Right? At least, that's what I keep telling myself so I don't go crazy and end up picking strawberries abroad after all those years at uni. Wait, why am I oversharing here? I guess studying for hours on end takes its toll. I'm a little stressed about tomorrow's technical interview. Wish me luck!

Web, URLs, servers, clients, HTTP, network requests and responses, browser engines, web browsers, pages, the must-know trio of HTML, CSS, and JavaScript, and so on: I have a decent understanding of how our little World Wide Web works. I'm no expert, though. I also wouldn't set the admin password to password123, hard-code it, and push it to a public repo. I know about common threats such as DDoS attacks, brute-force attacks, SQL injection, XSS, and CSRF, but I don't know how to ethically hack a website or protect it against more sophisticated attacks. (I even failed EPAM's phishing test 😭 It was the middle of the night, and I was sleepy, okay?? That's a terrible excuse, IKIK.)

I know the differences between white-box, grey-box, and black-box testing. I'm also familiar with black-box test techniques such as Equivalence Partitioning, Boundary Value Analysis, Decision Table Testing, State Transition Testing, Use Case Testing, Pairwise (combinatorial) Testing, and Error Guessing, as well as experience-based techniques such as Exploratory Testing.