Executable Specifications Over Static Documents
Best Practices for Agile/Lean Documentation
Test strategies and plans – I have done many, obviously. The most unread documentation you could ever find on a project. Sure, you can promote and sell what you are writing, and gain support from people who are never going to disagree with anything with “quality” tag. My focus is whether client is happy with progress or not – what better indication on how a project is going, than when you customer is happy. The woefully under-estimated definition of done has more importance that a test plan. Test strategies serve best at higher level, describing not hard and fast rules, but an approach to QA generally. If you are going full BDD, then a test strategy become a little pointless. You are re-working a strategy that does not need that document, with BDD, testing is part of the pipeline from story to sign-off.
While testing strategy is important, it has little bearing on actual work and the place of testing in team dynamics. Documentation is largely a self-promotion exercise or time-killer, let’s be honest. How to slot testing into existing way of working, recommending change, as well as throwing measured hissy-fits at bad attitude/process. In my earlier days, the documentation was key to making first good impression. As I care less and less about opinions about me, and never suffer fools gladly, I find the best way I can contribute is to start working – seriously, start working, don’t waste time beyond a week with your waffle about processes, tools and documentation. Just do it how you feel is best. As contractor, you are being paid not only for skills they see on cv, but your independent mind. Don’t have one? Then why are you a contractor when you need validation from a crowd?
In the workplace, a sheep mentality is common – waves of people switching allegiance on sometimes daily basis. It’s an easy crowd to play with, if you have a mind to. But I am not in a contract to accommodate pack-like behaviour patterns. I don’t judge anyone by documenting or presenting skills – I judge by an old-fashioned benchmark – results, and that is broad area. You want me to dazzle you with terminology and jazzy documentation, about a newer-faster-smarter approach, so you can be impressed, I can do that. To give you the impression following a certain approach, will make your project run better, I can do that too. But I would be doing you no favours.
By separating out testing into it’s own entity, is missing keys parts of Agile/Lean development. Your scope is defined by the schedule, which you, in a QA capacity, had input into already (right?). Outlining risks, introducing new testing tasks such as exploratory, accessibility or cross-browser/device testing. It’s part of the project. A test report at the end of automation or manual testing, indicates the test coverage. Attaching labels and process is separate test documentation, will end up covered in digital dust. To be truly useful, the documentation needs to grow with the projects. I say projects, plural, as strategy documents should take a high level view. Reuse is not only a principle for coding, it’s relevant to test documentation also.
Documentation is part of the reason QA got such a bad name – over-documenting, the prime directive of the paranoid employee. The second directive is product-plugging, solutionizing by recommending open source products, as if they are your own. That somehow you have risen above the chaos, executed a half-decent search on github, and found something no-one else could of (really?). Get back to your 1990’s cave, because unless your documentation is helpful, and your product-plugging amounts to something real, then that is where you belong.