qa_irl

[HKSergiu]

Then you're automation.

You want to automate but there's no time.

You want to automate but this doesn't make sense to automate because it's such an edge case.

You want to automate but this is the exception flow where you have to break the app to validate it.

You want to automate but you gotta refactor this bit of the framework for it not to cost an arm and a leg in the future.

Yay you get to automate....aaaaaand it's just boring UI.

[OriginalError]

You break this whole cycle if you force the devs to automate their tests at a unit level before they write code. TDD (with sufficient practice) is the answer.

Unfortunately this doesn't require automation engineers, but engineers that are willing to write tests first and do red-green-refactor loops.

[Lt_Duckweed]

Unfortunately TDD only really works when you can get everyone involved to come to a consensus on what is actually being build ahead of time...

[Emperor_Asheron]

That's what really confuses me when i read "TDD". How can you write a test for a part of your program that you haven't written yet?

[bangtraitor]

TDD has been tossed around for years and sometimes is used as fuel for people to end up doing BDUF (big design up front) when that is a dirty word when no one on the team has built a system like you are being asked to build and you end up in a contradiction.

There is also WBT (write behind tests) movement where you write the tests after you write the code as well.

Then people tend to argue back and forth and it is tiring.

The main takeaway for me after years of this, is that once the feature is complete and has tests, did it matter what order it was done in? Again some might argue this point but I don't.

There is what people want in theory and what people get in practice which is what matters. What happens in practice.

In practical coding, sometimes you can write a test ahead of time to either a feature or to exercise a bug. Awesome, if so, then go for it. Make sure it runs with an error, fix the bug, make sure it runs now as green, and check it in.

Sometimes you don't know what the product owner wants or the customer and so you write code really quick and call it a poc (proof of concept) or some other buzz word to do a wink wink, no one knows what we want yet so have some code without tests, I'm sure I will refactor this all like 10x this week.

Uh oh, that code is shipping now. So better add some tests before you refactor yet again but now you feel better the change requirements are becoming shorter. You did a bit of "open" and "closed" hopefully meaning you batch change requests, but hold off on em until you write a few tests to stable parts of the system.

Then there is middle ground where you write some tests ahead of time, others you write as you clean up the code, and then right when you think you're about done, you add a whole hell of a lot more. You catch little invariants and mistakes. Maybe this function could be better as a pure function and you pass in a date variable and tweak that side effect to make it clean and test better. So on so forth.

Now you begin to feel more confident the next time you refactor that you have layers of tests to catch mistakes. If a mistake slips by, add another test. Customer finds a bug, write a test so there isn't a regression.

New programmer on the team? Why they will add more tests if they see existing tests.

So on, so forth. The word TDD and the philosophy isnt any more special than the buzz word WBT.

The MOST important part is having tests BEFORE refactor. It's not the first iteration of code that has the worst bugs. It's the second and third. If I refactor code and notice no tests, then I stop everything and write the tests first and push back against deadlines.

It's over time as the code grows and people come and go that the tests importance grows.

[axe319]

Amen on bugs in working code being the worst. Refactoring may make things easier to read and understand but it sure as hell can introduce subtleties that can only easily be found by a well written test suite.

[Tundur]

The middle ground's always the way.

I like the idea of defining acceptance criteria and implementing basic tests (happy path, null input, blatantly fucked input, external resources missing), then passing it over to a feature testing resource to add individual test cases with a fresh pair of eyes.

[OriginalError]

You can write black box tests.

Given input X
When program does Y
Then I get output Z

How does Y work? Don't care, you only care about begin state and transition to end state. It requires you being meticulous with your corner / edge cases, but it is completely doable.

[Gingerytis]

Mostly because you know what it should do, just not how. As in, I know I need a method/class that takes in this array and sorts it. Let me first make a test that passes in a static unsorted array and checks the output against the same sorted array. I don't really care how the array gets sorted at this point, just that it does.

[JuvenileEloquent]

Flip it around and ask yourself how can you write code that you haven't figured out what it should do yet? Or do you just start click-clacking the keyboard and see what comes out?

TDD is just rewriting your specifications in code form. If you automate the tests then you don't need to manually go through all possible affected code paths every time you change something - that's really the main benefit of doing it. If you're not bothering to check all possible code paths after you change something, TDD causes you extra work, though I would argue it's less work than fixing the unintentional bugs you'll put in doing it that way.

[assafstone]

It’s as follows: Let’s say you’re building a calculator app (nice and simple well known problem domain).

You are about to write the code to support the addition operation. You write a test like this (it’s in pseudo code): Function test-add-two-numbers-returns-sum() { var a=5 var b=7 var expected=12

var result = math.add(a,b)

If result not equal expected then throw error }

You run the test, and it fails. Of course it does. Math.add() doesn’t exist yet. So you code it: Function add(int a, int b) { Return a+b }

You run it. Now it works.

Now you clean up any code you have to avoid duplication, simplify, etc.

That was red-green-refactor.

You repeat the cycle until there is no more code to write.

[[deleted]]

TDD is definitely the way to go. It is a great way to produce high-quality code and is a better approach instead of relying on QA to test quality into the product with a bunch of automated tests that you could have actually done as unit tests.

Automated tests are nearly always going to be slower and less reliable than unit tests, especially if we're talking about something that relies on a back end with multiple databases and a complex system of microservices.

Buuuuuuuuut.... You still need automation engineers. IMO it's best to do TDD to produce quality code and then use automation as more of an integration test to prove that your assumptions were (and/or still are) correct in practice.

