The soldier in his boxers was concerned about this picture going public and the ramifications on his continued enlistment. An unfortunate fear by anyone that has someone with a bird’s-eye view into their day-to-day work habits. But I would assume the photographer who took the picture was happy to see the soldier’s dedication to the mission and for preserving his life.
Do you trust the integrity of your development team to provide the access to the application that is needed for a tester to accurately discover, document and drive root cause analysis of defects? If the seeds of mistrust have been sown and there is a general lack of empathy between testing and development you can probably stop reading here. But if your organization has actually been able to avoid this fate then the adoption of something equivalent to the embedded reporting used by the United States military is a viable option. While conspiracy theorists point to the idea that embedded reporting allows the military to turn unbiased reporting into a propaganda machine for its own purposes, most embedded journalists in our country’s two most current conflicts feel quite differently. Most have come to say that they were able to more effectively utilize their pens by leaning on the resources of the military to get them to where they needed to be.
I would say that the truth is a shade of grey wherein a desirable amount of bias is built out of the reliance on people usually considered as adversaries. For example, the critical outside reporter; often driving for the truth, considers the military personnel to be an obstacle to the real story on the ground. Now we embed that reporter and insert them into a unit to live, eat, breathe and put himself in harm’s way with those same military personnel and a different kind of relationship develops. Developing a natural empathy towards the plight of the soldier on the part of the reporter, a sense of respect for the reporter “putting their money where their mouth is” from the soldiers. Both parties are equally concerned with returning from the engagement intact having done their jobs to the best of their abilities. On some level barriers fall, mistrust gives way to coordination and collaboration, mutual respect ensues and the entire effort is more cohesive.
The relationship typically manifests itself as a tester dedicated to a particular team or grouping of developers. But I’m also partial to a developer being assigned to a tester or group of testers. This idea of embedding resources that are typically stratified and separate into a single team lends the development process the opportunity to move towards a more TDD(test driven development)-like one. It also leads to decreased time to resolution and a more iterative defect resolution activity with greatly strengthened lines of communication between testing and development.
What makes all of this plausible is the idea that your organization will commit to one simple idea and that’s one of training and preparation of the resources that are going to be embedded. Whether it’s the developer learning some testing techniques or the tester getting some level of training in the technology platforms in play, it is an absolutely essential element. A boot-camp style training period so that the basics with respect to terminology and technique are understood would suffice.
From a staffing standpoint this is best achieved by pulling in junior development resources and walking them through a tour in testing and upwards through production support then on to full development duties. This helps acclimate your developers to your business. Knowing this probably won’t happen you could take a tester with an interest in development and embed them in the typical sense of tester-to-development only to then lose them once they believe they are ready to be a developer full-time and quit.
But before your developer turned tester bolts for more exciting opportunities in development and that embedded tester applies for a junior-level programming position at Google(do those exist?) you have an opportunity to groom a weel-rounded developer with testing on his/her mind and a tester who could lend their talents to a software automation effort before they go. Your organization can make good on promises of career growth and progression while still getting work done.
Live up to the definition of embed “to make something an integral part of” and you and your staff may find the results very satisfying and worth the effort and investment.
I came into testing in a similar manner – from technical support. My first testing gig was doing both technical support and testing – thus, any bug I missed before implementation came back as a call afterwards. Thus, I have a great appreciation for the cost of letting things slip into production.
Enhanced awareness of what the rest of the team does (and why) generally leads to better efficiency. A developer that has worked more closely with testers will know up front what information those testers will probably need for test planning. A tester that has worked closely with developers to troubleshoot and fix defects will tend to write better defects.