- This topic has 11 replies, 10 voices, and was last updated 8 years, 9 months ago by
.
-
Posts
-
Does anyone on here write and present their test plan documentation in a format other than the “formal” document version (doc or pdf)? For example, using ppt, or mindmaps, or perhaps using docs but keeping them extremely light rather than be a slave to the IEEE format?
I’d be interested in your thoughts and experiences on this subject..I’m in a bit of a bind personally due to the expectation that I follow the usual formal process even though I know I could present this better and without the (seemingly) endless rounds of reviews etc.
Nope!
It might be a luxury, you can’t afford, but our team doesn’t use formal documentation on testing at all.
My reasons:
* Why put it down formally if they’re going to change along the way?
* No one is reading them
* They cost a lot of time, to write
* They’re boring to write
* You don’t trust us that we’re good at what we do? 🙄Especially because our systems change (a lot!), our focus is being transparent, at all times.
What do we do:
* internally use mind maps when we are testing manually
* use tools like cucumber, so anyone can read, understand and see the status of our tests. at all times
* we talk with our developers and stakeholders, e.g. to define priorities, integration areas to focus on, etc.
* do anything to get more involved with developers and make them aware of quality and hand them better tools to measure quality.Disclaimer, this works for me and what I work on, I realize this wont work for everyone/every application… but if you can… drop formal documents!
Hi Paul!
I am lucky to work in a startup company, we are our own client. Our test strategy is heavily based on the exploratory testing method thus
any documentation is very limited. If I test a complex and detailed feature/functionality I create a spreadsheet. However, I very often use a diagram that illustrate a task flow /user journey. It’s an artifact that neither needs a long creation time or a maintenance.. It’s a picture of a general functionality. Details are in your head.I hope it helps,
Ursula
Hello Paul,
I think one important thing is to document your strategy and your testing goals. That will indicate the resource (people need) and resource (equipment need) to accomplish the goals with the chosen strategy. This could be documented in a simpler way than a full blown test plan in most cases
Often enough, a test plan IEEE style runs the risk of not being a living document and forgotten about later in the project.
At my current project we have rigorous test plans that no one reads anymore. We plan each sprint in Testlink, stating what test cases to run and by whom.
Strategies also evolve without going back to original plan.We use wikipages. Less formal than docs and pdfs and more of a living document that gets updated as the plan changes. The wiki have the option of exporting the plan to pdf for those that *need* that format (mostly contractual obligations). Preferred method of distributing the plan is to copy-paste the summary into an e-mail together with a link to the plan.<span style=”font-size: small;”> Side-note: Project managers will often only read the summary in the e-mail as it answers the two questions they’re interested in: Is testing on track and is there any obstacles that need their attention?</span>
We also try to move all information that doesn’t change from one test plan to the next into another page for reference and add a link in the introduction. This makes it easier for all to focus on what’s important for this round of testing while maintaining the formal requirements.
No we stopped using formal Test Plans also the overhead when using Agile or Continuous Delivery is not worth it, the item is done before the document is signed-off.
– It is usually out of date by the time it is signed-off
– No one wants to review (and I found most of the review comments related to sentence structure not content)
– Most times what ever it contained is/was ignored.IEEE Auditors, just want to see that you have considered what is in the guidelines. If you have a Test Plan Process that outlines most of these items, Then you should be able to get down to a light weight document. Think about what items can be documented in a Tracking system, like Risks, Environmental Needs can be included in the Technical Design Document. Stop/Go criteria can be in the Project Plan which is usually the document reviewed by all Stakeholders.
Just as an interim thanks to you all – these replies are superb and mirror exactly my thoughts on a lot of things. Going to have a proper read later on – I think I’m going to have fun with this 😉
Another tip came in on Twitter @paul-french 🙂
Make sure to include environment equipment & who has what type of access needs to complete #testing #testplans https://t.co/dnDDQsODLk
— Jean Ann Harrison (@JA_Harrison) February 4, 2016
We use very high level plans. So instead of writing ‘Enter your username and password and then click Login button’, we would just write ‘Login’. This allows us to remember all the small scenarios that could be forgotten with regression testing, but doesn’t go in too much detail in case there are some changes on the page. I would go through sprint tickets and quickly update test script every sprint with bugs found so that we can catch them if they appear again.
Saying that, some clients still prefer official documents, so you would write that to them at the project end.
We use formal documentation in key areas. Our legacy desktop system requires manual regression (only carried out in the last two weeks before a release). I’ve created a suite of test cases plus a test plan outlining risks etc which are copied and adjusted as appropriate for each release – these require the tester to have knowledge of the system so say “Enter an invoice” rather than “Type x in field y”. Some of our testing uses third party test cases (e.g. our Payroll suite’s final test run every year is done using a standard set of government provided data) so we hold the documentation for that. Our new products are web-based and the policy is to automate as far as possible and documentation is in the form of the acceptance criteria held against user stories (we use VSO) and in the comments included in the automated scripts (selenium with c#).
For bespoke work on the legacy system I’d still prefer to see some formal test documentation although not all of our teams agree (although when the helpline come back with questions six month on they sometimes regret keeping the user stories and test documentation to a minimum).
Having read through these now just wanted to say thanks again for the replies so far and great to see others feeling the same way. I’d also like to clarify that I am attacking this from the perspective of a Test Manager (my role).
Main issue I face is working with people who perhaps come from the “corporate” world and therefore think that formal TP document is the only way (because this is all they know) when there are other options. Examples being recently where I looks at a 40pg test plan, and probably only highlighted a handful of pages worth of useful material.
So, my argument is rooted in the idea that whilst testing planning is obviously a VERY important part of testing activity, writing a IEEE compliant test plan maybe isn’t. Though this does depend on the organisation you’re working for (especially if testing as part of contractors, or out-sourced org where maybe there is an SLA in place as part of the engagement). We need to think about the reasons for WHY you feel it’s required for a test plan to be documented and signed off (e.g. is this something to refer back to later on if things go a bit breasts up), and WHAT the key pieces of info actually are? There’s been lots of times (rightly or wrongly) where testing has started without test plan document formally accepted but where everyone knows whats going on. Why? Because we’ve discussed in the team and with the developers/PMs prior to the start.
I really like the Wiki idea for the TP and might explore that (we use SharePoint and something similar should be possible in there). The main reason being you don’t have to trawl through loads of documents, but also providing links to standard, repeated sections (e.g. current defect process, team structure etc) is easier.
This leads into my next question also
A pet hate of mine is people filling TP documents with material which is present in other documents instead of just linking and referencing that document. For example, putting business process flows, or even pages of project background (everyone reading the bloody thing KNOWS what the project is) etc.
- You must be logged in to reply to this topic.