Should Programmers Spend Time as a QA Lead?

My job title is "Software Developer," yet in my time at this company, I have had the opportunity to fill many different roles. As I move forward in my career as a developer, a question arises. Should programmers spend time as a QA lead/software tester? My answer is yes.

When I started in the programming field, I (as did others, I'm sure) would use software applications and think, "If I had developed this application, it would work much better." Now being in the field for a few years and doing different jobs that relate to the software lifecycle, I at times find that we as developers lose sight of the user's experience. As a software tester, I was responsible for making sure that the applications my co-workers developed represented the customer's needs and desires. Does it do what the customer wants? Does it look good? Is it easy to navigate? Is it intuitive? What I have found as a developer is that we generally do at least one of these things well, but we lose sight of the others. We make software, and we make exactly what the customer wants. Developers, in general, leave the question of "does it look good" to the testers and the graphic designers. Is this right? I don't think it is. I think developers need to get away from focusing only the functionality of the code, and try to gain insight into the other aspects of the application. Spending time as a quality assurance team member or a software tester might allow developers to gain this vision.

While using Kanban boards can help us focus on a story's lifecycle, some areas can still be lacking. We do a great job of creating user acceptance tests that mirror the customer's need. Our coding is second to none. Code reviews allow us to share code and catch potential code "smells" that a programming pair did not. However, when we get to QA and design reviews, and we fall short. We find things that would have been caught if we had only run the application. Our user acceptance tests fill in data that we know should be there, we get no failures, and we call the story done for the coding queue. I think if we took a more holistic view of our work, we may find things we overlooked. If we adjusted our Kanban ever so slightly, we may improve our process and reduce our kickbacks from QA and Design. One of the actions I suggest taking is breaking our coding queue into three different sections: Code, Internal code review, and Internal QA review. Doing this would force us to run the application, manually walk though a story's lifecycle, visually inspecting the UI and insuring that our story meets the customer's needs and also reduces the amount of kickbacks and time fixing bugs and missed requirements. If we also spent some time in a QA/Software tester role, we would see our applications in a different light, which would ultimately enable us to become more well-rounded developers.