I never thought that this needed a blog entry of its own since this has been a common practice in all the Agile projects I have done in TW. But apparently it isn't so easy in other organizations.
A “Dev Box” is basically a developer machine on which active development happens. The idea of “Dev Box” testing is to get the QA on the team to do a quick sanity test of the story on a developer machine before the final checkin of the story is done and the developer moves the card to Development Complete or Ready for Test.
It is as informal as a developer pair shouting out to a QA on the team “Hey, we think we are done with the story, can you do a quick round of Dev Box testing before we call it dev complete ? “ and the QA coming over to the dev pair station and doing a quick test. This usually takes no more than 15 mins.
Even though this sounds very basic, it has the following advantages
* Reduces the wait time to find defects as the QA need not wait for a build to be churned out and deployed on an environment, hence providing quick feedback to the developers.
* It provides more insight for the developers to look at how a QA is testing the application and vice versa.
* It also aligns developers and QAs towards building a much better quality product by having quality discussions much earlier in the cycle with a tangible story at hand. Sometimes the QA might have useful inputs in how a widget plays on the web page and it might be just a quick fix enhancement which the developers can jump on to during the testing session itself.
Apparently this is not quite easy as it sounds in organizations where cross functional teams are not a common practice. I have worked for clients who have a separate quality assurance department they report to and the QAs refuse to test on a developer machine as the policies do not allow them to do so, even though personally they agree with the benefits of cutting down the feedback loop.
Another client I was talking to remarked that QAs in their organization were actually driven by wanting to log a huge number of defects in their defect tracking system and not by actually wanting to deliver a quality product. This was to an extent that their yearly appraisals were affected party by what was logged in the defect tracking system as their managers will only look at those reports.
By having a QA as an integral part of the development team and adopting practices like Dev Box testing , the team goes through a mindset shift after which everyone is focussed on one goal, which is to deliver business value by building a quality product.
Ahem!! It is usually a BA and a QA who test the story on a dev machine not just a QA!!
ReplyDeleteInfact I've observed something very interesting on the project I am currently working on:
1) Story kick off: A process where the BA explains what the story is about to the developer pair who will be building it, QA likely to test it and the UX/UI people involved in the design/html - This ensures the devs, QAs and design people are all on the same page
2) Dev box/desk check/story walk through: Process as you described, but it again involves the BA and QA with UX/UI people testing the story and the edge cases
3) Testing: The devs when they pick up the story apart from writing unit tests also write high level acceptance (automation) tests. Once the story is dev done and desk checked a QA will pair with a Dev and finish writing all the required acceptance tests (automation) along with testing the story manually. This process ensures that a team is involved in making sure the story is "Done" and not individuals like a dev or a QA. What this also ensures is we are building a robust product with compelte set of tests and not just simly calling dev done or qa manually testing as "Done"
And ofcourse with our product owner right here, we get the stories tested every week and there is never a customer testing backlog!