I attended weekend testing America’s session number 18 on Saturday. It was my first WTA session and I must say it was a good learning experience. There was an interesting exercise given by James Bach. The exercise was about Test Charters.
As part of the exercise, we had to critique existing test charters and improve them. I went through the definition of test charter given in the exercise to understand more about test charters. I tried to critique and improve the example charters, based on the definition given in the exercise. I was not satisfied with the outcome and wanted someone to critique my (improved /modified) charters.
My (improved :-)/modified) test charter was discussed during the briefing session and Michael Larsen , Wade, Shrinik and Lalit gave interesting feedback on my charter. During that briefing session, I realised that I can draw analogy of writing test charters to writing user ...
User story is one of the primary development artifact for the XP project teams. A user story contains just enough information so that development team can reasonably give estimate about completing, tester can discuss how it will validated and customer can see its value.
One of the common question that we hear most of the time is, how user stories are different from use cases. User stories are much simpler than use cases. User stories are very easy to create, discuss and develop. They also do not contain any technical details.
Typically good user stories are defined in the following format
As a I would like to do so that
While discussing User Stories, you should make sure that they are not very big. A big user story leaves the chances of ambiguity and absence of clarity in the mind of development team. Ideally, you should be able to break ...
Dr Kaner talks about the requirement analysis of the Test documentation. According to Dr Kaner IEEE 829 is an paradigmatic example of standard that supports heavy weight software development process. You don't have to generate all the documents listed in 829 to be IEEE 829 compliant. Time spent in filling boiler plate information could be spent in documenting testing strategies and other useful information. The biggest problem with modern heavyweight projects is that they have a lot of inertia and resist the necessary change.
Requirements Analysis for Test Documentation (Part 2) - Cem Kaner
In this part Dr Kaner explains that using 'Prescriptive Standards' and templates will yield inappropriate products. Questioning should be used to gather documentation requirements. There are different types of stakeholders and each one is dealt differently. Dr Kaner answers some of the questions about Test Document Requirements. Needs of the organisation are more important than the ...
Dr. Kaner in this wonderful lecture explains the concept of specification based software testing. He explains what is specification based software testing. Importance of the specifications in the places where it is served as a contractual agreement is also discussed in this lecture. It also explains why specification might not be relevant if it served as vision document to guide the development initially and now it is not up to date. He also explains concept related to Active Reading can be applied to Specification documents.
Specification Based Software Testing - Part 2
In the second part of tutorial on specification based software testing, Dr. Kaner explains why questioning is very important in analyzing specification document. He explains different types of questions like hypothetical, behavioural, factual, historical, open/closed, context dependent and context free questions. He also gives many context free questions which can be used in any testing projects.
Specification Based ...
It is a well established fact that early involvement of testers during the software development life cycle brings immense value to the project. Participation of the testers during the requirement phase helps in identifying and correcting defects in the requirements.
As a tester if you are involved in the requirement phase you need to know , what attributes you should be looking for in the requirements? How can you ensure quality of the requirements? Following checklist gives you information about the attributes which should be tested for every requirement. These are just a subset of attributes that as a tester you will be interested in.
Complete Every requirement should be complete and give complete information on what is expected. For example, provide a shopping cart to the website is not a complete requirement. Complete requirement could be stated as "Provide shopping cart to the registered user who can pay using credit ...