Best Practice in any project using any tool is involving the QA Team, the project community at the beginning of the project planning stage. I've blogged about this previously but now I'd like to share how the QA Team can help and what they would be doing.
During project planning the QA Mgr and/or Lead should be involved so that during planning a comprehensive understanding of what is involved in the overall project can be obtained. The QA representative can help in planning from knowledge of previous projects for instance test timelines, test needs, resource needs, and has the opportunity to share ideas of how QA can assist other teams.
During preliminary project planning the QA Mgr/Lead can then start planning out the QA Team so that they have the right people sourced and available to start as soon as deemed required. This eliminates running around trying to hire QA resources a week prior to testing, which normally tends to be a disaster.
Now you have a QA team with a manager or lead, what do we do, get involved with requirements. I attended a web cast recently called Elicit Effective Requirements While Building Trust. It seems a lot of people are talking about "Requirements" these days the same points keep being repeated, see the list below:
Requirements development to include:
· plan to involve the stakeholders
· creation of a product vision
· establish a common glossary
· use multiple elicitation methods
· involve the entire project community
· use multiple model techniques both text and diagrams
· identify scope early - drive modelling from scope
· verify as you iterate
· prioritize continually
The next step is to involve the entire project community including stakeholders (the business) to create a vision, document the scope then analyze and verify requirements at the same time identifying priorities and risk. A great way to do this is by conducting workshops where requirement development is conducted in an organized, well planned atmosphere. I'll share tips I got from the web cast for a successful workshop. From experience this does work great in fact during a consultant gig I did where planning was started without the stakeholder’s I suggested to the project manager we do some workshops with the stakeholders. We basically followed this same pattern and what came out of it was the needs of the stakeholders had not been fully understood and what has being planned in development was about 70% incorrect. The workshops with the stakeholder early in the project saved the day in that situation.
· Use a planning team.
· Mind you’re "P’s": purpose, participants, principles, products, place, process.
· Uncover hidden agendas.
· Expose decisions.
· Establish and use ground rules.
· Make decision-making transparent.
· Openly acknowledge conflict.
· Build in serious play and prototypes.
· Enrich the work with multi-models and wall work.
· Conduct a sponsor show-and-tell.
· Facilitate a workshop retrospective.
· Share outcomes with the entire community.
· Use feedback to improve the process.
How does VSTS help in all this?
You can use templates that come with VSTS or upload your own for gathering and documenting high level requirements. With the ability to share using VSTS Team Explorer or the website Project Portal or for those that don’t have VSTS use Team Plain free (with a TFS license). I’ll blog about Team Plain another day but it gives your project community full edit/update access to work items with out having to have VSTS installed. During the workshop you can use the VSTS templates, Vision, the Persona, Requirements List, Issues, Project Checklist, work items Scenario and Quality of Service Requirements to translate the work into documents. Use work item Task to document additional work even assign it, work item Risk to identify areas that have been identified as a risk to the project. All this is stored in TFS and accessible to the project community. An easy format in workshops to get the documents written and updated is to assign them to specific people then have others proof read and a signoff process. Keep in mind one persons interpretation may not be another’s so it has to be a team effort. During the workshop there maybe times when you have to agree to disagree this is a good time to use the Triage List to track these instances and go back to them later with additional input from the community for clarification.
Once all requirements have been reviewed, analyzed and fully documented present them to the project sponsor’s, the entire community, get feedback, make revisions and finally get signoff.
The last step before the individual teams break out to start the next cycles have another workshop meeting where you plan out Builds, what will be in each build, estimate timelines, identify testing needs for each build, arrange tester/developer unit test design, regression testing of the builds, what happens if a build does not pass validation, logging of bugs found in builds, development load testing any work effort that can be identified and planned involving builds. Attendee’s at this workshop should include a Release Manager, Development, QA and Project Management builds affect all these areas’s and therefore needs to be a collaborative effort. All the build information should be documented, published and stored in VSTS TFS.
To conclude planning, requirement development workshops and build planning workshops help all teams in the project community to enable better team planning creates a well informed project community, the left hand knows what the right hand is doing, and it’s a gigantic step towards a successful project. VSTS aids the project community in organizing the documentation that comes from planning and workshops and allows easy communication to everyone. The requirements become work items that will be tracked as the project progresses, tasks identifies other work to be done, risk identifies stuff to watch and may even require further analysis, this all is the initial setup of your VSTS project.
As for the QA Team they now have a good understanding of what will need tested and can plan out their testing, make sure they have the right resources, they can work with development in creating better more comprehensive unit tests, plan for early load testing with unit tests, start getting tests cases/scenario’s written for the planned builds, they can determine what they will need to test thereby eliminating test duplication within the project community. Bring it on we’re ready!
Barry Gervin an ObjectSharp partner commented once; If QA is responsible for the quality of the product how come they aren’t involved from the start of the project. How come they aren’t involved in the unit testing, build verification, requirement verification? It is a good question and one that all Software Projects should be asking themselves.
If you have any questions contact me though comments. If you have just comments please they are welcome.
Quote of the day: We don't accomplish anything in this world alone ... and whatever happens is the result of the whole tapestry of one's life and all the weavings of individual threads from one to another that creates something.
Have a good day … Testa