Testing Quote of the Week 3

“If you do not care about quality, you can meet any other requirement.” ~ Gerald M. Weinberg

Skills of Attending Presentations

Several people do write about Presentation Skills since it is very important to deliver a good presentation starting from the topic through the way it is being delivered. However, how about the attendees?! I am sure they need skills too. Those skills the attendees need are related to their attitude and how to attend the presentation. This post will give a glance on attendees skills required. It is based on an experience with a presentation I had recently at work keeping in mind that the topic was important and my presentation skills are fairly good. In addition, involved people are related to the topic being discussed. (more…)

Quality Police Policy

One of the biggest mistakes in software development projects is to adopt Quality Police Policy for testing activities. In this post, I will explain what Quality Police Policy is and how it affects software testing and software quality.

A simple explanation of Quality Police Policy is to keep testers away and not involving them till late stages of software development. In other words, testers are ignored and their role is limited. The only thing testers might have is the initial customer requirements which most probably are subject to modifications. The testers then wait for next software release. They are not involved during requirements clarification meetings, design meetings or other project-related meetings. Whether this is done intentionally or unintentionally, there are always high expectations by management that the testers will (and must) find all the issues in the software. (more…)

Testing Quote of the Week 2

“There is nothing to stop us from testing for the rest of our life.”  ~ Portal 2

Exploratory Testing

Exploratory testing is an experience-based test design technique. The tester uses his/her skills and experience to test the software. It is an approach formalized by James Bach.  Exploratory testing can find issues with the software that are not caught in white box and black box test design techniques. It includes designing the tests at run time.

As mentioned previously, exploratory testing needs skills and experience. This includes knowledge about the system under test (SUT). Exploratory testing is best used when there is little or no documentation about the software. In addition, when testing time is limited. However, it might not be efficient if not done in the right way.

Tester needs to take notes about the decisions. These notes can be used by others and include any relevant details. This includes functions explored and test cases attempted in addition to any other observations that might be useful.

* Reference: Just-In-Time Testing by Robert Sabourin