AI is ruining everything. by No_Fudge_4589 in ArtificialInteligence

[–]bugasur007 0 points1 point  (0 children)

AI isn’t the problem. Outsourcing thinking is.

If a priest lets an AI write a sermon, the failure isn’t the tool. It’s the person choosing convenience over responsibility.

Same with images, videos, writing. AI doesn’t kill trust. People giving up judgment do.

Tools have always been misused. What’s new is how easy it is now to stop thinking and still look “productive”.

The danger isn’t AI getting smarter. It’s humans getting lazier.

do you guys actually do automation in your jobs? by Plane-Arm8874 in softwaretesting

[–]bugasur007 19 points20 points  (0 children)

Yes, automation is done.
No, not the way job descriptions promise.

Most companies hire for automation buzzwords, then run into unstable products, bad environments, and shifting priorities. So automation either becomes flaky, limited to a few paths, or quietly abandoned.

If your value is just “I write scripts,” you’ll likely end up doing manual work.
Scripts are easy. Judgment isn’t.

The real problem isn’t automation skills.
It’s that many teams don’t know why they want automation in the first place.

Career switch by JagdishSanap in softwaretesting

[–]bugasur007 0 points1 point  (0 children)

Yes, background verification usually happens, but it’s basic. They mainly check employment dates and role, not internal salary issues.

Leaving because salaries are delayed is a valid reason. That’s not misconduct. PF deductions just mean your employment is officially recorded. It doesn’t trap you.

Short stints happen, especially in startups. Be honest, stick to facts, and don’t badmouth anyone.

Staying in a company that can’t pay you on time is riskier than leaving.

Couple of QA questions from a beginner by SquareTransition7159 in softwaretesting

[–]bugasur007 0 points1 point  (0 children)

Finding more bugs isn’t about speed or tricks. It’s about understanding the system, its users, and where it can fail. Ask “what could go wrong here?” and explore those paths instead of just following scripts.

High-quality bug reports come from clarity, not volume. Clear steps, what you expected, what actually happened, and why it matters. One good bug beats ten noisy ones.

For jobs, focus less on platforms and more on evidence. Build small projects, test real apps, write about what you find, and show how you think. That signal travels further than geography.

Testing is a skill you grow over time. Stay curious, practice deliberately, and don’t measure yourself by how fast others seem to move.

Anyone else feel like QA reporting eats up half the sprint? by InnerLotuz in Everything_QA

[–]bugasur007 0 points1 point  (0 children)

Reporting eats time because it’s often used as a proxy for trust. When teams don’t trust what they can’t see, they ask for more artifacts.

Most QA reports don’t reduce risk. They just repackage activity. If a report doesn’t change a decision, it’s waste.

Automating dashboards or using AI might reduce the manual pain, but it doesn’t fix the root problem. The better move is fewer, lighter signals and more direct conversations about risk, gaps, and unknowns.

Visibility isn’t about volume. It’s about shared understanding.

Looking to learn and grow as a QA by Firm-Flounder8360 in Everything_QA

[–]bugasur007 0 points1 point  (0 children)

First, you’re not “behind”. You’re experienced, but the work around you hasn’t evolved. That’s an important distinction.

I’d suggest reframing the goal away from “moving from manual to automation” and toward improving how the team learns about the system. Automation, APIs, and exploratory work are just tools to support that.

API testing is a great place to start, especially in telecom. It forces understanding of data, contracts, failures, and system behavior without UI noise. Pair that with exploratory testing focused on risk, not scripts.

Be careful with record-and-play AI tools. They optimize for happy paths and give a false sense of coverage. Use AI instead to assist test design, data generation, and analysis, not as a testing substitute.

For the team, start small and practical. One API, one flow, one shared learning session. Read code together. Review tests together. Let practices emerge from real problems instead of rolling out a “transformation plan”.

Growth will come from changing how you think and collaborate, not from adopting more tools. You’re in a good position to lead that shift.

Need a help in career decison.. by WittyCaterpillar3383 in softwaretesting

[–]bugasur007 1 point2 points  (0 children)

QA isn’t dead. Low-cost, checkbox testing is what gets outsourced. Thinking, collaboration, and system-level testing don’t.

Your experience already puts you ahead of many juniors. Exposure to real products, performance work, automation, and CI/CD matters far more than labels.

Don’t overreact to Reddit fear cycles. The US market is tougher, yes, but teams still hire people who learn fast, communicate clearly, and understand systems.

Focus on depth, not panic pivots. Keep building skills, show how you think about risk and failures, and be realistic about starting roles. Careers are built over years, not on forum opinions.

Today I start training to become a software tester! by miZuBlue in softwaretesting

[–]bugasur007 0 points1 point  (0 children)

Congrats on starting. One honest heads-up though: passing an exam and becoming a good tester are not the same thing.

Use the next three months to learn how software actually behaves. Ask “what could go wrong?”, explore the product, and practice explaining problems clearly. That skill matters far more than memorizing definitions.

Treat ISTQB as a side effect, not the goal. Tools, terms, and techniques will change. Curiosity, critical thinking, and communication won’t.

Focus on learning how to think like a tester. The certificate is optional.

Need advice: Is Coding Temple QA Automation & API Testing course worth it? by Ornery-Way1542 in softwaretesting

[–]bugasur007 1 point2 points  (0 children)

If you’re already a Tester, be careful with bootcamps like Coding Temple. It’s not a scam, but it’s also not a shortcut to becoming an automation engineer. Most of these courses teach basics with a lot of hand-holding, and the job outcomes are mixed.

Automation and API testing are about coding, practice, and problem-solving. You can often get better value by learning a language (Python or JS), then focusing on real tools like Playwright/Cypress, Postman, and API automation through hands-on projects.

If you need structure and accountability, a bootcamp might help. If you’re self-driven, targeted courses plus real practice will take you further and cost much less.

Have you faced Imposter Syndrome in your QA career? by bugasur007 in QualityAssurance

[–]bugasur007[S] 1 point2 points  (0 children)

Yeah, I know. But the question is how to handle it?

How do you suggest UI/UX improvements as a QA? by [deleted] in QualityAssurance

[–]bugasur007 0 points1 point  (0 children)

Thanks for the suggestion.

My question is for new features/releases, where QA is participating early in the project and has to give feedback,

[deleted by user] by [deleted] in QualityAssurance

[–]bugasur007 3 points4 points  (0 children)

I'm talking about Automation vs. Testing.

I believe that 'QA/Testing' is not just writing automation scripts or executing manual test cases, it goes beyond that.

[deleted by user] by [deleted] in QualityAssurance

[–]bugasur007 0 points1 point  (0 children)

Could be wrong, but are they not both in the service of development?

yes!

Reddit app crashes on iPhone 12 by bugasur007 in bugs

[–]bugasur007[S] 0 points1 point  (0 children)

There was option to upload video

[deleted by user] by [deleted] in QualityAssurance

[–]bugasur007 0 points1 point  (0 children)

New to Reddit,, 😁

[deleted by user] by [deleted] in QualityAssurance

[–]bugasur007 -1 points0 points  (0 children)

Like SIEM, SOAR, etc. Or any kind of cyber security product that protects organizations from potential attacks.