SlideShare a Scribd company logo
1 of 32
Download to read offline
© NISHI, Yasuharu
Viewpoint-based
Test Requirement Analysis Modeling
and Test Architectural Design
6th
World Congress for Software Quality
London, UK
2014/7/3(Thu)
Nishi, Yasuharu
The University of Electro-Communications, Japan
© NISHI, Yasuharu2
Profile – Dr. NISHI, Yasuharu
Assistant professor:
the University of Electro-Communications, Japan
(also providing consultancy service to industry on testing and TQM)
President:
Association of Software Test Engineering, Japan (ASTER)
President:
Japan Software Testing Qualifications Board (JSTQB)
National delegate:
ISO/IEC JTC1/SC7/WG26 Software testing
Founder:
Japan Symposium on Software Testing (JaSST)
Founder:
Testing Engineers’ Forum (Japanese community on software testing)
Vice chair:
SQiP/Software Quality Committee of JUSE (promoting organization of TQM)
(SQiP has published the book of “SQuBOK: Software Quality Body of
Knowledge”
and is operating engineer certification on software quality)
Research interest:
Software testing, software quality/TQM , embedded software engineering,
software process improvement, software project management, system safety
© NISHI, Yasuharu3
Software Test Engineering Process
• As software has got huge and complicated,
test cases (= test suite) also get huge and complicated
– such as
» a test project with over 100,000 test cases
» over 10 test levels
» various test types such as load, configuration and security
– You have to develop huge and complicated test suite systematically
• But technologies on test planning or test strategy
are just immature
– Engineering work and management work for test development are confused
• It is necessary to define software test engineering process
to develop huge and complicated test suite systematically
© NISHI, Yasuharu4
Independent RA is necessary for testing
• Independent requirement analysis for testing is necessary
– Requirement analysis for software isn’t usually exact or detail enough
– Of course test requirement analysis depends on SUT and its dev. Process
• Requirement analysis for testing should be more important
– Test “planning” is just management word and NOT engineering word
Test
Architecture
Design
Test
Requirement
Analysis
Test
Detail
Design
Test
Implementation
VSTeP: Viewpoint-based Test Process
Test
Planning
Test
Design
Test
Implementation
(Scripting)
Part of typical test process
Test Management (including planning for management)
© NISHI, Yasuharu5
VSTeP
• VSTeP(Viewpoint-based Software Test Engineering Process)
is a generic test engineering process model
focusing on test viewpoint
– You can stress upper phase of test engineering process such as
test requirement analysis and test architecture design
which tend to be negligent
– VSTeP drives you to good test suite, good review for test design,
accumulation of knowledge and experience on testing
– Reuse and improvement will be easy because you can do
reverse-engineering of your past (unorganized) test suite
– NGT (Notation for Generic Testing) is a made-in-Japan notation
for Test Requirement Analysis and Test Architecture Design
» Modeling skill like object-oriented design is essentially necessary
Test
Architecture
Design
Test
Requirement
Analysis
Test
Detail
Design
Test
Implementation
VSTeP: Viewpoint-based Test Process
Test Management (including planning for management)
© NISHI, Yasuharu6
Detail phase of VSTeP
• TRA: Test Requirement Analysis
– To make a test requirement model
» To extract, organize and understand test requirement
» To create a test requirement model which consists of test viewpoints,
i.e. to create a viewpoint diagram
• TAD: Test Architecture Design
– To make a test architecture model
» To re-organize test viewpoints into test containers
as test types, levels and cycles for making test smooth
» To assemble test viewpoints into test frames which is template for TDD
• TDD: Test Detail Design
– To make test cases
» To set values in detail into test frames or test viewpoints
• TI: Test Implementation
– To make test scripts
» To add detail information necessary to execution to test cases
» To combine simple test scripts into a compound test script
for making execution efficient
© NISHI, Yasuharu7
Example of part of viewpoint diagram drawn for TRA
E-mail client
GUI Functions Environment Data
Platform Network
OS Hardware
Kind of OS Version of OS Internet Explorer
Test Item / SUT
© NISHI, Yasuharu8
What is test viewpoint: abstract test case
• Test cases has test values
– ex) parameter: Kind of OS, values: Win7, WinXP, Win2000
– Test parameters are also called as test conditions
and test values are also called as test coverage items
– Test cases consists of test values
• Viewpoints are abstract test cases
– Bottom viewpoints means test parameters
– Viewpoints don’t express
any test values or test cases
– Viewpoints can have hierarchical structure
like classification trees or class diagrams
– Viewpoints can be extracted from
test conditions, test items and quality characteristics
such as load, configuration and performance
– Ideally viewpoints should indicate
an INTENTION of a test case
» Viewpoint diagram can be a repository of intentions of TCs
Kind of OS
OS
Platform
Environment
- Win7
- WinXP
- Win2000
Test
Cases
Bottom
viewpoint
Viewpoint
Viewpoint
© NISHI, Yasuharu9
Various test viewpoints
– What should be exhausted:
» Specs, functions, data etc.
» Test conditions
– Characteristics which should be
achieved
» Quality characteristics, non
functional requirements etc.
– Parts of test items
» Funcs, Subsystems, modules etc.
– Bugs
» Errors and failures, bug patterns,
weak points of test items etc.
– Customer usage
» Business, lifestyle etc.
– Other parts of systems than software
» Hardware units, hardware failures etc.
– Test types
» Load test, configuration test etc.
– Test levels
» Component test, system test etc.
– Lists and/or diagrams developed
until software testing
» Use cases, State transition diagrams etc.
• Test viewpoint is a point where test engineers focus
an attention for grasping a big picture of test design
– Test viewpoint is abstraction and source of test cases
• Types of test viewpoints depend on organizations
and/or test engineers
OS
© NISHI, Yasuharu10
• The word “viewpoint” is independent of roles
Why “viewpoint” ?
Test purpose
Requirement!
Test condition
Parameter
Test Environment
Analyst
Test Manager
CT Researcher
Test EngineerTest Operator
© NISHI, Yasuharu11
Types of Hierarchical relationship
• Test viewpoints have two fundamental relationships
– Hierarchy relationships and Interaction relationships
– Types of relationships can be expressed as “<<stereotype>>”
• Hierarchical relationships can bear several meanings
– is-a relationship: inheritance
– has-a relationship: possession
– There may be other hierarchical relationships
» object-attribute and cause-effect is example
OS
Windows Memory
Management
Subsystem
<<has-a>><<is-a>>
© NISHI, Yasuharu12
Interactive relationships of viewpoints
• Viewpoints can relate each other with interactive relationships
– Non-hierarchical relationships are necessary: Interactive relationships
– They can also bear several meanings: combination, sequential etc.
– Lines without arrowhead represent “combinatorial relationships”
– Arrows with an open head represent “sequential relationships”
– Relationships can represent their meanings with <<stereotype>>
– In this workshop interactive relationships without stereotypes represent
combinatorial relationship
Function Configuration
<<sequence>>
OS Web browser
<<combination>>
© NISHI, Yasuharu13
Relationships of viewpoints
• Test viewpoints have two fundamental relationships
– Hierarchy relationships
» Detail a viewpoint step by step to reach test coverage item with a straight line
» Have several types such as is-a, has-a, cause-effect, object-attribute
– Interaction relationships
» Connect test viewpoints to test combination of viewpoints with a curved line
» Have several types such as combination (needs combinatorial testing) etc.
• Types of relationships can be expressed as “<<stereotype>>”
OS
Version of OS
<<has-a>><<is-a>>
Interaction
Hierarchy
<<combination>>
Viewpoint
Filesystem
© NISHI, Yasuharu14
Notation of viewpoint diagram in NGT
Viewpoint Viewpoint
Hierarchical
Relationship
Combinatorial
Relationship
Sequential
Relationship
<<combination>>
<<stereotype>> Stereotype
<<sequence>>
...
...
...
...
...
... Interactive
Relationship
Drawing tools for
mindmaps
are useful
Test
Container
...
© NISHI, Yasuharu15
Viewpoint diagram is simple enough
• Viewpoint diagram is simple enough
to make a TRA/TAD model
– More simple than classification tree
OS Web browser
OS Web browser
7 Vista IE Chrom
e
Firefox
Classification Tree Viewpoint diagram
© NISHI, Yasuharu16
TRA: Test requirement analysis
• To extract, organize and understand test requirements
– Requirements from customers to achieve
» Functional requirement, non-functional requirement, business goals etc.
– Constraints to achieve requirement from customers
» Requirement of test project management such as efforts, costs etc.
» Test tools and/or methods directly requested by customer especially
– Information of current quality of the test item
» Ex) bugs which were detected in prior reviews
• To create a test requirement model on viewpoint diagram
– Extract test viewpoints from test requirements
– Detail test viewpoints and
connect parent viewpoint and child viewpoints
– Extract interaction relationships and
connect viewpoints
– Top-level viewpoints are most important
for grasping a big picture, called “View”
Views
© NISHI, Yasuharu17
Refinement of a test requirement model
• You can refine a test requirement model
to make it clear and easy to understand
– To detail viewpoints step by step to exhaust / list all test conditions
– To move, divide or rename viewpoints if necessary
– To check non MECE viewpoints in each layer
and re-organize them as MECE
» MECE: Mutually Exclusive and Collectively Exhaustive
– To check whether brotherhood viewpoints have
the same stereotypes of hierarchy connections
– To check whether interactions would be better to change viewpoints
© NISHI, Yasuharu18
VSTeP
• VSTeP(Viewpoint-based Software Test Engineering Process)
is a generic test engineering process model
focusing on test viewpoint
– You can stress upper phase of test engineering process such as
test requirement analysis and test architecture design
which tend to be negligent
– VSTeP drives you to good test suite, good review for test design,
accumulation of knowledge and experience on testing
– Reuse and improvement will be easy because you can do
reverse-engineering of your past (unorganized) test suite
– NGT (Notation for Generic Testing) is a made-in-Japan notation
for Test Requirement Analysis and Test Architecture Design
» Modeling skill like object-oriented design is essentially necessary
Test
Architecture
Design
Test
Requirement
Analysis
Test
Detail
Design
Test
Implementation
VSTeP: Viewpoint-based Test Process
Test Management (including planning for management)
© NISHI, Yasuharu19
TAD: Test Architectural Design
• Test architecture is a big picture of test suite
– It is easy to grasp a big picture in test container level
for large and complicated testing
– Several viewpoints can be packed into a “test container”
– Test containers can be test levels, test types and test cycles
Structure t.
Exception
handling
testing
Multi bytes
testing
Boundary
of arrays t.
Unit
testing
Module calling
t.
Interruption
handling
testing
Shared
memory t.
Device
management
t.
Security
testing
Environment
testing
System
testing
Failure
mgmt
testing
Load t.
Function t.
Cycle 1
Load t.
Function t.
Cycle 2
Integration
testing
© NISHI, Yasuharu20
Guides for good TAD
• Some characteristics, attributes and patterns for software
can be applied as guides for good TAD
– “Quality Characteristics” for software are already available
such as ISO/IEC 25000s
» Functional Suitability / Performance efficiency / Compatibility / Usability
/ Reliability / Security / Maintainability / Portability
– Other characteristics and design patterns for software design are also major
» Coupling / Cohesion / Encapsulation / Responsibility
» Design patterns such as MVC, singleton
• Characteristics for TAD is important for good TAD
– Cohesion and coupling
» A test container should be packed with
viewpoints with similar meanings
» Test containers should have
so few combinatorial relationships as possible
– Maintainability / Internationaliziblity / Portability
» Test containers which needs modifications should be
easily identified in maintenance, internationalization and porting
– Design patterns on viewpoint level could be another guide for TAD
© NISHI, Yasuharu21
Quality attributes of test suite
• Test architecture depends on
required quality attributes of test suite
– Test suite can have its own quality attribute
if test suite is artifact
– Ex) Maintainability of test suite
– It doesn’t mean testing of quality attribute
such as ISO/IEC 25000s/9126s
Maintainability
considered
Simply
divided
Test architecture
of small calculator
© NISHI, Yasuharu22
Example of design pattern for TRA/TAD
• Interaction Cluster Partitioning Pattern
– if you can specify the source of combinatorial bugs is
e-mail protocols and accept risks of bugs from other sources,
you can reduce combinatorial test cases with ICP design pattern
Client
OS
Client
E-Mail
Client
Web
Server
OS
E-mail
server
Anti-
spam
Client
OS
Client
E-Mail
Client
Web
Server
OS
E-mail
server
Anti-
spam
Client
E-Mail
E-mail
server
3 values 4 values 2 values 2 values 3 values 4 values
3 values 4 values 2 values 2 values 3 values 4 values
4 values 3 values
(3 x 4 x 2) x (2 x 3 x 4)
= 576 cases
(3 x 4 x 2) + (2 x 3 x 4)
+ (4 x 3)
= 64 cases
© NISHI, Yasuharu23
Research Question
• Can Test Viewpoint Diagram
reduce omission of test conditions?
– Can test requirement modeling activity based on test viewpoints
reduce omission of test conditions more than based on test conditions?
– Is independent requirement “modeling” for testing
is better than “deriving test conditions”?
» Does “Deriving test conditions” mean just reading test base and writing them?
• We conducted an experiment to compare
“deriving test conditions” and “modeling test viewpoints”
– Lecture from academia and experiment by industry
© NISHI, Yasuharu24
Experiment for reducing omissions of test conditions
• Overview of Experiment
– Experiment for reducing omissions of test conditions in test requirement
analysis phase by 2 teams using test conditions and test viewpoints
» Team C: Selected test conditions using test conditions
· Team C selected test cases by the same way as actual test design using spreadsheet
· To compare easily, we redrew Team C’s test cases into Test Viewpoint Diagram
» Team V: Selected test conditions using test viewpoint model
· We made lectures on NGT/VSTeP and
instructed them to model with Hierarchical relationships
· They drew Test Viewpoint Diagram using a mindmap tool (freemind)
– Both teams had 3-4 engineers and all engineers had 5-10 years experiences
in software testing company mainly for embedded software
• Test Base / SUT
– User manual of a highly functional rice cooker
– Manual mainly has 2 parts:
» Operational instructions / functional descriptions
» Recommendations of cooking rice, e.g. for Sushi
© NISHI, Yasuharu25
Condition-based test requirement model
1
-
No.
Kind of rice Note Amount of rice Note
Amount of water
for cooking
Note
Pre-soak
in water
Note
Amount of water
for post-cooing
Note
1 Polished rice 1 cup Same as gauge Not to be soaked 45ml
2 Pre-washed rice 2 cups More than gauge To be soaked Maximum
3 Stickyrice 3 cups Less than gauge
4 Raw rice 4 cups
5 Sprouted raw rice 5 cups
6 Partlymilled rice
Level of milling isn't
categolized
7 Sprouted rice
8 Cereals rice
Test
Values
Test
Conditons
Precondition
Policy for listing
Condition-Value
list No.
To derive necessary test conditions and values for the rice cooking functions referring to operational steps of rice cooking
- - - If post-cooking is started
1 2 3 4 5
To compare easily,
we redrew the list into
Test Viewpoint
Diagram
© NISHI, Yasuharu26
Viewpoint-based test requirement model
© NISHI, Yasuharu27
Comparison of Condition-based and Viewpoint-based model
Condition-based model
Viewpoint-based model
© NISHI, Yasuharu28
Result: no. of omissions of test conditions
• Condition-based model omitted 13 more test conditions
than Viewpoint-based model
– Team C selected test conditions only which are explicitly written and
easily identified as test conditions
» Model is constructed in spreadsheet style
– Team V modeled the SUT itself whether viewpoints are test conditions or not
» Model is constructed in NGT/mindmap style
Conditions
explicitly written
Omissions of
Conditions
Out-of-scope
Condition-based
Model
All +13 0
Viewpoint-based
Model
All +0 (baseline) 18
© NISHI, Yasuharu29
Detail of omitted test conditions out of Condition-based model
• Ambiguously written input parameter: 1 condition
– “Memory of a past cooking course”
• Ambiguously written usecase: 1 condition
– “Successive cooking”
• Attributes of physical object explicitly written
in Recommendation part of the manual: 6 conditions
– “Degree of rinsing”, “pH of Water”, “Hardness of water”,
“Temperature of water”, “Vinegar”, “Spices”
• Ambiguously written expected results (behavior): 4 conditions
– “Display before rice cooking”, “Display just when rice cooking starts”,
“Display on buttons”, “Sounds”
• expected result of physical object explicitly written
in Recommendation part of the manual: 1 condition
– “Badness of taste”
© NISHI, Yasuharu30
Consideration on threats to validity
• Lack of empirical study?
– Single experiment can be biased and consistently extract wrong information
– We gathered multiple engineers who have almost the same experience into each team
• Lack of assessing the validity of cost and time measures?
– Team V spend more time (but practically acceptable) on TRA than team C
– Cost and time for TRA and TAD is often made more ignorable than TDD, TI and Test Execution
• Lack of assessing the validity of domain skills of engineers?
– All the engineers have almost the same domain skills as rice is the most popular food in Japan
• Lack of evaluations for instances of growing size and scope?
– Omissions are mainly about domain objects, i.e. physical objects, and ambiguous specifications
– As size and scope of test grow, domain objects and ambiguous specifications will grow,
VP model will be more effective
• Lack of evaluations for integrity and testability of the test base
– Integrity and testability of the test base grow, description on domain object will get richer and
ambiguous specification will decrease
– Although C model can reduce omissions, integrity and testability of test basis is limited actually.
We can estimate VP model will be yet more effective
• Lack of evaluations for refinement of model
– We didn't measure or limit the number of refinement of model exactly
– VP model was more refined than the C model
– As good model written in good notation will be more refined, VP model can be estimated to be
more effective.
© NISHI, Yasuharu31
Conclusion
• Independent test requirement analysis(TRA) is necessary
• It is important to construct a test requirement model in TRA
• In our experiment, test viewpoint model can reduce
omission of test conditions more than test condition model
• Scientific measurement
of merit of “modeling”
is rather difficult or not?
– Empirical study is necessary
© NISHI, Yasuharu
Thank you for your kind attention
NISHI, Yasuharu
http://qualab.jp/
Yasuharu.Nishi@uec.ac.jp

