One can standardize processes but not the context. So, there are good practices that add value in testing context, but there are no generic best practices which are situation and context independent.
We must accept the fact that any best practice in one context does not show the same results in another context. Hence we shall not follow blindly any of the so claimed best practice from some other context and apply it in our in-progress software testing as-is. In brief, what works in one context may not work as-is in another context. So we need to refine the practice specific to the context and strategize our software testing to address that context.
In order to make any software test practice effective, in software testing assignment in hand, we need to
- Understand the context
- Create System Context Diagram
- Select Initial Set of Best Test Practices of other Context and Refine to Suite our Context
We shall brief on each of these steps.
Understand the Context
Understanding the context involves understanding circumstances and conditions under which software testing occurs. Intuitive tester uses creativity and innovation to perform organized exploration of possibilities in a given context so as to understand circumstances and conditions under which testing shall take place. This exploration of possibilities consists of two steps:
1. Create mental picture
2. Imagining and creatively experiencing on events, statements, ideas, and so on that form setting for software testing in order to understand the circumstances fully.
If we perform this activity as an exercise of group creativity with the help of Brainstorming or Group Thinking, we certainly come out with extraordinary results. We learn and experience that when group thinking is at its peak, we start feeling that ideas start coming from air!
At the end of this step, we develop an understanding of circumstances and conditions under which events, statements, ideas, standards etc that would be providing information and insights on how well internal structure and external behavior are aligned to requirements & user expectations.
Create System Context Diagram
System Context diagrams represent the internal and external environment in which a software system exists. They serve as a useful tool to help the project stakeholders to communicate about what lies inside and outside the system boundary by defining system; sub-systems; environment; boundaries between the system, sub-systems, and its environment and their interactions with the system. It provides high level view without going into details. The best system context diagrams are used to display how a system interoperates at a very high level, or how systems operate and interact logically. The system context diagram is a necessary tool in developing a baseline interaction between systems and actors; actors and a system or systems and systems.
The context diagram depicts the project scope at a high level of abstraction but reveals nothing about the system functionality, architecture, or look-and-feel. Nor does it explicitly identify the features or functionality that is in or out of scope. The functional behavior of the system is merely implied by the labeled flows that connect the system to the external entities. Corresponding data inputs and outputs imply the types of operations the system will perform, but these aren’t shown explicitly in the context diagram.
System Context Diagrams can be created in different ways. We can use System Context Diagram based notations. Alternatively, we can us Architecture Interconnect Diagram, Business Model Canvas, Enterprise Data Model, IDEF0 Top Level Context Diagram, Problem Diagrams (Problem Frames), Use Case Diagrams, or User Stories.
Most of these diagrams work well as long as a limited number of interconnects will be shown. Where twenty or more interconnects must be displayed, the diagrams become quite complex and can be difficult to read.
For details on these diagrams, please refer: http://en.wikipedia.org/wiki/System_context_diagram
Select Initial Set of Best Test Practices of other Context and Refine to Suite our Context
Testing is iterative. It starts with high level initial understanding of the system and selects initial set of test best practices of other Context and refine to fit into context of testing under consideration. As our understanding continues to improve as we proceed to next phases of software testing life cycle because of test basis from different phases of development starts coming to us along with improved understanding of project-process-client-user-product-technology, our test practices shall undergo changes to suite to changing context. We shall continuously ask questions like what practice to continue; what to discontinue; what practice to add; and what practice to refine.
Thus, we shall always look out for good practices throughout because testing requires to align to dynamic circumstances and conditions.
I look forward for your views. Please send to firstname.lastname@example.org.
Also visit www.khannur.com and www.isqtinternational.com