Oleksii Golub

About a year ago, I launched a Russian-speaking YouTube channel (https://lnkd.in/eUwiSVEU), which has grown to 75k subscribers. Although it began as a blog about my QA career, I haven’t posted anything related to that in over six months. When I started, I secretly hoped that content creation might be "my true calling." I was excited about the idea of turning this passion into a full-time endeavor, freeing me from the constraints of my previous career in Tech. A few months ago, I left my job, partly because of this new passion. Around the same time, I read a book called So Good They Can’t Ignore You. It made me realize: you can’t abandon a career and suddenly succeed at something entirely new just because you're passionate about it. It requires building what the author calls Career Capital — a set of rare and valuable skills you can offer to the world. Only AFTER that can you think about receiving something valuable in return. This approach worked for me as a QA engineer — a realization that only came to me after I attempted a career switch and read the book. I became skilled not because I was naturally talented but because I dedicated countless hours to deliberate practice and navigated many stressful situations, like sleeping just 4 hours a day and working 16-hour days during an onsite 3 week trip abroad to prepare a system for UAT. I hadn’t fully appreciated that these challenges and focused efforts were what helped me grow professionally. For my new activity — YouTube — I’ve poured approximately 400 hours into a single video (the most recent one). That’s totally OK because: 1. I’m new to scriptwriting. 2. I have no prior experience in video editing. 3. I struggle with shyness, often feeling extremely anxious when filming in public places. Despite these challenges, I want to become good at content creation. However, the biggest realization is how much I also want to excel in my primary field — QA. More than even I’m now willing to invest hundreds, even thousands, of hours into mastering the skills required to become a true professional. Ironically, while chasing what I thought was my “true calling,” I’ve come to understand that the only real “calling” is the pursuit of excellence in the work I’m already doing. Have you ever faced a similar realization about your career? I’d love to hear your thoughts!

92

12 Comments

🔧 Appium - Robot Framework vs. Cypress: My Test Automation Tools 🔧 In my work at Neste Mobile App Project and on the Marimekko online shopping platform, I’ve used two different frameworks for test automation, depending on the project’s needs. 💡 Appium + Robot Framework Best for: Mobile app testing When testing mobile apps, this duo has been unbeatable. Appium handles the cross-platform automation for Android and iOS, while Robot Framework brings a clear, keyword-driven structure to test cases. Together, they make mobile app testing efficient and scalable. This combination was especially helpful at Neste, ensuring a smooth and consistent experience for all users. 💡 Cypress Best for: Web app testing For web platforms like Marimekko’s online store, Cypress has been tool of team's choice. Its speed, easy setup, and real-time debugging make it perfect for modern web applications. I’ve used it to run end-to-end tests, ensuring the platform delivers a seamless shopping experience. 🎯 The Bottom Line: Both approaches have their strengths. Appium + Robot Framework is perfect for mobile apps (of course you can use Robot Framework on Web App testing), while Cypress shines for web applications. Choosing the right tool depends on the platform and the project requirements. What’s your preferred tool or combination for test automation? #Appium #RobotFramework #Cypress #MobileTesting #WebTesting #TestAutomation

9

On the CI side, there are code writing, compilation and testing parts. After writing code build with tools like Gradle, Bazel. During the testing phase, we test the code frequently with tools like Jest, JUnit and catch potential errors early. Tools like Jenkins speed up this process. On the CD side, the code that has passed the test is distributed with tools like Docker or Kubernetes. It is run with solutions like AWS Lambda and monitored with tools like Prometheus, Datadog. Testing is the essence of the entire process. The more frequently the code is tested, the more reliable and robust the product is. In this process, identifying errors early allows us to improve and helps the software to be continuously found.

13

🚀 Stop Wasting Time on Full Test Suites: Use Playwright’s --only-changed Option! 🚀 Why run every test when only one file has changed? Playwright’s --only-changed option helps streamline your development workflow by running tests only for the files you've modified. ⚡ 💡 Save Time: Instead of waiting for all tests to run, Playwright runs only the ones affected by your changes, speeding up your iterations. 🛠 Pro Tip: Add this option to your package.json scripts for an even smoother, automated workflow—perfect for pre-commit hooks, CI pipelines, or local coding. Isn’t it time to ditch unnecessary steps? Try it out and share how it improves your development process! 🚀💬 #Playwright #Efficiency #Productivity #QAAutomation https://lnkd.in/dyr-ddZx

11

For Testers with enthusiasm for Java, Springboot and Playwright - try out Vaadin's FE api as a Springboot project. Here is a very simple example of how you may create a web view for your Playwright tests: https://lnkd.in/db3Wt_QX

2

Fellow QAs: Don't be worried or defensive about AI being applied to QA. I keep hearing two types of reactions in some QA circles about AI: “AI can’t handle the complexity of testing; it’s not ready for us.” “AI efficiency will just mean more work for us.” Here’s the hard truth: both of these are defensive postures. Staying defensive will not save us; it will DISRUPT us. Embrace AI. That doesn’t mean ignoring the challenges. It means leaning into what we, as QAs, do best: - Providing critical insights AI can’t. - Applying human creativity and experience to testing. - Being the experts in context, risk, and customer impact QA AI tools are evolving, but so must we. If we focus on what makes us irreplaceable and integrate AI into our workflows as a tool (not a threat), we will future-proof QA as a critical function in software development. Our choice: adapt or risk being disrupted.

30

6 Comments

1. Gradle Inc. Gradle is like a magic builder for your software projects. Think of building a house - you need to assemble bricks, wood, and other materials. Gradle does this for software. It takes your code, puts all the pieces together, and turns it into a working app or software. It's super fast and can handle big projects with ease, making sure everything is in the right place. 2. Phabricator Phabricator is like an all-in-one project hub for software development. Think of it as a digital workshop where your team can plan, build, and manage projects together. It helps you track tasks, review code, and collaborate in one place. This makes sure everyone stays on the same page, work moves smoothly, and projects are completed efficiently. 3. Gitea Gitea is like a digital storage locker for your code, but with teamwork in mind. Imagine working on a project with friends. You all need to keep track of who did what and make sure you're not messing up each other's work. Gitea helps you do that by letting you save your code, track changes, and collaborate seamlessly. Plus, it’s lightweight and super easy to set up! 4. Huginn Huginn is like your personal internet assistant. Imagine having a smart robot that watches the internet for you and takes action when something happens. Huginn can send you alerts, gather information, and even perform tasks automatically. Whether it’s monitoring news, tracking emails, or managing social media, Huginn makes your online life easier by doing the repetitive work for you. 5. Tabnine TabNine is like an intelligent assistant for coding. Let's say you’re writing a long essay, and someone whispers the next sentence to you. That’s what TabNine does for coding. It predicts what you’re about to type next and offers suggestions, helping you code faster and with fewer mistakes. It’s like having a smart friend who knows exactly what you need. 6. Ansible by Red Hat Ansible is like a remote control for your IT tasks. Imagine having to cook dinner for 100 people in different kitchens. Ansible helps you control all the stoves from one place. It automates tasks like setting up servers, deploying apps, or managing systems, so you don’t have to do it manually. It’s super efficient, reliable, and saves a ton of time. Follow For More 🤖

6

2 Comments

New article in my weekly feed findings 🤖 I'm learning how to write tests on Playwright and sometimes use AI in my work. An interesting topic about creating self-healing tests using AI and Playwright from author 💎 And thanks to the Ministry of Testing for a great portal. https://lnkd.in/ddpwcMmg #qa #softwaretesting #softwaretesting101 #qualityassurance #networking #article #exploratory #testing #bugcount #testcase #balance #weeklyarticle #automation #playwright #AI

2

I don't believe in luck (maybe a bit?). So I have to repost. Senior QA Engineer here, specializing in automation and searching (and solving) new challenges. I'm quite good on building solid testing frameworks from the ground up, primarily with Playwright (Cypress and I have a complicated relationship – let's just say we've agreed to disagree. And Selenium? Let's be real, it's 2024!). But even if you don't have anything else, in other testing layers – I can help you with that too. Beyond automation, I'm passionate about streamlining processes, optimizing release pipelines, and everything in between. My toolkit includes JS/TS, with a bit of Bash and Python. Currently exploring new opportunities and seeking a product team (sorry software houses/"workforce selling" companies) that values quality as much as I do. Think I could be your missing piece? Let's chat! You can find more details in my original post: https://lnkd.in/dCDdrxb7 Also I know post will have quite traction so I can also link my guide (welcome to expand it) about building QA architecture in companies: https://lnkd.in/gHkEMZsr #qa #automations #work #search #playwright #javascript #typescript #resume #OpenToWork #recruitment #qualityassurance

29

1 Comment

🚀 Hi fellow testers, EXCITING NEWS! 🚀 I've just released my new cypress-ajv-schema-validator plugin and published a blog post about it! This powerful cypress.io plugin ensures your API responses are validated against JSON schemas, Swagger, and OpenAPI documents using the Ajv JSON Schema validator. Plus, it presents schema errors in a very easy, user-friendly way. Check out my detailed blog post for all the ins and outs: "CYPRESS-AJV-SCHEMA-VALIDATOR Plugin: The Brave Vigilante for Your API Contracts" (https://lnkd.in/g3N5fkAn). Explore the repository and get started here: https://lnkd.in/g8ZDQPMk You can also install it directly from NPM: https://lnkd.in/gkGYGRET If you like the plugin and the blog post, feel free to leave a comment and share your thoughts. Stay vigilant, stay validated my friends! #cypress #ajv #schema #validator #plugin #qa #automation #test #blog

35

1 Comment

Hi fellow testers! This was my 6th blog post. It was about JSON Schema validation and how the new pluguin I created CYPRESS-AJV-SCHEMA-VALIDATION can help you in API testing (supports Json Shema and the standards OpenApi 3.0.1 and Swagger 2.0).

26

Should devs do more testing? Pros and cons in a nutshell It’s quite a trend now - many companies want to "improve" software development processes and "save money" by having fewer QA/Testers and letting devs do more testing. These are general points from industry professionals that I combined based on how often people mention them. ✔ Pros: 1 - Make processes more efficient and speed up CI/CD cycles, fewer delays between development and testing. 2 - Developers gain testing skills, leading to a better understanding of potential issues and overall code quality improvement. 3 - Fewer dedicated QA testers lower costs (technically yes but no). 4 - Prevents costly fixes later on - smoother project timelines and fewer disruptions. 5 - Fewer dedicated QA testers - smaller teams - easier to manage the team and activities (technically yes but no). 6 - Devs usually have better tech skills and can perform complicated tests more efficiently. 7 - Easier to support testing framework. 🚨 Cons: 1 - Developers may be overwhelmed, affecting their productivity and focus on development tasks. 2 - Lack of specialized skills and mindset of QA testers, leading to potential oversights and a decrease in software quality. 3 - Balancing coding and testing can lead to burnout. 4 - Developers might overlook broader system issues that QA testers would typically catch - tunnel vision. 5 - Higher salaries for developers because of more responsibilities and more skills. 6 - More difficult to find devs who would agree to do not only unit testing and some e2e but all types of testing. 7 - Devs spend up to 70% of their time on testing leading to fewer features, and less frequent releases; as a simple solution to hire more devs. 💡 Balanced effective approach: 1 - Combine developer testing with QA support. 2 - Provide training in testing methodologies. 3 - Foster collaboration between developers and QA. 4 - Invest in tools to reduce manual testing on developers and assign different QA and testing activities to different roles/teams. 5 - Quickly identify and address issues, ensuring ongoing improvement in both development and testing processes. ---------- 🤔 Concerning questions and risks: How do you think this change will affect software quality and development efficiency? Is this approach effective in maintaining high-quality standards? What are the main challenges and benefits of having developers do more testing? From a budgeting perspective, is reducing the number of QA professionals cost-effective? How will this shift affect developers' workload, productivity, release frequency, and feature quantity? ---------- What’s your experience with developers doing more/all testing? Have you seen improvements or challenges? Share your thoughts in the comments ⬇ Check out the link in the comment with the discussion on this topic on the Ministry of Testing Club platform for details ⬇ #softwaredevelopment #testing #qualityassurance #softwaretesting #softwareqa #efficiency #mindset

19

9 Comments

What are your thoughts on running tests in production environments? Is it ever justifiable? Testing in production can be controversial, as it introduces potential risks to live users. However, in certain scenarios, it can provide invaluable insights that pre-production/lower environments cannot replicate. One advantage of testing in production is the ability to observe real user interactions and identify issues that only occur under actual load and usage patterns. This can lead to the discovery of edge cases and performance bottlenecks that might be missed in staging environments. Additionally, feature flags and canary releases can mitigate risks by gradually exposing new features to a small subset of users, allowing for controlled testing and monitoring. Despite these benefits, running tests in production requires rigorous planning and safeguards to minimize user impact. Monitoring tools and automated rollback mechanisms are essential to quickly address any issues that arise. It's also crucial to communicate with stakeholders and ensure that the team is prepared to handle potential disruptions. Do you think testing in production is worth the risk? Share your experiences in the comments section...

5

2 Comments

https://lnkd.in/d9hcf2xy I've created a tool based on Electron js to split big JSON file/files into small ones, whoever needs it or is just interested >>> clone it and use it.

3

Every time I talk with CTOs about Software QA and testing, I get one of two reactions: 1 - I don’t want to think about QA/testing; can we talk about anything else? 2 - I don’t want to think about QA/testing, but I now HAVE to focus on it, so can we please get this over with? This is a big reason why MuukTest sells *very* fast. Because when CTOs HAVE to focus on Software Testing, they want a solution that just… works. Something they can rely on, that they don’t have to think about too much, that they don’t need to know every single detail about. Is this the ideal world? Of course not. Do I WISH I could talk for HOURS with CTOs about QA and testing, about shifting left, about the nuances of *real* QA and different testing approaches? Of course. Do I feel like my 20+ years of Software QA/testing expertise is valued? Definitely not *until* we’ve delivered a ton of value for companies. And even then… nobody wants to hear my thoughts on QA/testing 😆 I can complain about this… or we can just build our business around the reality that CTOs don’t really want to talk about or think about QA/testing—they just want it effortlessly. Can you blame them for it? Of course not. 

25

7 Comments

Our team at CarbonQA is working on our API automated testing skills, using Jest and SuperTest. A design idea that I used heavily when I was full-time coding nUnit tests in Java was to abstract the API test representation from the test code. Simple idea for creating more modular and maintainable test code, right? If something changed on the API, we changed it once in our API test representation and (mostly) could count on our tests not breaking...or at least needing only minimal refactor. Surprisingly, I couldn't find any good javascript examples of this. So here's a never-tested psuedocode pattern our team used to model, with a hat tip to my former team at Carvana. Happy dog-day! If you have any other examples, please share. At CarbonQA, we provided fractional QA testing services and API test automation, at the price and schedule that works for you! TEST FILE import DogsApi from '../../src/API/transaction/dogsApi'; import CustomerBuilder from '../../src/helpers/customerBuilder'; let dogsApi; let userId; let dogId; beforeAll(async () => { const authToken = await new AuthTokenGenUtility().getBearerToken( 'dogShop' ); dogsApi = new DogsApi(authToken); ({ userId } = customerRes.customer.account); const dogsRes = await executeHttpRequest( dogsApi.getDogsByCustomerId(userId) ); dogId = parseResponse(dogsRes).dogs[0].id; }, 300000); describe('DOGS API - GETS', () => { ('GET dog by DogId', async (myId, resp) => { if (resp == 200) myId = dogsId; return executeHttpRequestWithoutThrow(dogsApi.getDogbyDogId(myId)).then( (response) => { expect(response.status).toBe(resp); } ); }); API MAPPING FILE class DogsApi { constructor(authToken) { this.authToken = authToken; this.headers = { 'Content-Type': 'application/json', Authorization: `Bearer ${this.authToken}`, }; } getDogbyDogId(dogId) { return new Request.Builder('api') .withMethod('GET') .withEndpoint(`${dogsUrl}/id/${dogId}`) .build(); } getDogsByCustomerId(custId) { return new Request.Builder('api') .withMethod('GET') .withEndpoint(`${dogsUrl}/id/${custId}`) .build(); } Tyler Hartless Mario Martell #quality #software Synapse Studios CarbonQA

7

Excellent example of in-depth AI prompts for analyzing test failures and planning tests.

3

New version 1.45 - time manipulation with Clock API - ability to look for network call for single actions And many more updates and features

7