More Related Content

What's hot

(애자일) 테스트 계획서 샘플
(애자일) 테스트 계획서 샘플(애자일) 테스트 계획서 샘플
(애자일) 테스트 계획서 샘플SangIn Choung
 
Chapter 4 - Test Design Techniques
Chapter 4 - Test Design TechniquesChapter 4 - Test Design Techniques
Chapter 4 - Test Design TechniquesNeeraj Kumar Singh
 
ISTQB Foundation - Chapter 3
ISTQB Foundation - Chapter 3ISTQB Foundation - Chapter 3
ISTQB Foundation - Chapter 3Chandukar
 
Test automation principles, terminologies and implementations
Test automation principles, terminologies and implementationsTest automation principles, terminologies and implementations
Test automation principles, terminologies and implementationsSteven Li
 
ISTQB Performance Tester Sample Questions
ISTQB Performance Tester Sample QuestionsISTQB Performance Tester Sample Questions
ISTQB Performance Tester Sample QuestionsNeeraj Kumar Singh
 
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFL
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFLINTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFL
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFLRahul R Pandya
 
테스트자동화와 TDD
테스트자동화와 TDD테스트자동화와 TDD
테스트자동화와 TDDSunghyouk Bae
 
Understanding Unit Testing
Understanding Unit TestingUnderstanding Unit Testing
Understanding Unit Testingikhwanhayat
 
