I'm a geek who has worked with computers since before I care to remember. Went though various IT roles, from desktop support, sys/net admin, software QA, and currently in the role of SDET.
Thanks for writing this and opening the discussion. I agree with you in that it should be a combination of both approaches. Too many times, I've felt like developers think of QA as a second class citizen. I've been refered to as "oh he's just QA..." as if we were beneath them. Ironic because it's often us "mere QA" folks who catch potential issues and make the company and product be the best it can be. It's also funny how a "mere QA person" at times can school a developer on how a lot of issues can be avoided with simple tests and caught earlier rather than later. I remember some things taught in some introductory computer science courses (at least the ones I took) was the concept of defensive coding. Yet that concept seemed foreign to a so-called senior level developer. The more issues we caught before release, the better everyone looks. QA are your colleagues and peers supporting you, the company, and the clients. Let's stop the arrogance.
From the developer standpoint, I would be one of the ones who write coded tests as I develop, and often think of test cases to watch out for as I go. This, in my opinion, while it can be sometimes boring and tedious, overall leads to higher quality and confidence that the build/code is good. That's not to say it's perfect. I am guilty of wanting to skip writing tests sometimes just as anyone else. It takes discipline, but results in better quality in the end. From what I've seen, a developer can be brilliant in what they create, but in the end, we are still human and sometimes a 3rd party perspective can lead to unexpected conditions that may negatively impact the project/application. I've not met a developer that was so brilliant that there was never a bug or any edge cases that weren't already considered and handled.
This is why we still need QA and developers working together and respecting what each other do, because we have a common goal to have a good release of quality software. Designing and developing software is as much a full time job as is good testing and QA. Some might even go so far as to say QA is often more difficult. The way I see it, each side has its own challenges. Let's all work together for the common good.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Thanks for writing this and opening the discussion. I agree with you in that it should be a combination of both approaches. Too many times, I've felt like developers think of QA as a second class citizen. I've been refered to as "oh he's just QA..." as if we were beneath them. Ironic because it's often us "mere QA" folks who catch potential issues and make the company and product be the best it can be. It's also funny how a "mere QA person" at times can school a developer on how a lot of issues can be avoided with simple tests and caught earlier rather than later. I remember some things taught in some introductory computer science courses (at least the ones I took) was the concept of defensive coding. Yet that concept seemed foreign to a so-called senior level developer. The more issues we caught before release, the better everyone looks. QA are your colleagues and peers supporting you, the company, and the clients. Let's stop the arrogance.
From the developer standpoint, I would be one of the ones who write coded tests as I develop, and often think of test cases to watch out for as I go. This, in my opinion, while it can be sometimes boring and tedious, overall leads to higher quality and confidence that the build/code is good. That's not to say it's perfect. I am guilty of wanting to skip writing tests sometimes just as anyone else. It takes discipline, but results in better quality in the end. From what I've seen, a developer can be brilliant in what they create, but in the end, we are still human and sometimes a 3rd party perspective can lead to unexpected conditions that may negatively impact the project/application. I've not met a developer that was so brilliant that there was never a bug or any edge cases that weren't already considered and handled.
This is why we still need QA and developers working together and respecting what each other do, because we have a common goal to have a good release of quality software. Designing and developing software is as much a full time job as is good testing and QA. Some might even go so far as to say QA is often more difficult. The way I see it, each side has its own challenges. Let's all work together for the common good.