|
Mniot posted:Why are you even talking to them? Why are they even talking to you? Will they invite you to come on-site to get slapped? Yeah, there's the concept of interviewing at a place you're not super into on the off chance they might change your mind, and also to get some interview practice in, but I would say this is not one of those places. The interaction you already had says there's a good chance their company norms are hosed. I would be wary of drawing any conclusions about norms or internalizing feedback about your performance from such a place. It's completely tainted, just move on before they gently caress with your head anymore.
|
#
?
Apr 13, 2017 16:31
|
|
|
|
| # ? Jun 3, 2024 18:48 |
|
|
Slightly off-topic but related to programming job question: What kind of skills do you want your QA/testing people to know, for testing sites in a browser and Android/iPhone apps? Of course the person needs to know how to illustrate/document and reproduce the problem, and find the version of the device or browser, but what else is essential?
|
|
#
?
Apr 24, 2017 20:06
|
|
|
It depends on your exact expectations but ideally they would also have some minor technical understanding about how web pages get served up, client-side vs server-side code, etc. Also familiarity with non-functional requirements like performance, accessibility, multi-lingual support. Understands the concepts of bug severity and priority.
|
|
#
?
Apr 24, 2017 20:14
|
|
|
How to clear cache and refresh the page mainly.
|
|
#
?
Apr 24, 2017 20:15
|
|
|
I think being familiar with console logs/network error codes is useful. Knowing what it means when a variable is undefined. And the different between 400 or 500 errors is also pretty useful. That usually the first thing I check whenever something goes wrong.
|
|
#
?
Apr 24, 2017 20:18
|
|
|
Bob Morales posted:Slightly off-topic but related to programming job question: I would say some actual coding knowledge/experience in the domain. It's not very helpful to say "I clicked here and it broke". Being able to inspect console logs, describe what the DOM looks like, if it's a styling or functional issue, etc, is very helpful. Also some familiarity with JavaScript unit/integration test frameworks, so they can actually spend most of their time writing integration tests instead of manually testing things.
|
|
#
?
Apr 24, 2017 20:20
|
|
|
With mid-to-high end QAs, I'd expect them to be able to automate their jobs. There's a lot of good tools for that now.
|
|
#
?
Apr 24, 2017 20:25
|
|
|
Skandranon posted:Also some familiarity with JavaScript unit/integration test frameworks, so they can actually spend most of their time writing integration tests instead of manually testing things. If you know Javascript/OOP pretty well, but next to nothing about unit testing/any automated testing of any sort, where is the best place to get started with that?
|
|
#
?
Apr 24, 2017 20:25
|
|
|
Grump posted:If you know Javascript/OOP pretty well, but next to nothing about unit testing/any automated testing of any sort, where is the best place to get started with that? Not personally being a fan of unit testing... it depends on your environment. There's no shortage of articles which will point to the framework(s) used for various platforms. I'm currently using Karma and Jasmine for testing a large Angular SPA. This was also posted earlier to much praise: http://artofunittesting.com/
|
|
#
?
Apr 24, 2017 20:30
|
|
|
Grump posted:I think being familiar with console logs/network error codes is useful. They've almost doubled in size in the last 4 years and when I was there they really didn't have anyone on staff who did quality - it was pretty much 'everyone in the company check out the new site/app for 2 weeks and help find bugs'. I kind of want to show her some cool browser plugins, how to use the inspectors and console, but at the same time I don't want to over-complicate things for her and kind of just want to sit back and see how it goes for a month or so. She doesn't really have any programming background except a college HTML/CSS class. And, I can sympathize with the developers when someone who knows just enough to be dangerous starts to try explaining a bug on their level (especially when they don't know what's actually going on behind the scenes).
|
|
#
?
Apr 24, 2017 21:01
|
|
|
Skandranon posted:Not personally being a fan of unit testing... Why not?
|
|
#
?
Apr 24, 2017 21:18
|
|
|
idk. Being able to decipher the console was huge to me when I first started at my company. I also felt more useful when I could troubleshoot things by myself, even if it was only a few things. I can't imagine someone who just wants to do the bare minimum without really understanding why things are breaking. That's the kind of stuff I really wanted to know and I think it's made me a better developer for it. Even if she doesn't know how to write code, maybe she'll end up having a motivation to learn while in a QA position. Skandranon posted:Not personally being a fan of unit testing... it depends on your environment. There's no shortage of articles which will point to the framework(s) used for various platforms. I'm currently using Karma and Jasmine for testing a large Angular SPA. sweet. Everything I do at my job is me just manually trying to break things, and I'd love to dive in to automated stuff.
|
|
#
?
Apr 24, 2017 21:20
|
|
|
Jose Valasquez posted:Why not? I do not personally enjoy the process.
|
|
#
?
Apr 25, 2017 00:22
|
|
|
The #1 skill I liked in QA folks was precise error descriptions. Tools can help out with that, but I'd still prefer "On the User Settings page, clicking 'Post History' leads to a broken page" over "Malformed post-history request receives 403 response" with 0 indication of how that particular request was formed.
|
|
#
?
Apr 25, 2017 00:37
|
|
|
JawnV6 posted:The #1 skill I liked in QA folks was precise error descriptions. Tools can help out with that, but I'd still prefer "On the User Settings page, clicking 'Post History' leads to a broken page" over "Malformed post-history request receives 403 response" with 0 indication of how that particular request was formed. Yeah, this is actually what is nice about my QA team, in that they are separate from the team that writes tests. They know precisely gently caress-all about programming and it's great, what they do know is to be extremely descriptive to make up for it. They don't know how to inspect network traffic, so they aren't going to try and tell me an API is broken. They don't know how CSS works, so they aren't going to try and tell me a property isn't set correctly. It's just gonna be: "I clicked on the Report List page from the main page and there should be 12 reports per page and it's displaying 11 reports per page." Awesome, that is genuinely the most useful thing you could have told me. I need to know exactly what someone did to make a thing break, in as many steps as possible. That makes my life so much easier. Vincent Valentine fucked around with this message at 05:08 on Apr 25, 2017 |
|
#
?
Apr 25, 2017 05:05
|
|
|
Skandranon posted:I do not personally enjoy the process. i don't want to pick on you or anything, but how do you validate your code if you're not doing unit testing? also how do you handle interface design without writing unit tests as a consumer of your interface?
|
|
#
?
Apr 25, 2017 18:05
|
|
|
the talent deficit posted:i don't want to pick on you or anything, but how do you validate your code if you're not doing unit testing? also how do you handle interface design without writing unit tests as a consumer of your interface? My giant perfect brain handles all that flawlessly. See the "Feynman Method" More seriously, I recognize it has value, I just do not enjoy it. I find it tedious and unfun.
|
|
#
?
Apr 25, 2017 18:26
|
|
|
Skandranon posted:
Nobody has ever written unit tests because they are fun to write.
|
|
#
?
Apr 25, 2017 19:47
|
|
|
Skandranon posted:More seriously, I recognize it has value, I just do not enjoy it. I find it tedious and unfun. That's funny, because I find it tedious and unfun to pay someone to debug code that should have been written properly in the first place.
|
|
#
?
Apr 25, 2017 19:57
|
|
|
dantheman650 posted:Nobody has ever written unit tests because they are fun to write. So because no one likes them, no one can ever express displeasure over such? Pixelboy posted:That's funny, because I find it tedious and unfun to pay someone to debug code that should have been written properly in the first place. God willing, may we never meet in real life.
|
|
#
?
Apr 25, 2017 20:18
|
|
|
Writing a unit test for a feature you just wrote yourself is stupid. "Oh look, i came over here to the _test file with the exact same mental model of the feature, totally gonna wring some bugs out of this instead of coding the same thing again!"
|
|
#
?
Apr 25, 2017 20:21
|
|
|
Unit tests aren't for you, they are for the next guy
|
|
#
?
Apr 25, 2017 20:37
|
|
|
Jose Valasquez posted:Unit tests aren't for you, they are for the next guy  Got anything more than a soundbite? I hate this dogmatic poo poo. QA team writing tests, higher level things like integration tests, UAT, nope nope nope none of that could make a worthwhile process. Only the exact same coder writing the exact same function backwards will save us from bugs. Also, next "guy"?
|
|
#
?
Apr 25, 2017 21:45
|
|
|
Why bother to test anything? Just throw it over the wall to QA or ops. Isn't that what those people get paid for?
|
|
#
?
Apr 25, 2017 21:48
|
|
|
JawnV6 posted:Writing a unit test for a feature you just wrote yourself is stupid. "Oh look, i came over here to the _test file with the exact same mental model of the feature, totally gonna wring some bugs out of this instead of coding the same thing again!" I think there's value in immediately verifying that your code does what you expect. I've definitely written bugs that were just straight up mistakes and weren't related to my mental model of the problem.
|
|
#
?
Apr 25, 2017 21:52
|
|
|
fantastic in plastic posted:Why bother to test anything? Just throw it over the wall to QA or ops. Isn't that what those people get paid for? jony neuemonic posted:I think there's value in immediately verifying that your code does what you expect. I've definitely written bugs that were just straight up mistakes and weren't related to my mental model of the problem.
|
|
#
?
Apr 25, 2017 22:07
|
|
|
Nobody is advocating that unit tests are the only form of QA.
|
|
#
?
Apr 25, 2017 22:11
|
|
|
JawnV6 posted:
If you don't see the value in the next person (forgive the earlier colloquialism) being able to verify that their changes didn't break existing functionality I don't know what to tell you
|
|
#
?
Apr 25, 2017 22:14
|
|
|
JawnV6 posted:whatever other garbage you'd like to ascribe to me. JawnV6 posted:Unit tests, of course, being the only possible way to do this verification. Attaching with a debugger, literally any other kind of test suite, none of that could be used instead. Unit tests written by the dev themself are The Only Way.  I'm just saying that I've personally found unit tests give a good return on time invested, not that every other kind of testing is valueless or not important for other reasons. There are plenty of ways to verify your code, but unit tests are still there next time someone is monkeying around in that bit of code and I think that's useful.
|
|
#
?
Apr 25, 2017 22:18
|
|
|
I enjoy writing unit tests because I enjoy not worrying that I'm breaking code I wrote 20 minutes ago with code I'm writing now. I also consider "past me" and "current me" to be different people.
|
|
#
?
Apr 25, 2017 22:19
|
|
|
Jose Valasquez posted:Unit tests aren't for you, they are for the next guy In this case, you're the next guy. Come back to a project that you haven't touched for a few months, you'll be singing the praises of past you.
|
|
#
?
Apr 25, 2017 22:26
|
|
|
Sometimes unit test good. Sometimes unit test bad.
|
|
#
?
Apr 25, 2017 22:46
|
|
|
Unit tests are not always the correct form of automated tests. Some form of automated tests is always correct, though.
|
|
#
?
Apr 25, 2017 23:03
|
|
|
If I ever teach a programming class, the first thing I'll write on the board is, "All dogmas are bad." And the student who smugly points out that that is also a dogma gets ejected from the class.
|
|
#
?
Apr 25, 2017 23:12
|
|
|
JawnV6 posted:Only the exact same coder writing the exact same function backwards will save us from bugs. I agree that "unit tests" are generally dumb and bad if by "unit test" we mean a test that breaks if you make any change to the original function... And when it comes to web programming, testing individual functions is usually awful in my experience, leading to exactly the "same function backwards" bullshit that I think you're referring to. Unit testing gets better when you're more willing to accept something larger than "any function" or "any publicly visible function" as a unit. It can often be way better to treat an entire API method as a "unit" and test that, bringing up your entire application and an empty database just for the test, like Rails let's you. Then you don't care what function or database or RPC calls your service makes, you just check that you get the right output when you give it some input.
|
|
#
?
Apr 25, 2017 23:22
|
|
|
JawnV6 posted:
I'm not saying that it's the right approach but... I was at a place where there was a core platform and two products that used it in a single repo. They used unit tests extensively and the engineering culture had a motto of, "If my change broke your code it's your fault for not having a test that would catch it." Person on Product A could make a change to Product A and Platform, and push it to the test runner. If tests passed they could merge it into master knowing that Product B wasn't affected, without needing to run Product B. That's probably the ultimate, "The next guy"
|
|
#
?
Apr 25, 2017 23:28
|
|
|
oliveoil posted:It can often be way better to treat an entire API method as a "unit" and test that…. As a bonus with this strategy, if you're willing to publicize your unit tests, you've maybe just created some API documentation that is guaranteed to be accurate, because you can't release when it goes wrong. You've also, hopefully, given your developers an extra indication that they've made a breaking change to your API, if the unit tests suddenly start failing because you added a new field that they're not passing, or whatever.
|
|
#
?
Apr 25, 2017 23:31
|
|
|
oliveoil posted:It can often be way better to treat an entire API method as a "unit" and test that, bringing up your entire application and an empty database just for the test, like Rails let's you. Is that really unit testing at that point?
|
|
#
?
Apr 25, 2017 23:32
|
|
|
NewForumSoftware posted:Is that really unit testing at that point? No, but fixating on what to call your tests is dumb and a waste of time.
|
|
#
?
Apr 26, 2017 00:30
|
|
|
|
| # ? Jun 3, 2024 18:48 |
|
|
JawnV6 posted:The #1 skill I liked in QA folks was precise error descriptions. Tools can help out with that, but I'd still prefer "On the User Settings page, clicking 'Post History' leads to a broken page" over "Malformed post-history request receives 403 response" with 0 indication of how that particular request was formed. Even specifying a 403 over "and it broke" is manual QA gold. If she can replicate the terminology used in the spec (stop laughing some places have them) it's platinum level.
|
|
#
?
Apr 26, 2017 00:44
|
|