Chapter 4 - Quality Characteristics for Technical Testing
Chapter 4 - Quality Characteristics for Technical TestingChapter 4 - Quality Characteristics for Technical Testing
Chapter 4 - Quality Characteristics for Technical TestingNeeraj Kumar Singh
 
software testing for beginners
software testing for beginnerssoftware testing for beginners
software testing for beginnersBharathi Ashok
 
ISTQB Foundation Level Mock Exam 1
ISTQB Foundation Level Mock Exam 1ISTQB Foundation Level Mock Exam 1
ISTQB Foundation Level Mock Exam 1Neeraj Kumar Singh
 
02 software test plan template
02 software test plan template02 software test plan template
02 software test plan templateAndrei Hortúa
 
ISTQB / ISEB Foundation Exam Practice -1
ISTQB / ISEB Foundation Exam Practice -1ISTQB / ISEB Foundation Exam Practice -1
ISTQB / ISEB Foundation Exam Practice -1Yogindernath Gupta
 

What's hot (20)

(애자일) 테스트 계획서 샘플
(애자일) 테스트 계획서 샘플(애자일) 테스트 계획서 샘플
(애자일) 테스트 계획서 샘플
 
Chapter 4 - Test Design Techniques
Chapter 4 - Test Design TechniquesChapter 4 - Test Design Techniques
Chapter 4 - Test Design Techniques
 
