Integration of Software Testing in Agile Development
VerifiedAdded on 2023/02/01
|9
|2294
|22
AI Summary
This assignment discusses the integration of software testing in agile development and the relevance of the AS/NZS ISO/IEC/IEEE 29119 Software Testing standard. It explores the different parts of the standard and their application in various life cycle models. The paper also discusses the similarities and differences between the standard and agile development.
Contribute Materials
Your contribution can guide someone’s learning journey. Share your
documents today.
Running head: SOFTWARE TESTING
SOFTWARE TESTING
Name of Student
Name of University
Author’s Note
SOFTWARE TESTING
Name of Student
Name of University
Author’s Note
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
1SOFTWARE TESTING
Introduction
The standard chosen for this particular assignment is AS/NZS ISO/IEC/IEEE 29119
Software Testing. The main purpose of this standard series is defining a set of various standards
for the purpose of software testing which is internationally agreed, this standard can be used by
organizations during performing the process of testing, and it can be used by various
organizations of any size and irrespective of the services provided by them (Chen, Chen and
Chen 2018). The part ISO/IEC/IEEE 29119-2 of the standard does not refer to a process for test
design as well as implementation, it refers to a set of techniques that would be used within the
ISO/ICE/IEEE 29119-2.
Responses to the questions for standard
The name of the standard is AS/NZS ISO/IEC/IEEE 29119 Software Testing.
The copyright for the standard is hold by the Joint Standards Australia/ Standards New
Zealand Committee IT- 015, Software and Systems Engineering.
Amongst all the acknowledged contributors to the document, the universities that were
involved NAVSEA, ASQ; KOMBIT, IMBUS, IBM Research, Janaagraha, Planit Testing,
Software Testing Alliances (Laplante 2017).
The standard provides an international standard which defines the techniques of software
testing design which can be utilized within the test design as well as implementation processes
that has been defined in ISO/IEC/IEEE 29112-2 (Mall 2018). This particular part of the standard
does not prescribe the process for test design as well as implementation. The main intent of this
standard is to describe a particular series of technique which has a wide acceptance in the
industry of software testing.
Introduction
The standard chosen for this particular assignment is AS/NZS ISO/IEC/IEEE 29119
Software Testing. The main purpose of this standard series is defining a set of various standards
for the purpose of software testing which is internationally agreed, this standard can be used by
organizations during performing the process of testing, and it can be used by various
organizations of any size and irrespective of the services provided by them (Chen, Chen and
Chen 2018). The part ISO/IEC/IEEE 29119-2 of the standard does not refer to a process for test
design as well as implementation, it refers to a set of techniques that would be used within the
ISO/ICE/IEEE 29119-2.
Responses to the questions for standard
The name of the standard is AS/NZS ISO/IEC/IEEE 29119 Software Testing.
The copyright for the standard is hold by the Joint Standards Australia/ Standards New
Zealand Committee IT- 015, Software and Systems Engineering.
Amongst all the acknowledged contributors to the document, the universities that were
involved NAVSEA, ASQ; KOMBIT, IMBUS, IBM Research, Janaagraha, Planit Testing,
Software Testing Alliances (Laplante 2017).
The standard provides an international standard which defines the techniques of software
testing design which can be utilized within the test design as well as implementation processes
that has been defined in ISO/IEC/IEEE 29112-2 (Mall 2018). This particular part of the standard
does not prescribe the process for test design as well as implementation. The main intent of this
standard is to describe a particular series of technique which has a wide acceptance in the
industry of software testing.
2SOFTWARE TESTING
The application of standard results in helping organizations to carry out the process of
testing. There are various techniques that can be used by organizations; these techniques follow
the test design as well as process of implementation which is defined in the ISO/IEC/IEEE
29119-2
The key terms and understanding that are needed for the standard to be understood as
well as applied include systems, objects, software items, classes, design specifications, user
guides and requirements documentations (Beyer 2019). The aspect which requires to be
understood include the fact that a test condition is a particular testable aspect of a particular test
team like function, feature, transaction, quality attribute and structural element which is
identified as a basic step for testing. This has to be achieved by discussing with various
stakeholders whose attributes are to be tested.
The relevance of software testing to the standard
The IEEE Std 29119 is a specific set of standards that is agreed upon internationally, its
purpose was to support the process of software testing. IEEE Std 29119 has five parts that have
different operations and features (Garousi and Mäntylä 2016). The five parts are as follows
IEEE Std 29119-1: concepts and definitions
IEEE Std 29119-2: processes of testing
IEEE Std 29119-3: documentation of testing
IEEE Std 29119-4: techniques of testing
IEEE Std 29119-5: keyword driven testing
IEEE Std 29119 is actually intended for the purpose of replacing the existing standards
for software testing. The previously used standards for software testing are IEEE 829 test
The application of standard results in helping organizations to carry out the process of
testing. There are various techniques that can be used by organizations; these techniques follow
the test design as well as process of implementation which is defined in the ISO/IEC/IEEE
29119-2
The key terms and understanding that are needed for the standard to be understood as
well as applied include systems, objects, software items, classes, design specifications, user
guides and requirements documentations (Beyer 2019). The aspect which requires to be
understood include the fact that a test condition is a particular testable aspect of a particular test
team like function, feature, transaction, quality attribute and structural element which is
identified as a basic step for testing. This has to be achieved by discussing with various
stakeholders whose attributes are to be tested.
The relevance of software testing to the standard
The IEEE Std 29119 is a specific set of standards that is agreed upon internationally, its
purpose was to support the process of software testing. IEEE Std 29119 has five parts that have
different operations and features (Garousi and Mäntylä 2016). The five parts are as follows
IEEE Std 29119-1: concepts and definitions
IEEE Std 29119-2: processes of testing
IEEE Std 29119-3: documentation of testing
IEEE Std 29119-4: techniques of testing
IEEE Std 29119-5: keyword driven testing
IEEE Std 29119 is actually intended for the purpose of replacing the existing standards
for software testing. The previously used standards for software testing are IEEE 829 test
3SOFTWARE TESTING
documentation, IEEE 1008 unit testing, BS 7925-1 vocabulary of terms in the process of
software testing, BS 7925-2 software component testing standards.
The IEEE Std 29119-1, concepts and definition, correlates to the BS 7925-1, it serves the
purpose of a glossary of various definitions of the testing terms as well as concepts that
are used in overall IEEE 29119 standard. The IEEE Std 29119-2, this step is known as
testing process and it describes the software testing processes at numerous levels (Briand,
Nejati and Sabetzadeh 2016). In this stage the processes are supposed to be generic in
nature because they are able to be implemented in many organizations for the purpose of
any sort of software testing as well as any sort of software development life cycle model.
This usually focuses on the approaches that are risk based. The primary goal is of
mitigating various risks. The next step that is IEEE Std 29119-3, is named as test
documentation (Kanewala, Bieman and Ben‐Hur 2016). This stage provides templates as
well as examples of the test documentation. The work products obtained from this stage
is aligned with various test processes that have been describes in the previous stage and
hence cover the test management level, dynamic test level and organizational level. IEEE
Std 29119-4, test techniques is a description of the techniques of software testing design
which align with various test processes that have been mentioned in IEEE Std 29119-2.
The document describes the ways to drive various test conditions, test cases and test
coverage items. The last stage IEEE Std 29119-5, keyword driven testing is the portion
that has been most recently published (Takanen, Demott and Miller 2018). This describes
the utilization of keyword driven testing as a form of major strategy of the modular
testing for using the test automation frameworks.
Discussion
documentation, IEEE 1008 unit testing, BS 7925-1 vocabulary of terms in the process of
software testing, BS 7925-2 software component testing standards.
The IEEE Std 29119-1, concepts and definition, correlates to the BS 7925-1, it serves the
purpose of a glossary of various definitions of the testing terms as well as concepts that
are used in overall IEEE 29119 standard. The IEEE Std 29119-2, this step is known as
testing process and it describes the software testing processes at numerous levels (Briand,
Nejati and Sabetzadeh 2016). In this stage the processes are supposed to be generic in
nature because they are able to be implemented in many organizations for the purpose of
any sort of software testing as well as any sort of software development life cycle model.
This usually focuses on the approaches that are risk based. The primary goal is of
mitigating various risks. The next step that is IEEE Std 29119-3, is named as test
documentation (Kanewala, Bieman and Ben‐Hur 2016). This stage provides templates as
well as examples of the test documentation. The work products obtained from this stage
is aligned with various test processes that have been describes in the previous stage and
hence cover the test management level, dynamic test level and organizational level. IEEE
Std 29119-4, test techniques is a description of the techniques of software testing design
which align with various test processes that have been mentioned in IEEE Std 29119-2.
The document describes the ways to drive various test conditions, test cases and test
coverage items. The last stage IEEE Std 29119-5, keyword driven testing is the portion
that has been most recently published (Takanen, Demott and Miller 2018). This describes
the utilization of keyword driven testing as a form of major strategy of the modular
testing for using the test automation frameworks.
Discussion
Secure Best Marks with AI Grader
Need help grading? Try our AI Grader for instant feedback on your assignments.
4SOFTWARE TESTING
This assignment discusses regarding the integration of the standard to the process of agile
development. Agile development is usually a broad term that encompasses a set of practices
which promotes the values in the Agile Manifesto. Usually agile is meant to enhance the actual
ability to respond to a constant change in an effective manner. This change is usually present in
the process of software development. Agile promotes continuous as well as small incremental
releases of the working software (Binder 2018). Agile describes the techniques of the how in the
process of software development. Examples of this include Kanban and Scrum. In agile
development, the process of software testing takes place in different manner as compared to the
traditional method such as waterfall methodology. Hence it can be said that the similarities
between the standard and the paper includes the fact that both refer to the process of testing. The
paper has referred to the implementation of software in agile. The processes mentioned in the
standard have been used by the paper as well for the purpose of agile.
Testing is not performed in a distinct and separate phase after the coding is done; the
agile software testing is done in concurrence with the process of coding. Besides this, testing is
integrated in the development team along with the related stakeholders and distinction between
the testers and developers are not of much importance (Leicht, Knop and Blohm 2016). In the
Agile methods, there does not exist any true standard or definitive strategy for testing whereas
the test driven development is a popular method of testing software in Agile, it is not much
required. Agile does not have any technically prescribed processes for testing processes, only the
fact is that the process of software development stays responsive to any change. Agile is a strong
interpretation and does not actually prescribe or need any kind of standard for testing. Hence a
testing standard will not be valuable in the Agile environment (Böhme and Paul 2016). The
standard gives a common platform on which the community would be able to agree on the
This assignment discusses regarding the integration of the standard to the process of agile
development. Agile development is usually a broad term that encompasses a set of practices
which promotes the values in the Agile Manifesto. Usually agile is meant to enhance the actual
ability to respond to a constant change in an effective manner. This change is usually present in
the process of software development. Agile promotes continuous as well as small incremental
releases of the working software (Binder 2018). Agile describes the techniques of the how in the
process of software development. Examples of this include Kanban and Scrum. In agile
development, the process of software testing takes place in different manner as compared to the
traditional method such as waterfall methodology. Hence it can be said that the similarities
between the standard and the paper includes the fact that both refer to the process of testing. The
paper has referred to the implementation of software in agile. The processes mentioned in the
standard have been used by the paper as well for the purpose of agile.
Testing is not performed in a distinct and separate phase after the coding is done; the
agile software testing is done in concurrence with the process of coding. Besides this, testing is
integrated in the development team along with the related stakeholders and distinction between
the testers and developers are not of much importance (Leicht, Knop and Blohm 2016). In the
Agile methods, there does not exist any true standard or definitive strategy for testing whereas
the test driven development is a popular method of testing software in Agile, it is not much
required. Agile does not have any technically prescribed processes for testing processes, only the
fact is that the process of software development stays responsive to any change. Agile is a strong
interpretation and does not actually prescribe or need any kind of standard for testing. Hence a
testing standard will not be valuable in the Agile environment (Böhme and Paul 2016). The
standard gives a common platform on which the community would be able to agree on the
5SOFTWARE TESTING
practices that are required to say the entire testing process is valid. The main differences between
the paper and the standard are that the paper does not consider it mandatory to use all the stages
for agile but the standard considers the stages to be the priority. The paper describes processes of
implementing the standard in agile whereas the standard describes regarding the process of
testing in any industry.
Integration of software testing in Agile development
Testing process in agile development usually aims at various goals compared to the
traditional iteration life process models. An example of this is waterfall model. At the initial
stage of integration, the process does not require any firm requirements; it does not require any
solid and fixed plan for architecture. One of the major goals in every iteration includes having
specific working software (Arcuri 2018). The term of working software implies to the existence
of requirements as well as the process of verifying the requirements after they have been
informal and does not exist in the form of formal documentation. This has provided the idea that
in case the activity of development is iterative as well as incremental, then the formation of test
plans, test tools policy, test documentation can be incremental and iterative. This paper presents
an effort to form plans, policy and documentation in scrum setting.
Conclusion
The IEEE standard 29119 that represents the software and systems engineering- software
testing is divided into five parts. These parts include concepts and definitions, test
documentation, test processes, keyword driven testing and test techniques. It has been designed
for the purpose of designing the needs of various life cycle models such as agile, sequential and
evolutionary. The model of life cycle can be seen as an answer to the when and how questions
such as when and how to carry out the desirable activities. The standard 29119 is viewed as a
practices that are required to say the entire testing process is valid. The main differences between
the paper and the standard are that the paper does not consider it mandatory to use all the stages
for agile but the standard considers the stages to be the priority. The paper describes processes of
implementing the standard in agile whereas the standard describes regarding the process of
testing in any industry.
Integration of software testing in Agile development
Testing process in agile development usually aims at various goals compared to the
traditional iteration life process models. An example of this is waterfall model. At the initial
stage of integration, the process does not require any firm requirements; it does not require any
solid and fixed plan for architecture. One of the major goals in every iteration includes having
specific working software (Arcuri 2018). The term of working software implies to the existence
of requirements as well as the process of verifying the requirements after they have been
informal and does not exist in the form of formal documentation. This has provided the idea that
in case the activity of development is iterative as well as incremental, then the formation of test
plans, test tools policy, test documentation can be incremental and iterative. This paper presents
an effort to form plans, policy and documentation in scrum setting.
Conclusion
The IEEE standard 29119 that represents the software and systems engineering- software
testing is divided into five parts. These parts include concepts and definitions, test
documentation, test processes, keyword driven testing and test techniques. It has been designed
for the purpose of designing the needs of various life cycle models such as agile, sequential and
evolutionary. The model of life cycle can be seen as an answer to the when and how questions
such as when and how to carry out the desirable activities. The standard 29119 is viewed as a
6SOFTWARE TESTING
specific answer to the questions that arise in the form of what such as what are the activities that
are desirable in nature and can be done so that the output is not much far away from the
community norms. The main premise is that in agile, though there are many more characteristics
that are valued; there are still some processes, documentation, plans, tools and many more that
are needed. Their value can never be zero. This research paper aims at bringing about a different
line of research, Test maturity model integration in the picture. The TMMi suggests different
levels, they are initial, defined, managed, optimized and measured. The exact amount of plans,
processes, tools and documentation in a setting of Agile could be reasonably engaged by the
level of maturity that has been defined by TMMi. The paper provides a specific example of the
tailored conference of IEEE 29119 which targets TMMi maturity of level two, it is suitable for
most of the agile projects.
specific answer to the questions that arise in the form of what such as what are the activities that
are desirable in nature and can be done so that the output is not much far away from the
community norms. The main premise is that in agile, though there are many more characteristics
that are valued; there are still some processes, documentation, plans, tools and many more that
are needed. Their value can never be zero. This research paper aims at bringing about a different
line of research, Test maturity model integration in the picture. The TMMi suggests different
levels, they are initial, defined, managed, optimized and measured. The exact amount of plans,
processes, tools and documentation in a setting of Agile could be reasonably engaged by the
level of maturity that has been defined by TMMi. The paper provides a specific example of the
tailored conference of IEEE 29119 which targets TMMi maturity of level two, it is suitable for
most of the agile projects.
Paraphrase This Document
Need a fresh take? Get an instant paraphrase of this document with our AI Paraphraser
7SOFTWARE TESTING
References
Arcuri, A., 2018. An experience report on applying software testing academic results in industry:
We need usable automated test generation. Empirical Software Engineering, 23(4), pp.1959-
1981.
Beyer, D., 2019, April. International competition on software testing (Test-Comp).
In International Conference on Tools and Algorithms for the Construction and Analysis of
Systems (pp. 167-175). Springer, Cham.
Binder, R.V., 2018, April. Optimal scheduling for combinatorial software testing and design of
experiments. In 2018 IEEE International Conference on Software Testing, Verification and
Validation Workshops (ICSTW) (pp. 295-301). IEEE.
Böhme, M. and Paul, S., 2016. A probabilistic analysis of the efficiency of automated software
testing. IEEE Transactions on Software Engineering, 42(4), pp.345-360.
Briand, L., Nejati, S., Sabetzadeh, M. and Bianculli, D., 2016, May. Testing the untestable:
model testing of complex software-intensive systems. In Proceedings of the 38th international
conference on software engineering companion(pp. 789-792). ACM.
Chen, N., Chen, E.W. and Chen, I.S., 2018. Integrating Software Testing Standard
ISO/IEC/IEEE 29119 to Agile Development. In Proceedings of the International Conference on
Software Engineering Research and Practice (SERP) (pp. 89-95). The Steering Committee of
The World Congress in Computer Science, Computer Engineering and Applied Computing
(WorldComp).
Garousi, V. and Mäntylä, M.V., 2016. When and what to automate in software testing? A multi-
vocal literature review. Information and Software Technology, 76, pp.92-117.
References
Arcuri, A., 2018. An experience report on applying software testing academic results in industry:
We need usable automated test generation. Empirical Software Engineering, 23(4), pp.1959-
1981.
Beyer, D., 2019, April. International competition on software testing (Test-Comp).
In International Conference on Tools and Algorithms for the Construction and Analysis of
Systems (pp. 167-175). Springer, Cham.
Binder, R.V., 2018, April. Optimal scheduling for combinatorial software testing and design of
experiments. In 2018 IEEE International Conference on Software Testing, Verification and
Validation Workshops (ICSTW) (pp. 295-301). IEEE.
Böhme, M. and Paul, S., 2016. A probabilistic analysis of the efficiency of automated software
testing. IEEE Transactions on Software Engineering, 42(4), pp.345-360.
Briand, L., Nejati, S., Sabetzadeh, M. and Bianculli, D., 2016, May. Testing the untestable:
model testing of complex software-intensive systems. In Proceedings of the 38th international
conference on software engineering companion(pp. 789-792). ACM.
Chen, N., Chen, E.W. and Chen, I.S., 2018. Integrating Software Testing Standard
ISO/IEC/IEEE 29119 to Agile Development. In Proceedings of the International Conference on
Software Engineering Research and Practice (SERP) (pp. 89-95). The Steering Committee of
The World Congress in Computer Science, Computer Engineering and Applied Computing
(WorldComp).
Garousi, V. and Mäntylä, M.V., 2016. When and what to automate in software testing? A multi-
vocal literature review. Information and Software Technology, 76, pp.92-117.
8SOFTWARE TESTING
Kanewala, U., Bieman, J.M. and Ben‐Hur, A., 2016. Predicting metamorphic relations for testing
scientific software: a machine learning approach using graph kernels. Software testing,
verification and reliability, 26(3), pp.245-269.
Laplante, P.A., 2017. Requirements engineering for software and systems. Auerbach
Publications.
Leicht, N., Knop, N., Blohm, I., Müller-Bloch, C. and Leimeister, J.M., 2016. When is
crowdsourcing advantageous? the case of crowdsourced software testing.
Mall, R., 2018. Fundamentals of software engineering. PHI Learning Pvt. Ltd..
Takanen, A., Demott, J.D., Miller, C. and Kettunen, A., 2018. Fuzzing for software security
testing and quality assurance. Artech House.
Kanewala, U., Bieman, J.M. and Ben‐Hur, A., 2016. Predicting metamorphic relations for testing
scientific software: a machine learning approach using graph kernels. Software testing,
verification and reliability, 26(3), pp.245-269.
Laplante, P.A., 2017. Requirements engineering for software and systems. Auerbach
Publications.
Leicht, N., Knop, N., Blohm, I., Müller-Bloch, C. and Leimeister, J.M., 2016. When is
crowdsourcing advantageous? the case of crowdsourced software testing.
Mall, R., 2018. Fundamentals of software engineering. PHI Learning Pvt. Ltd..
Takanen, A., Demott, J.D., Miller, C. and Kettunen, A., 2018. Fuzzing for software security
testing and quality assurance. Artech House.
1 out of 9
Related Documents
Your All-in-One AI-Powered Toolkit for Academic Success.
+13062052269
info@desklib.com
Available 24*7 on WhatsApp / Email
Unlock your academic potential
© 2024 | Zucol Services PVT LTD | All rights reserved.