Test strategy

ISTQB Glossary  definition 

"A high-level document defining the test levels to be performed and the testing within those levels for a programme (one or more projects)."

In Simple English,

It is a published agreement to keep all parties involved informed about the strategy defined to test a project. This involves documenting the level of testing targeted, the kinds of testing agreed on as needed and the approach agreed upon.

Field Notes 

1. This document is often confused with test plan document.

2. Depending on the way on organization defines it, test strategy sometimes will involve several items that are generally considered as part of a formal test plan.

3. Some companies altogether combine both the test strategy and test plan documents and have a single artifact. They call it Master test document or test strategy or test plan.
remember, as rose by any other name is still a rose.

4.This however is different from test policy. While Test Policy is defined and maintained at the organization level, test strategy is at a project or program level. (Program here does not mean a piece of code. It means a very big Project which in turn has several projects under it)

Test suite

ISTQB Glossary definition In Simple English, flield notes for "Test suite"

ISTQB Glossary definition

A set of several test cases for a component or system under test, where the post condition of one test is often used as the precondition for the next one.

In Simple English,

it's a group of related test cases that makes sense to be tested together to achive a test objective at hand.

QA Practitioner’s notes for ream work experience in this field

• Test suites are often dynamically created to match the the task at hand.
• Most times test suites are used as work allocation mechanism within a huge team. 
• Though it's easy to use it to manage work allocation its not the best way to achive test objectives. 
• Though by definition each steps' result should feed to the next step as input it is not a hard requirement. 
• Most often test suites are created based on the release being tested.   

Now, Let’s see one or more example cases to understand this even better:

Say you are asked to test an web application like gmail. One way to form the test suites would be to have one per function like, send mail, receive mail and manage drafts.

Feedback
So, what do you think?
Was the explanation clear enough?
Did you understand?
Did you get what you were searching for?

If you have any more questions, comments or compliments please let me know as your comments below.

Wide Band Delphi

ISTQB Glossary definition explained in simple english with examples based on real experience for the testing term “ Wide Band Delphi"

ISTQB Glossary definition

An expert based test estimation technique that aims at making an accurate estimation using the collective wisdom of the team members.

In Simple English, this means 

just ask the team how much time testing will take and use it.

QA Practitioner’s notes for real work experience in this field

• So who is this ‘Expert’?
  • ‘Expert’ here means someone who has prior experience with the testing that is being estimated.
  • An  interesting question such a definition brings is: what is no one has never tested the test being estimated?
  • In such case, the team with prior similar experience is a better ‘Expert’.
  • Even better is to ask the actual team that will eventually test the application to be used as the ‘Expert'
• ‘Collective Wisdom’ is the emphasis here. 
  • This means that the first step is to ask each member of the test team separately  for their estimate. 
  • Most important distinction here is to ask without suggesting a baseline.
  • So, the question should not be “Can this be tested in a week?” Or “How much time should we take to test this?"
  • The question should be open ended and directed to just the person being asked. Something like “How much time do YOU think testing this release/version will take?"
  • Another distinction here is not to ask, how much time will you need to test this? This becomes a incorrect question as it forces the person to answer for only what they assume as the part they will be testing.
  • The objective is to not that. it is ask each team member how much time they think will be needed to test the release/version. 
• It is what the team thinks it will take to get the job done.
• Please Remember.  This is still an estimation. Just because it comes from the team it does not some how qualify to become a better estimate in anyway. 
• Most times, the test engineers do not include time for test lead / test manager level tasks like triage, reporting and meetings.

• The unit varies.  
  • This is becase every person may express it in a different way.
  • Some. might say, may a week. Some may say, 5 days. some may say it as we can run 14 test cases.
• Prepare to be surprised, there may be a wide band of estimates. 
  • Some may say "hmm., just 4 days. we can get this done?"
  • Someone in the same team for the same release may at the same time say “this will definetly take 4 weeks at the minimum"
  • Hence the “Wide” i guess.

Now, Let’s see one or more example cases to understand this even better:

Most often, i have seen this method used even without the awareness that the team is using this method.

Case 1:
An emergency release is being planned to address some priority issues. Most cases have much tighter deadlines. The test team gets asked this question “So, how much time do you need to get this tested?"

Feedback
So, what do you think?
Was the explanation clear enough?
Did you understand?
Did you get what you were searching for?

If you have any more questions, comments or compliments please let me know as your comments below.