ISTQB Foundation - Chapter 3
ISTQB Foundation - Chapter 3ISTQB Foundation - Chapter 3
ISTQB Foundation - Chapter 3
 
Chapter 2 - Test Management
Chapter 2 - Test ManagementChapter 2 - Test Management
Chapter 2 - Test Management
 
Chapter 1 - Basic Concepts
Chapter 1 - Basic ConceptsChapter 1 - Basic Concepts
Chapter 1 - Basic Concepts
 
Test automation principles, terminologies and implementations
Test automation principles, terminologies and implementationsTest automation principles, terminologies and implementations
Test automation principles, terminologies and implementations
 
Istqb foundation level day 1
Istqb foundation level   day 1Istqb foundation level   day 1
Istqb foundation level day 1
 
ISTQB Performance Tester Sample Questions
ISTQB Performance Tester Sample QuestionsISTQB Performance Tester Sample Questions
ISTQB Performance Tester Sample Questions
 
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFL
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFLINTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFL
INTRODUCTION TO ISTQB FOUNDATION LEVEL - CTFL
 
테스트자동화와 TDD
테스트자동화와 TDD테스트자동화와 TDD
테스트자동화와 TDD
 
Understanding Unit Testing
Understanding Unit TestingUnderstanding Unit Testing
Understanding Unit Testing
 
Chapter 4 - Quality Characteristics for Technical Testing
Chapter 4 - Quality Characteristics for Technical TestingChapter 4 - Quality Characteristics for Technical Testing
Chapter 4 - Quality Characteristics for Technical Testing
 
Istqb chapter 5
Istqb chapter 5Istqb chapter 5
Istqb chapter 5
 
Selenium
SeleniumSelenium
Selenium
 
Chapter 5 - Reviews
Chapter 5 - ReviewsChapter 5 - Reviews
Chapter 5 - Reviews
 
software testing for beginners
software testing for beginnerssoftware testing for beginners
software testing for beginners
 
ISTQB Foundation Level Mock Exam 1
ISTQB Foundation Level Mock Exam 1ISTQB Foundation Level Mock Exam 1
ISTQB Foundation Level Mock Exam 1
 
02 software test plan template
02 software test plan template02 software test plan template
02 software test plan template
 
Unit Test
Unit TestUnit Test
Unit Test
 
ISTQB / ISEB Foundation Exam Practice -1
ISTQB / ISEB Foundation Exam Practice -1ISTQB / ISEB Foundation Exam Practice -1
ISTQB / ISEB Foundation Exam Practice -1
 

Viewers also liked

ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントYasuharu Nishi
 
Testing fundamentals
Testing fundamentalsTesting fundamentals
Testing fundamentalssunilabj
 
IoT時代と第3者検証
IoT時代と第3者検証IoT時代と第3者検証
IoT時代と第3者検証Yasuharu Nishi
 
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~Yasuharu Nishi
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからYasuharu Nishi
 
Viewpoint teacher's book
Viewpoint teacher's bookViewpoint teacher's book
Viewpoint teacher's bookBudlan
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証Yasuharu Nishi
 
Viewpoint level1 sequence
Viewpoint level1 sequenceViewpoint level1 sequence
Viewpoint level1 sequencehectorgv2
 

Viewers also liked (10)

ソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホントソフトハウスの品質保証のウソホント
ソフトハウスの品質保証のウソホント
 
Test. units 1 & 2
Test. units 1 & 2Test. units 1 & 2
Test. units 1 & 2
 
Testing fundamentals
Testing fundamentalsTesting fundamentals
Testing fundamentals
 
IoT時代と第3者検証
IoT時代と第3者検証IoT時代と第3者検証
IoT時代と第3者検証
 
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~日本のテスト産業の国際競争力~日本をソフトウェアテスト立国にしよう~
日本のテスト産業の国際競争力 ~日本をソフトウェアテスト立国にしよう~
 
Testing Standards List
Testing Standards ListTesting Standards List
Testing Standards List
 
ソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれからソフトウェアの品質保証の基礎とこれから
ソフトウェアの品質保証の基礎とこれから
 
Viewpoint teacher's book
Viewpoint teacher's bookViewpoint teacher's book
Viewpoint teacher's book
 
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
QAアーキテクチャの設計による説明責任の高いテスト・品質保証QAアーキテクチャの設計による説明責任の高いテスト・品質保証
QAアーキテクチャの設計による 説明責任の高いテスト・品質保証
 
Viewpoint level1 sequence
Viewpoint level1 sequenceViewpoint level1 sequence
Viewpoint level1 sequence
 

Similar to Viewpoint-based Test Requirement Analysis Modeling and Test Architectural Design

Primer on application_performance_modelling_v0.1
Primer on application_performance_modelling_v0.1Primer on application_performance_modelling_v0.1
Primer on application_performance_modelling_v0.1Trevor Warren
 
Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1SangeethaSubramaniam14
 
System models of sdlc- v model
System models of sdlc- v modelSystem models of sdlc- v model
System models of sdlc- v modelMinal Kashyap
 
Software Testing Principles and  Techniques
Software Testing Principles and  Techniques Software Testing Principles and  Techniques
Software Testing Principles and  Techniques suresh ramanujam
 
Lecture 2 (Software Processes)
Lecture 2 (Software Processes)Lecture 2 (Software Processes)
Lecture 2 (Software Processes)Education Front
 
Unit 8 software quality and matrices
Unit 8 software quality and matricesUnit 8 software quality and matrices
Unit 8 software quality and matricesPreeti Mishra
 
Primer on performance_requirements_gathering_v0.3
Primer on performance_requirements_gathering_v0.3Primer on performance_requirements_gathering_v0.3
Primer on performance_requirements_gathering_v0.3Trevor Warren
 
1 Ads
1 Ads1 Ads
1 Adslcbj
 
03 module2-090710094221-phpapp02
03 module2-090710094221-phpapp0203 module2-090710094221-phpapp02
03 module2-090710094221-phpapp02gurusaras01
 
Object Oriented Analysis
Object Oriented AnalysisObject Oriented Analysis
Object Oriented AnalysisAMITJain879
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified ProcessKumar
 
System Analysis and Design Project documentation
System Analysis and Design Project documentationSystem Analysis and Design Project documentation
System Analysis and Design Project documentationMAHERMOHAMED27
 
UNIT V TESTING.pptx
UNIT V TESTING.pptxUNIT V TESTING.pptx
UNIT V TESTING.pptxanguraju1
 
Se6162 analysis concept and principles
Se6162 analysis concept and principlesSe6162 analysis concept and principles
Se6162 analysis concept and principleskhaerul azmi
 
Case tools and modern process of system development
Case tools and modern process of system development Case tools and modern process of system development
Case tools and modern process of system development tushar217
 
15 object orienteddesign
15 object orienteddesign15 object orienteddesign
15 object orienteddesignrandhirlpu
 

Similar to Viewpoint-based Test Requirement Analysis Modeling and Test Architectural Design (20)