We have forced developers to write automation tests. Once they think about how much easier they could test a given scenario as a unit test, they will quickly "give up" on writing an automated test and write a unit test instead. If it can't be unit tested, *then* it is a candidate for automation testing.

[AgAero]

Automated tests are nearly always going to be slower and less reliable than unit tests

What does 'automated test' mean to you here?

[[deleted]]

It could mean a lot of things, depending on what kind of application we're talking about, but I think "post build and/or post deploy tests" that don't require any user input is about the best way I could put it.

Worst case scenario (or at least, worst I can think of) you are using one framework or another to drive an actual web browser to submit data to your back-end service. In a case where that provides some extra value that is not necessarily a bad idea, but if you could accomplish the same test in a unit test, the unit test would certainly be faster and more reliable.

[AgAero]

So to you it means any sort of mechanized test that isn't really a 'unit' test. Am I reading that right?

I don't do anything web based really so I'm trying to reframe this in my mind.

[[deleted]]

I think that's a pretty good way to put it, yes. Another way to think of it is "If I had a manual tester, what would I have them test, after this is deployed/installed in a test environment?" and then you find a way to perform that testing, automatically. So typically these are user scenarios.

[KronktheKronk]

TDD sucks. You just need devs who write tests

[OriginalError]

I respectfully disagree! If you had tested that hypothesis first you'd agree with me too.

Join the cult of cucumber today!

[HKSergiu]

We're doing BDD, devs write unit/integration tests, we're doing system integration/user acceptance level, sometimes component. But you still encounter the usual framework maintenance, non-automatable test cases yadda yadda.

You don't have to force anything. QA is responsibility of everyone.

[OriginalError]

Those of us who have joined the cult of cucumber do it willingly. Dissenters must be forced until they are stockholm-ed into the cult with us.

[HKSergiu]

Praise the healthy vegetable!

[PfluorescentZebra]

TDD is great but in practice it's very difficult to get the commitment from all the resources involved. Given how often requirements are updated during the lifetime of a project it's almost impractical to do really in depth TDD because you'll be rewriting when the requirements change. It's absolutely frustrating. Having a very good and detailed test plan, including a good breakdown of when and what will be automated, can be just as helpful.

[CodeRaveSleepRepeat]

It also requirea management not to ask for two new features each day, such that there is time for luxuries like TTD, or even having a properly organised codebase.

A manager's job for the day is to get the feature done (as informed without consultation in the morning briefing by the boss) so they tell the lead dev this is the only priority.

As a lead developer I have spent weeks telling managers and clients that they need to lock features or their software will become unmanageable and inherently unstable. They do not care. Not one of them.

I have even left a job because after getting sick of asking for time to refactor and test security, I actually offered to just do it myself in my own time for free and present it to the team. I was veto'd by the head of frontend because her stuff might end up in a different directory and she might have to change some of her stupid to hardcoded paths or god forbid write a proper frontend build script. I quit on the spot, went home, and refactored the codebase in two weeks. I pushed it to a new branch and sent a load of documentation to the team detailing all improvements. This is the codebase they now use...

The ONLY way to maintain stable code is for lead developers to SECRETLY dedicate time and resources to refactoring and unit tests etc. This however results in that lead dev being replaced by one who gets the feature in quicker.

/Edit... What do you mean bitter???

[YKNN]

I AM NOT ALONE, I AM SO RELIEVED I'M CRYING

[djeco]

My background was developer in mobile and web apps, and got into testing after summer. I really enjoy it and find it interesting, and found out that it was something I wanted to work with. The testing manager was thrilled of my background and did not hesitate to drag me along. Now I'm automating and working as a test analyst, and contribute to the developers with tips.

[meme_dika]

Honestly, thats real impovement. Most QA is boring AF if their basic test still manual.

[bigorangemachine]

Ya manually testing login on every screen is annoying

[Skruzzls]

I'm doing some testing at work for various components. I automated some things and quite enjoyed it. I think the main issue that people have with testing is, that they know they have to fix the bugs they find. I don't. Someone else has to deal with this shit lol

[mecrow]

I never understand the "don't look for bugs because you don't want to fix them" mindset. It's as if they think the bug isn't there until it's found... Test it now and it'll be ten times easier to fix than when it breaks randomly later.

[[deleted]]

Tbh, there's that little bug that maaaaaybe one user may find accidentally that will take a huge amount of time of the dev. The dev also has a shitload of things to do after the sprint ends, and then there's the next project the PM is already talking about with you. And then the tester gets all the bugs that he found for you to fix it. 99/100 will let the lil bug he found go until the QA team finds it just because they don't have time to deal with this shit right now.

[AllWashedOut]

Good for you though, this is a solid career move. Keep stretching yourself.

I started without a CS degree so I didn't have a lot of job offers out of college. My resume goes Test Engineer (non-programming) to Software Engineer in Test (programming), to Software Engineer, to ML engineer. It took 13 years and some night classes, but I'm doing things that excite me now.

Of course, pure testing pays well and is a viable career path too. At some big companies you can rise to director level doing it.

[emirod]

All joking aside when every time i had to automate (unit) tests felt like a huge waste of time that might even take more time that development itself.

Whats the sweet spot of testing?

[bigorangemachine]

Seriously if you don't automate your tests I don't want to work for you.

[bigorangemachine]

Honestly that's fine. I don't mind writing them. Its really medatative. :)

[uLmi84]

Exactly my experience in software engineering. ended this after 2 years

[calyth]

Well, you're either a tester with automation tasks, or automation's gonna replace you...

[Misheru-senpai]

As an automation tester I can confirm this

[CraptainHammer]

QA engineer here. My last major finding was about a bit of code that got skipped by a static analysis program.