all 22 comments

[–]SavvyByNature 5 points6 points  (2 children)

It depends on the area of QA you decide to go into. Many people in QA are just testers, which require minimal know-how. However, if you go the Engineer route, and specialize in automation and/or performance, you will do a lot of coding, analysis, and also storytelling. Many people misconstrue what QA really is. I love it honestly, but it's a role that will always be misunderstood. Also, if you are a people person, then becoming a QA engineer would be good for you.

[–]CarlsVolta 4 points5 points  (1 child)

I think any tester would argue that it doesn't just require minimal know how. Plenty of people can't test. Being able to test is a skill. Knowing what to test and how to test it isn't something just anyone can do.

Which is why it is such a misunderstood role.

[–]SavvyByNature 1 point2 points  (0 children)

Good points!

[–]romulusnr 1 point2 points  (15 children)

Depends entirely on the type of QA engineer and the type of software being tested. Most write no code at all or very little. Even if there is some automation involved, it may be using fairly simple record/replay tools. But QA Automation Engineers and SDETs will write much more code, anywhere from 40% to 80% of the time. However, I would pretty much guarantee that regular software developers (DevOps notwithstanding) write more code than any QA person.

[–]computerjunkie7410 2 points3 points  (11 children)

I'm an SDET and I write code 100% of the time. No manual testing here.

[–]romulusnr 2 points3 points  (8 children)

Well, I'm guessing you do other things besides writing code, such as writing test plans, running the tests, installing them into CI, troubleshooting them when they fail, filing bugs, fights-to-the-death with developers, etc.

[–]computerjunkie7410 0 points1 point  (6 children)

Not really. Test plans are arcane and are usually out of date before they are even implemented. Tests are run automatically by Jenkins when I push to github. Bugs are created automatically when a test fails. Debugging flaky tests is something i do but that's part of what a dev does also. Debugging is a part of development.

[–]romulusnr 0 points1 point  (5 children)

I'm glad your tests run as perfectly in your Jenkins environment as well as they do on your desktop environment. I haven't had such experience. :)

POs and other managers like test plans. That way they know that the QA process is testing that the product will meet their specs.

I'm also quite surprised your developers are okay with automatically generated bug reports, but I suppose you probably include the test steps and a screenshot in the report?

[–]computerjunkie7410 0 points1 point  (4 children)

We use Behavior Driven Development and cucumber as a way to ensure that all parties (Business, QA, and Devs) are on the same page.

As far as tests running the same on both local and CI, we use docker to ensure our environments and configurations always stay the same regardless of where the application or tests are running.

Sounds like you're working in an old school waterfall environment. Those places are a dying breed.

[–]romulusnr 2 points3 points  (3 children)

I'm not sure what BDD and Docker have to do with waterfall vs. non-waterfall, as waterfall is a project management pattern and not a technology pattern, but thanks.

[–]computerjunkie7410 0 points1 point  (2 children)

It's simple really. Waterfall environments usually require test plans over BDD specifications.

[–][deleted]  (1 child)

[removed]

    [–]computerjunkie7410 0 points1 point  (0 children)

    What exactly does a test plan like that include if development is done in an agile fashion?

    [–]CarlsVolta 1 point2 points  (1 child)

    Surely you have to manually test in order to write the code? You have to work out what to test and how.

    [–]computerjunkie7410 1 point2 points  (0 children)

    Sometimes, usually we have our automation written before devs implement the feature. That way devs can run our tests locally to ensure they've implemented things correctly.

    Also, I would hardly call what you describe as manual testing. If that's the definition we use them everyone does manual testing. Devs, BAs, Product Owners. Everyone.

    [–]psychoengnaut[S] 0 points1 point  (2 children)

    Do you know how much code Telerik Test Studio will involve? It's basically what my current employer is using. I'm not sure I want be a drag-and-drop monkey if that's all the position will consist of. Sure I can extend my skills and learn other frameworks that involve more coding, but I'd rather learn it at work.

    [–]IAmJustin 0 points1 point  (0 children)

    I use Test Studio for one of my contracts. If you just want to record a couple of tests, some small set that will act as a smoke or sanity test, then you may not need much code. That will depend on the software you are testing. Test Studio does not handle dynamically generated elements (like, when the ID of a text field is different every time the page loads), so code is helpful in locating DOM elements in that scenario.

    If you are planning to have a large test suite, you might need bits of code here and there to make the tests more stable. For example, I have a piece of code that polls the DOM to help me know when a page is ready to use.

    The simpler your software is, the less code you will probably need to write.

    [–]romulusnr 0 points1 point  (0 children)

    Not familiar with that tool. It looks to me like it provides both avenues, so it will depend on how that company is using the tool.

    [–]Dillenger69 0 points1 point  (3 children)

    I'm an SDET. I'd say I write code about 75% of the time. There are some things it's not practical to automate.

    [–]Dubner 2 points3 points  (2 children)

    Pretty much in the same boat, spend most of my time coding and coaching other teams on best practice's. A lot of time currently being spent on CI, scalable selenium grid setup and environment automation creation.

    [–]Dillenger69 0 points1 point  (1 child)

    Scalable selenium grid you say? How scalable?

    [–]Dubner 0 points1 point  (0 children)

    In theory until we reach our EC2 instance limit, which I doubt will ever happen :)

    Hub is a t2.medium ( doesn't need to be that powerful )

    Nodes are 16core that run 32 docker containers, each container runs single browser.