Primer on application_performance_modelling_v0.1
Primer on application_performance_modelling_v0.1Primer on application_performance_modelling_v0.1
Primer on application_performance_modelling_v0.1
 
Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1Object Oriented Analysis and Design Unit-1
Object Oriented Analysis and Design Unit-1
 
System models of sdlc- v model
System models of sdlc- v modelSystem models of sdlc- v model
System models of sdlc- v model
 
Software Testing Principles and  Techniques
Software Testing Principles and  Techniques Software Testing Principles and  Techniques
Software Testing Principles and  Techniques
 
3 analysis and design overview
3 analysis and design overview3 analysis and design overview
3 analysis and design overview
 
Lecture 2 (Software Processes)
Lecture 2 (Software Processes)Lecture 2 (Software Processes)
Lecture 2 (Software Processes)
 
Unit 8 software quality and matrices
Unit 8 software quality and matricesUnit 8 software quality and matrices
Unit 8 software quality and matrices
 
Rup
RupRup
Rup
 
Primer on performance_requirements_gathering_v0.3
Primer on performance_requirements_gathering_v0.3Primer on performance_requirements_gathering_v0.3
Primer on performance_requirements_gathering_v0.3
 
1 Ads
1 Ads1 Ads
1 Ads
 
03 module2-090710094221-phpapp02
03 module2-090710094221-phpapp0203 module2-090710094221-phpapp02
03 module2-090710094221-phpapp02
 
Object Oriented Analysis
Object Oriented AnalysisObject Oriented Analysis
Object Oriented Analysis
 
Rational Unified Process
Rational Unified ProcessRational Unified Process
Rational Unified Process
 
System Analysis and Design Project documentation
System Analysis and Design Project documentationSystem Analysis and Design Project documentation
System Analysis and Design Project documentation
 
UNIT V TESTING.pptx
UNIT V TESTING.pptxUNIT V TESTING.pptx
UNIT V TESTING.pptx
 
Se6162 analysis concept and principles
Se6162 analysis concept and principlesSe6162 analysis concept and principles
Se6162 analysis concept and principles
 
sdlc.pptx
sdlc.pptxsdlc.pptx
sdlc.pptx
 
SW Project Process.pptx
SW Project Process.pptxSW Project Process.pptx
SW Project Process.pptx
 
Case tools and modern process of system development
Case tools and modern process of system development Case tools and modern process of system development
Case tools and modern process of system development
 
15 object orienteddesign
15 object orienteddesign15 object orienteddesign
15 object orienteddesign
 

More from Yasuharu Nishi

Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?Yasuharu Nishi
 
Software-company Transformation
Software-company TransformationSoftware-company Transformation
Software-company TransformationYasuharu Nishi
 
What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?Yasuharu Nishi
 
What should you shift left
What should you shift leftWhat should you shift left
What should you shift leftYasuharu Nishi
 
Paradigm shifts in QA for AI products
Paradigm shifts in QA for AI productsParadigm shifts in QA for AI products
Paradigm shifts in QA for AI productsYasuharu Nishi
 
What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?Yasuharu Nishi
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)Yasuharu Nishi
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextYasuharu Nishi
 
CommentScreeen is good
CommentScreeen is goodCommentScreeen is good
CommentScreeen is goodYasuharu Nishi
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextYasuharu Nishi
 
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeRe-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeYasuharu Nishi
 
Teaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decadeTeaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decadeYasuharu Nishi
 
車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれからYasuharu Nishi
 
modern software qa - draft 1
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1Yasuharu Nishi
 
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Yasuharu Nishi
 
Software Frontloading and QA
Software Frontloading and QASoftware Frontloading and QA
Software Frontloading and QAYasuharu Nishi
 
Tomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsYasuharu Nishi
 
QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019Yasuharu Nishi
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentationYasuharu Nishi
 
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)Yasuharu Nishi
 

More from Yasuharu Nishi (20)

Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?Is No More QA Idealist Practical and Something Tasty?
Is No More QA Idealist Practical and Something Tasty?
 
Software-company Transformation
Software-company TransformationSoftware-company Transformation
Software-company Transformation
 
What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?What is quality culture? Is it something tasty?
What is quality culture? Is it something tasty?
 
What should you shift left
What should you shift leftWhat should you shift left
What should you shift left
 
Paradigm shifts in QA for AI products
Paradigm shifts in QA for AI productsParadigm shifts in QA for AI products
Paradigm shifts in QA for AI products
 
What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?What is quality engineer? Is it something tasty?
What is quality engineer? Is it something tasty?
 
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
品質を加速させるために、テスターを増やす前から考えるべきQMファンネルの話(3D版)
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
 
CommentScreeen is good
CommentScreeen is goodCommentScreeen is good
CommentScreeen is good
 
Demystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern contextDemystifying quality management for large scale manufacturing in modern context
Demystifying quality management for large scale manufacturing in modern context
 
Re-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decadeRe-collection of embedded software qa in the last decade
Re-collection of embedded software qa in the last decade
 
Teaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decadeTeaser - Re-collection of embedded software QA in the last decade
Teaser - Re-collection of embedded software QA in the last decade
 
車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから車載ソフトウェアの品質保証のこれから
車載ソフトウェアの品質保証のこれから
 
modern software qa - draft 1
modern software qa - draft 1modern software qa - draft 1
modern software qa - draft 1
 
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
Tomorrow's software testing for embedded systems ~明日にでも訪れてしまう組込みシステムのテストの姿~
 
Software Frontloading and QA
Software Frontloading and QASoftware Frontloading and QA
Software Frontloading and QA
 
Tomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systemsTomorrow's software testing for embedded systems
Tomorrow's software testing for embedded systems
 
QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019QA4AI JaSST Tokyo 2019
QA4AI JaSST Tokyo 2019
 
DeNA QA night #2 presentation
DeNA QA night #2 presentationDeNA QA night #2 presentation
DeNA QA night #2 presentation
 
LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)LINE Developer Meetup in Tokyo #39 Presentation (modified)
LINE Developer Meetup in Tokyo #39 Presentation (modified)
 

Recently uploaded

Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...Jaydeep Chhasatia
 
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine HarmonyLeveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmonyelliciumsolutionspun
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfTobias Schneck
 
Mastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example ProjectMastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example Projectwajrcs
 
About .NET 8 and a first glimpse into .NET9
About .NET 8 and a first glimpse into .NET9About .NET 8 and a first glimpse into .NET9
About .NET 8 and a first glimpse into .NET9Jürgen Gutsch
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampVICTOR MAESTRE RAMIREZ
 
Kawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies
 
Introduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptxIntroduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptxIntelliSource Technologies
 
Kubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptxKubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptxPrakarsh -
 
Top Software Development Trends in 2024
Top Software Development Trends in  2024Top Software Development Trends in  2024
Top Software Development Trends in 2024Mind IT Systems
 
eAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionseAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionsNirav Modi
 
AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyRaymond Okyere-Forson
 
IA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeIA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeNeo4j
 
