Testers Are The Most Important Role!

I have always said the #1 most important role, in systems and software delivery, is the Code Slinger (Developer), where #2 is the Project Manager. However, in the beginning of any project or delivery exercise, we are trying to develop and validate the "Requirements" for the effort. In other words, understand the problem(s) to solve.

I find that in almost every project, when I arrive to assist in better delivery results, the team is missing important roles at the start of the effort. One of those roles is a "Tester" or "Quality Assurance" role. This is usually the person or role that knows how the business or shop does things, like methods, procedures, rules, and processes. The Testing role probably should have been the first "role" that the Project Manager asked for, even before me (the Solution/Enterprise Architect 😎).

The "Testing" role is usually a stakeholder responsible for "Quality" in the Company, Organization, or Development Shop. In my shops, when  hiring Developers, I prefer that everyone start out as a "Tester". These resources are very good at asking questions, challenging outcomes, and have problem solving skills. These are also traits that good Developers should have.

When modeling, solutioning, or designing a system or software, one of our major objectives is to determine "what" we are doing or what is to be done. The "what" is "requirements" and these can be existing or future modes of operations whether technical or non-technical. All must be "TESTED".

Why Modeling?

Modeling, whether using the Unified Modeling Language (UML) or other modeling techniques is an important aspect of understanding what is to be done.

In software design and engineering, modeling refers to the process of creating abstract representations of software systems, components, behaviors, and interactions using various modeling techniques and tools. These models help software engineers and stakeholders understand, visualize, analyze, and communicate different aspects of the software system throughout its lifecycle, from initial conception to maintenance and evolution.

Modeling in software design serves several purposes:

Understanding Requirements - Models help stakeholders clarify and capture requirements by providing visual representations of system functionalities, user interactions, and data flows. They enable stakeholders to explore and validate requirements before implementation begins.

Designing Architecture - Models facilitate the design of software architecture by capturing the structure of the system, including components, modules, layers, and their relationships. Architects use architectural diagrams to define system boundaries, interfaces, and dependencies.

Detailing Behavior - Models describe the behavior of the software system through use case diagrams, sequence diagrams, state diagrams, and activity diagrams. These behavioral models illustrate how users interact with the system and how the system responds to different inputs and events.

Communicating Design Decisions - Models serve as a communication medium between different stakeholders, including developers, designers, testers, and clients. They provide a common visual language to discuss and convey design decisions, trade-offs, and constraints.

Analyzing and Verifying Design - Models can be analyzed and validated using formal methods, simulations, or automated tools to detect design flaws, inconsistencies, or performance bottlenecks early in the development process. This helps improve the quality and reliability of the software system.

Supporting Documentation - Models serve as documentation artifacts that capture the design rationale, decisions, and constraints of the software system. They provide a reference for developers during implementation and for maintainers during system evolution.

Various modeling languages and notations are used in software design, including Unified Modeling Language (UML), Entity-Relationship Diagrams (ERDs), Data Flow Diagrams (DFDs), and Domain-Specific Languages (DSLs). Each modeling language has its strengths and is suitable for different aspects of software design, ranging from high-level architecture to detailed behavior specification.

A Testing-First Mentality

In tools like Sparx Enterprise Architect (EA), we can model our requirements, build Scenario Structures, and auto-generate various Model Types (e.g., Activity Diagrams, Sequence Diagrams, State Diagrams, and more). We can also auto-generate Test Cases.

In our UML Operator Channel, we published Building Test Cases from Scenarios. Be sure to always bring Testers, at some level, to the start of every project and start building your Test Plans and Cases as soon as possible.

Comments

Popular posts from this blog

Sparx EA and Open Collaboration

BPMN Diagram versus Sequence Diagram

MDA vs MDD