3 ms·

I work in QA and I wish more developers thought this way. Also run your code before hand off. Please. If I had a nickel for every time I got a user story or bug

I work in QA and I wish more developers thought this way. Also run your code before hand off. Please. If I had a nickel for every time I got a user story or bug to validate and it immediately crashes then I would have a bunch of nickels. Which wouldn't be super helpful, but still. Please at least run your code, or ideally you should have CI/CD with unit tests, but we all know that isn't always the case especially in legacy Enterprise software.

debaserab2 8y ago
It's easy to make the assumption that developers haven't ran the code at all, but I find in reality that's rarely the case. In my experience it almost always has something to do with an unexpected environment variant. It's very easy as a developer to get so comfortable with the "happy path" of navigating code that you forget to look outside of the happy path when devising your test cases. It takes time to learn to identify the test cases you're not regularly exposing yourself, and these test cases are often ones not described in a requirements or specs doc.
- rcollyer 8y ago
  As a QA dev, myself, I run across this occasionally. For a recent bug, the dev couldn't reproduce it, yet I could consistently. The difference: the width the window we were using; he was using the default, I was not. Most of the bugs I run into are not config dependent, so it is always surprising when one is.
- egfx 8y ago
  This! I spent the first half of my career in QA. This second half in dev. Coming from QA I'm very meticulous about everything and yet as soon as it leaves my hands something comes up. This is why I'm a big proponent of QA. I had a chat with someone who was pretty much dismissing QA because they had the mindset of I'll just test it or my cofounder will help. It's terribly surprising what goes down outside the confines.
phaedrus 8y ago
As a developer this bugs me too. I once was team lead on a team which had two developers (bad hires) who seemed to believe that it was only their job to write the code, someone else's job to run it and test it. I started putting "and test the code" in the tasks; a team member successfully lobbied our manager that that was another task. So now I had to write 2x as many tasks, and the predictable result happened: the developers who didn't test their own code grabbed all the "write the feature" tasks and banged them out rapidly (easy to do when you don't make sure it works!) The more experienced developers were left to pick up the "and test what you wrote" tasks, which really amounted to rewriting the bad code. Then management said, "Why are you (senior developers) wasting so much time testing code? It generally seems to work and we can always fix it later." There was just no way to win. I'm glad I don't work in that environment anymore.

debaserab2 8y ago

It's easy to make the assumption that developers haven't ran the code at all, but I find in reality that's rarely the case. In my experience it almost always has something to do with an unexpected environment variant. It's very easy as a developer to get so comfortable with the "happy path" of navigating code that you forget to look outside of the happy path when devising your test cases. It takes time to learn to identify the test cases you're not regularly exposing yourself, and these test cases are often ones not described in a requirements or specs doc.

rcollyer 8y ago
As a QA dev, myself, I run across this occasionally. For a recent bug, the dev couldn't reproduce it, yet I could consistently. The difference: the width the window we were using; he was using the default, I was not. Most of the bugs I run into are not config dependent, so it is always surprising when one is.
egfx 8y ago
This! I spent the first half of my career in QA. This second half in dev. Coming from QA I'm very meticulous about everything and yet as soon as it leaves my hands something comes up. This is why I'm a big proponent of QA. I had a chat with someone who was pretty much dismissing QA because they had the mindset of I'll just test it or my cofounder will help. It's terribly surprising what goes down outside the confines.

phaedrus 8y ago

As a developer this bugs me too. I once was team lead on a team which had two developers (bad hires) who seemed to believe that it was only their job to write the code, someone else's job to run it and test it. I started putting "and test the code" in the tasks; a team member successfully lobbied our manager that that was another task. So now I had to write 2x as many tasks, and the predictable result happened: the developers who didn't test their own code grabbed all the "write the feature" tasks and banged them out rapidly (easy to do when you don't make sure it works!) The more experienced developers were left to pick up the "and test what you wrote" tasks, which really amounted to rewriting the bad code. Then management said, "Why are you (senior developers) wasting so much time testing code? It generally seems to work and we can always fix it later." There was just no way to win. I'm glad I don't work in that environment anymore.