Webinar - IA generativa e grafi Neo4j: RAG time!
Webinar - IA generativa e grafi Neo4j: RAG time!Webinar - IA generativa e grafi Neo4j: RAG time!
Webinar - IA generativa e grafi Neo4j: RAG time!Neo4j
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorShane Coughlan
 
ERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxAutus Cyber Tech
 
Why Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdfWhy Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdfBrain Inventory
 
Growing Oxen: channel operators and retries
Growing Oxen: channel operators and retriesGrowing Oxen: channel operators and retries
Growing Oxen: channel operators and retriesSoftwareMill
 
JS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIJS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIIvo Andreev
 

Recently uploaded (20)

Sustainable Web Design - Claire Thornewill
Sustainable Web Design - Claire ThornewillSustainable Web Design - Claire Thornewill
Sustainable Web Design - Claire Thornewill
 
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
Optimizing Business Potential: A Guide to Outsourcing Engineering Services in...
 
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine HarmonyLeveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
Leveraging DxSherpa's Generative AI Services to Unlock Human-Machine Harmony
 
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdfARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
ARM Talk @ Rejekts - Will ARM be the new Mainstream in our Data Centers_.pdf
 
Mastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example ProjectMastering Kubernetes - Basics and Advanced Concepts using Example Project
Mastering Kubernetes - Basics and Advanced Concepts using Example Project
 
About .NET 8 and a first glimpse into .NET9
About .NET 8 and a first glimpse into .NET9About .NET 8 and a first glimpse into .NET9
About .NET 8 and a first glimpse into .NET9
 
Deep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - DatacampDeep Learning for Images with PyTorch - Datacamp
Deep Learning for Images with PyTorch - Datacamp
 
Kawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in TrivandrumKawika Technologies pvt ltd Software Development Company in Trivandrum
Kawika Technologies pvt ltd Software Development Company in Trivandrum
 
Introduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptxIntroduction-to-Software-Development-Outsourcing.pptx
Introduction-to-Software-Development-Outsourcing.pptx
 
Kubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptxKubernetes go-live checklist for your microservices.pptx
Kubernetes go-live checklist for your microservices.pptx
 
Top Software Development Trends in 2024
Top Software Development Trends in  2024Top Software Development Trends in  2024
Top Software Development Trends in 2024
 
eAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspectionseAuditor Audits & Inspections - conduct field inspections
eAuditor Audits & Inspections - conduct field inspections
 
AI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human BeautyAI Embracing Every Shade of Human Beauty
AI Embracing Every Shade of Human Beauty
 
IA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG timeIA Generativa y Grafos de Neo4j: RAG time
IA Generativa y Grafos de Neo4j: RAG time
 
Webinar - IA generativa e grafi Neo4j: RAG time!
Webinar - IA generativa e grafi Neo4j: RAG time!Webinar - IA generativa e grafi Neo4j: RAG time!
Webinar - IA generativa e grafi Neo4j: RAG time!
 
OpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS CalculatorOpenChain Webinar: Universal CVSS Calculator
OpenChain Webinar: Universal CVSS Calculator
 
ERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptxERP For Electrical and Electronics manufecturing.pptx
ERP For Electrical and Electronics manufecturing.pptx
 
Why Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdfWhy Choose Brain Inventory For Ecommerce Development.pdf
Why Choose Brain Inventory For Ecommerce Development.pdf
 
Growing Oxen: channel operators and retries
Growing Oxen: channel operators and retriesGrowing Oxen: channel operators and retries
Growing Oxen: channel operators and retries
 
JS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AIJS-Experts - Cybersecurity for Generative AI
JS-Experts - Cybersecurity for Generative AI
 

