4
atheist
14d

Test things you don't think you can get right on first try or are easily screwed up by someone that doesn't have the understanding. Most other tests aren't needed.

Comments
  • 1
    Quote from ThePrimagen, very insightful.
  • 1
    It's also tested very well from people who're just motivated to take you down. Worked somewhere where the whole sales team (car sale people) tried everything to break the software just to flip the finger afterwards. Besides that, they also tested the happy flow very well.

    That company had the best software regarding amount of bugs where i've ever worked. On top of that, we did especially deploy on Friday so you had a whole weekend for if you fucked up. That's dedication
  • 2
    Test the stuff you know you're going to break.

    And if there's anything you're confident you're not going to break, test that even more.
  • 4
    I test things cuz I don't trust myself

    it's always the stuff you don't expect
  • 1
    @retoor yeah testing should have a red team and blue team! like cybersecurity does

    then it could be fun
  • 2
    @jestdotty it's always the things you don't expect indeed, so it makes a lot of sense that two people test, preferably one with no programmers mind.

    The manual tested software (that company didn't do unit tests) beated the unit tested software I wrote easily. The unit test software didn't have manual testers and even the devs didn't manually test after writing tests.

    Two teams is an idea. Both teams start with a budget of thousand euros for the yearly department party. The team that wins get 50,- from other team. Resulting that end of the year one team go's go carting end of year and other team has a pizza margeritta at the office.

    The teams could share a budget to fight the system
  • 1
    @retoor yeah I love manual testing! people using your software is really good. though some bugs are just embarrassing and should've been obvious if I wrote some tests so ye. like it's easier for you to check and make sure when you're building it than it is for you to deploy, then later someone tries the feature and questions if they used it wrong or it's actually broken, they have to figure out how to open a ticket, do ticket etiquette, have to successfully explain to you what it is and then you have to go get caught up on that part of the code and do all the same things you would've done had you bothered testing it the first time, and then you have to tell them when it's fixed and deploy again. hassle

    had an intern once who didn't manually test. like he didn't even run the code before committing. I kept telling him to at least run it. he wouldn't. he was such a disaster. we had him 3 months and the guy couldn't even change the text in a button successfully. wtf
  • 2
    @jestdotty

    Starter -> test because insecure.

    Experienced -> doesn't test because confident.

    Prof -> experienced both, does tests again

    (Refuse to use the Junior/Medior/Senior thingy)
Add Comment