Viewpoint-based Test Requirement Analysis Modeling and Test Architectural Design

  • 1. © NISHI, Yasuharu Viewpoint-based Test Requirement Analysis Modeling and Test Architectural Design 6th World Congress for Software Quality London, UK 2014/7/3(Thu) Nishi, Yasuharu The University of Electro-Communications, Japan
  • 2. © NISHI, Yasuharu2 Profile – Dr. NISHI, Yasuharu Assistant professor: the University of Electro-Communications, Japan (also providing consultancy service to industry on testing and TQM) President: Association of Software Test Engineering, Japan (ASTER) President: Japan Software Testing Qualifications Board (JSTQB) National delegate: ISO/IEC JTC1/SC7/WG26 Software testing Founder: Japan Symposium on Software Testing (JaSST) Founder: Testing Engineers’ Forum (Japanese community on software testing) Vice chair: SQiP/Software Quality Committee of JUSE (promoting organization of TQM) (SQiP has published the book of “SQuBOK: Software Quality Body of Knowledge” and is operating engineer certification on software quality) Research interest: Software testing, software quality/TQM , embedded software engineering, software process improvement, software project management, system safety
  • 3. © NISHI, Yasuharu3 Software Test Engineering Process • As software has got huge and complicated, test cases (= test suite) also get huge and complicated – such as » a test project with over 100,000 test cases » over 10 test levels » various test types such as load, configuration and security – You have to develop huge and complicated test suite systematically • But technologies on test planning or test strategy are just immature – Engineering work and management work for test development are confused • It is necessary to define software test engineering process to develop huge and complicated test suite systematically
  • 4. © NISHI, Yasuharu4 Independent RA is necessary for testing • Independent requirement analysis for testing is necessary – Requirement analysis for software isn’t usually exact or detail enough – Of course test requirement analysis depends on SUT and its dev. Process • Requirement analysis for testing should be more important – Test “planning” is just management word and NOT engineering word Test Architecture Design Test Requirement Analysis Test Detail Design Test Implementation VSTeP: Viewpoint-based Test Process Test Planning Test Design Test Implementation (Scripting) Part of typical test process Test Management (including planning for management)
  • 5. © NISHI, Yasuharu5 VSTeP • VSTeP(Viewpoint-based Software Test Engineering Process) is a generic test engineering process model focusing on test viewpoint – You can stress upper phase of test engineering process such as test requirement analysis and test architecture design which tend to be negligent – VSTeP drives you to good test suite, good review for test design, accumulation of knowledge and experience on testing – Reuse and improvement will be easy because you can do reverse-engineering of your past (unorganized) test suite – NGT (Notation for Generic Testing) is a made-in-Japan notation for Test Requirement Analysis and Test Architecture Design » Modeling skill like object-oriented design is essentially necessary Test Architecture Design Test Requirement Analysis Test Detail Design Test Implementation VSTeP: Viewpoint-based Test Process Test Management (including planning for management)
  • 6. © NISHI, Yasuharu6 Detail phase of VSTeP • TRA: Test Requirement Analysis – To make a test requirement model » To extract, organize and understand test requirement » To create a test requirement model which consists of test viewpoints, i.e. to create a viewpoint diagram • TAD: Test Architecture Design – To make a test architecture model » To re-organize test viewpoints into test containers as test types, levels and cycles for making test smooth » To assemble test viewpoints into test frames which is template for TDD • TDD: Test Detail Design – To make test cases » To set values in detail into test frames or test viewpoints • TI: Test Implementation – To make test scripts » To add detail information necessary to execution to test cases » To combine simple test scripts into a compound test script for making execution efficient
  • 7. © NISHI, Yasuharu7 Example of part of viewpoint diagram drawn for TRA E-mail client GUI Functions Environment Data Platform Network OS Hardware Kind of OS Version of OS Internet Explorer Test Item / SUT
  • 8. © NISHI, Yasuharu8 What is test viewpoint: abstract test case • Test cases has test values – ex) parameter: Kind of OS, values: Win7, WinXP, Win2000 – Test parameters are also called as test conditions and test values are also called as test coverage items – Test cases consists of test values • Viewpoints are abstract test cases – Bottom viewpoints means test parameters – Viewpoints don’t express any test values or test cases – Viewpoints can have hierarchical structure like classification trees or class diagrams – Viewpoints can be extracted from test conditions, test items and quality characteristics such as load, configuration and performance – Ideally viewpoints should indicate an INTENTION of a test case » Viewpoint diagram can be a repository of intentions of TCs Kind of OS OS Platform Environment - Win7 - WinXP - Win2000 Test Cases Bottom viewpoint Viewpoint Viewpoint
  • 9. © NISHI, Yasuharu9 Various test viewpoints – What should be exhausted: » Specs, functions, data etc. » Test conditions – Characteristics which should be achieved » Quality characteristics, non functional requirements etc. – Parts of test items » Funcs, Subsystems, modules etc. – Bugs » Errors and failures, bug patterns, weak points of test items etc. – Customer usage » Business, lifestyle etc. – Other parts of systems than software » Hardware units, hardware failures etc. – Test types » Load test, configuration test etc. – Test levels » Component test, system test etc. – Lists and/or diagrams developed until software testing » Use cases, State transition diagrams etc. • Test viewpoint is a point where test engineers focus an attention for grasping a big picture of test design – Test viewpoint is abstraction and source of test cases • Types of test viewpoints depend on organizations and/or test engineers OS
  • 10. © NISHI, Yasuharu10 • The word “viewpoint” is independent of roles Why “viewpoint” ? Test purpose Requirement! Test condition Parameter Test Environment Analyst Test Manager CT Researcher Test EngineerTest Operator
  • 11. © NISHI, Yasuharu11 Types of Hierarchical relationship • Test viewpoints have two fundamental relationships – Hierarchy relationships and Interaction relationships – Types of relationships can be expressed as “<<stereotype>>” • Hierarchical relationships can bear several meanings – is-a relationship: inheritance – has-a relationship: possession – There may be other hierarchical relationships » object-attribute and cause-effect is example OS Windows Memory Management Subsystem <<has-a>><<is-a>>
  • 12. © NISHI, Yasuharu12 Interactive relationships of viewpoints • Viewpoints can relate each other with interactive relationships – Non-hierarchical relationships are necessary: Interactive relationships – They can also bear several meanings: combination, sequential etc. – Lines without arrowhead represent “combinatorial relationships” – Arrows with an open head represent “sequential relationships” – Relationships can represent their meanings with <<stereotype>> – In this workshop interactive relationships without stereotypes represent combinatorial relationship Function Configuration <<sequence>> OS Web browser <<combination>>
  • 13. © NISHI, Yasuharu13 Relationships of viewpoints • Test viewpoints have two fundamental relationships – Hierarchy relationships » Detail a viewpoint step by step to reach test coverage item with a straight line » Have several types such as is-a, has-a, cause-effect, object-attribute – Interaction relationships » Connect test viewpoints to test combination of viewpoints with a curved line » Have several types such as combination (needs combinatorial testing) etc. • Types of relationships can be expressed as “<<stereotype>>” OS Version of OS <<has-a>><<is-a>> Interaction Hierarchy <<combination>> Viewpoint Filesystem
  • 14. © NISHI, Yasuharu14 Notation of viewpoint diagram in NGT Viewpoint Viewpoint Hierarchical Relationship Combinatorial Relationship Sequential Relationship <<combination>> <<stereotype>> Stereotype <<sequence>> ... ... ... ... ... ... Interactive Relationship Drawing tools for mindmaps are useful Test Container ...
  • 15. © NISHI, Yasuharu15 Viewpoint diagram is simple enough • Viewpoint diagram is simple enough to make a TRA/TAD model – More simple than classification tree OS Web browser OS Web browser 7 Vista IE Chrom e Firefox Classification Tree Viewpoint diagram
  • 16. © NISHI, Yasuharu16 TRA: Test requirement analysis • To extract, organize and understand test requirements – Requirements from customers to achieve » Functional requirement, non-functional requirement, business goals etc. – Constraints to achieve requirement from customers » Requirement of test project management such as efforts, costs etc. » Test tools and/or methods directly requested by customer especially – Information of current quality of the test item » Ex) bugs which were detected in prior reviews • To create a test requirement model on viewpoint diagram – Extract test viewpoints from test requirements – Detail test viewpoints and connect parent viewpoint and child viewpoints – Extract interaction relationships and connect viewpoints – Top-level viewpoints are most important for grasping a big picture, called “View” Views
  • 17. © NISHI, Yasuharu17 Refinement of a test requirement model • You can refine a test requirement model to make it clear and easy to understand – To detail viewpoints step by step to exhaust / list all test conditions – To move, divide or rename viewpoints if necessary – To check non MECE viewpoints in each layer and re-organize them as MECE » MECE: Mutually Exclusive and Collectively Exhaustive – To check whether brotherhood viewpoints have the same stereotypes of hierarchy connections – To check whether interactions would be better to change viewpoints
  • 18. © NISHI, Yasuharu18 VSTeP • VSTeP(Viewpoint-based Software Test Engineering Process) is a generic test engineering process model focusing on test viewpoint – You can stress upper phase of test engineering process such as test requirement analysis and test architecture design which tend to be negligent – VSTeP drives you to good test suite, good review for test design, accumulation of knowledge and experience on testing – Reuse and improvement will be easy because you can do reverse-engineering of your past (unorganized) test suite – NGT (Notation for Generic Testing) is a made-in-Japan notation for Test Requirement Analysis and Test Architecture Design » Modeling skill like object-oriented design is essentially necessary Test Architecture Design Test Requirement Analysis Test Detail Design Test Implementation VSTeP: Viewpoint-based Test Process Test Management (including planning for management)
  • 19. © NISHI, Yasuharu19 TAD: Test Architectural Design • Test architecture is a big picture of test suite – It is easy to grasp a big picture in test container level for large and complicated testing – Several viewpoints can be packed into a “test container” – Test containers can be test levels, test types and test cycles Structure t. Exception handling testing Multi bytes testing Boundary of arrays t. Unit testing Module calling t. Interruption handling testing Shared memory t. Device management t. Security testing Environment testing System testing Failure mgmt testing Load t. Function t. Cycle 1 Load t. Function t. Cycle 2 Integration testing
  • 20. © NISHI, Yasuharu20 Guides for good TAD • Some characteristics, attributes and patterns for software can be applied as guides for good TAD – “Quality Characteristics” for software are already available such as ISO/IEC 25000s » Functional Suitability / Performance efficiency / Compatibility / Usability / Reliability / Security / Maintainability / Portability – Other characteristics and design patterns for software design are also major » Coupling / Cohesion / Encapsulation / Responsibility » Design patterns such as MVC, singleton • Characteristics for TAD is important for good TAD – Cohesion and coupling » A test container should be packed with viewpoints with similar meanings » Test containers should have so few combinatorial relationships as possible – Maintainability / Internationaliziblity / Portability » Test containers which needs modifications should be easily identified in maintenance, internationalization and porting – Design patterns on viewpoint level could be another guide for TAD
  • 21. © NISHI, Yasuharu21 Quality attributes of test suite • Test architecture depends on required quality attributes of test suite – Test suite can have its own quality attribute if test suite is artifact – Ex) Maintainability of test suite – It doesn’t mean testing of quality attribute such as ISO/IEC 25000s/9126s Maintainability considered Simply divided Test architecture of small calculator
  • 22. © NISHI, Yasuharu22 Example of design pattern for TRA/TAD • Interaction Cluster Partitioning Pattern – if you can specify the source of combinatorial bugs is e-mail protocols and accept risks of bugs from other sources, you can reduce combinatorial test cases with ICP design pattern Client OS Client E-Mail Client Web Server OS E-mail server Anti- spam Client OS Client E-Mail Client Web Server OS E-mail server Anti- spam Client E-Mail E-mail server 3 values 4 values 2 values 2 values 3 values 4 values 3 values 4 values 2 values 2 values 3 values 4 values 4 values 3 values (3 x 4 x 2) x (2 x 3 x 4) = 576 cases (3 x 4 x 2) + (2 x 3 x 4) + (4 x 3) = 64 cases
  • 23. © NISHI, Yasuharu23 Research Question • Can Test Viewpoint Diagram reduce omission of test conditions? – Can test requirement modeling activity based on test viewpoints reduce omission of test conditions more than based on test conditions? – Is independent requirement “modeling” for testing is better than “deriving test conditions”? » Does “Deriving test conditions” mean just reading test base and writing them? • We conducted an experiment to compare “deriving test conditions” and “modeling test viewpoints” – Lecture from academia and experiment by industry
  • 24. © NISHI, Yasuharu24 Experiment for reducing omissions of test conditions • Overview of Experiment – Experiment for reducing omissions of test conditions in test requirement analysis phase by 2 teams using test conditions and test viewpoints » Team C: Selected test conditions using test conditions · Team C selected test cases by the same way as actual test design using spreadsheet · To compare easily, we redrew Team C’s test cases into Test Viewpoint Diagram » Team V: Selected test conditions using test viewpoint model · We made lectures on NGT/VSTeP and instructed them to model with Hierarchical relationships · They drew Test Viewpoint Diagram using a mindmap tool (freemind) – Both teams had 3-4 engineers and all engineers had 5-10 years experiences in software testing company mainly for embedded software • Test Base / SUT – User manual of a highly functional rice cooker – Manual mainly has 2 parts: » Operational instructions / functional descriptions » Recommendations of cooking rice, e.g. for Sushi
  • 25. © NISHI, Yasuharu25 Condition-based test requirement model 1 - No. Kind of rice Note Amount of rice Note Amount of water for cooking Note Pre-soak in water Note Amount of water for post-cooing Note 1 Polished rice 1 cup Same as gauge Not to be soaked 45ml 2 Pre-washed rice 2 cups More than gauge To be soaked Maximum 3 Stickyrice 3 cups Less than gauge 4 Raw rice 4 cups 5 Sprouted raw rice 5 cups 6 Partlymilled rice Level of milling isn't categolized 7 Sprouted rice 8 Cereals rice Test Values Test Conditons Precondition Policy for listing Condition-Value list No. To derive necessary test conditions and values for the rice cooking functions referring to operational steps of rice cooking - - - If post-cooking is started 1 2 3 4 5 To compare easily, we redrew the list into Test Viewpoint Diagram
  • 26. © NISHI, Yasuharu26 Viewpoint-based test requirement model
  • 27. © NISHI, Yasuharu27 Comparison of Condition-based and Viewpoint-based model Condition-based model Viewpoint-based model
  • 28. © NISHI, Yasuharu28 Result: no. of omissions of test conditions • Condition-based model omitted 13 more test conditions than Viewpoint-based model – Team C selected test conditions only which are explicitly written and easily identified as test conditions » Model is constructed in spreadsheet style – Team V modeled the SUT itself whether viewpoints are test conditions or not » Model is constructed in NGT/mindmap style Conditions explicitly written Omissions of Conditions Out-of-scope Condition-based Model All +13 0 Viewpoint-based Model All +0 (baseline) 18
  • 29. © NISHI, Yasuharu29 Detail of omitted test conditions out of Condition-based model • Ambiguously written input parameter: 1 condition – “Memory of a past cooking course” • Ambiguously written usecase: 1 condition – “Successive cooking” • Attributes of physical object explicitly written in Recommendation part of the manual: 6 conditions – “Degree of rinsing”, “pH of Water”, “Hardness of water”, “Temperature of water”, “Vinegar”, “Spices” • Ambiguously written expected results (behavior): 4 conditions – “Display before rice cooking”, “Display just when rice cooking starts”, “Display on buttons”, “Sounds” • expected result of physical object explicitly written in Recommendation part of the manual: 1 condition – “Badness of taste”
  • 30. © NISHI, Yasuharu30 Consideration on threats to validity • Lack of empirical study? – Single experiment can be biased and consistently extract wrong information – We gathered multiple engineers who have almost the same experience into each team • Lack of assessing the validity of cost and time measures? – Team V spend more time (but practically acceptable) on TRA than team C – Cost and time for TRA and TAD is often made more ignorable than TDD, TI and Test Execution • Lack of assessing the validity of domain skills of engineers? – All the engineers have almost the same domain skills as rice is the most popular food in Japan • Lack of evaluations for instances of growing size and scope? – Omissions are mainly about domain objects, i.e. physical objects, and ambiguous specifications – As size and scope of test grow, domain objects and ambiguous specifications will grow, VP model will be more effective • Lack of evaluations for integrity and testability of the test base – Integrity and testability of the test base grow, description on domain object will get richer and ambiguous specification will decrease – Although C model can reduce omissions, integrity and testability of test basis is limited actually. We can estimate VP model will be yet more effective • Lack of evaluations for refinement of model – We didn't measure or limit the number of refinement of model exactly – VP model was more refined than the C model – As good model written in good notation will be more refined, VP model can be estimated to be more effective.
  • 31. © NISHI, Yasuharu31 Conclusion • Independent test requirement analysis(TRA) is necessary • It is important to construct a test requirement model in TRA • In our experiment, test viewpoint model can reduce omission of test conditions more than test condition model • Scientific measurement of merit of “modeling” is rather difficult or not? – Empirical study is necessary
  • 32. © NISHI, Yasuharu Thank you for your kind attention NISHI, Yasuharu http://qualab.jp/ Yasuharu.Nishi@uec.ac.jp