Quality assurance at the design stage?

Question

How does quality assurance enter the software development phase?

What (if any) quality assurance activities are carried out at the design stage?

Answer 1

The most useful thing that QA can do at the design stage is to make sure that the supplied specification has a set of clear, verifiable goals. And use these goals to develop a testing plan.

This is so that they can answer two very important questions: " Can this be tested " and " How long will it take to test ." The first is important so that everyone knows the criteria for completing a project. And the second is necessary, since it is part of the total cost of sales.

Answer 2

Good design - testable design. IMO, you should always think about how you can test the software even at the design stage. Of course, the required level of attention will depend on whether you are performing a detailed design or a high-level architecture. Using a methodology such as TDD will draw attention to the importance of testing during design. Of course, one should not forget about other aspects of QA, such as usability testing, performance testing, etc. These are also important factors to consider when designing - both to achieve your goals, and to assess whether goals are achieved.

Answer 3

Design phase: Lack of quality during the design process may invalidate the requirements specification and may make proper implementation impossible. Industry practice shows that using a checklist during design helps improve design quality.

Have we considered all the requirements mentioned in the SRS? Was SRS placed under document control? Were the requirements related to the following functions considered during the design? Performance, security, concurrency, usability, portability, testability, language / database / OS / hardware requirements, development environment, compatibility, compliance with industry standards, scalability, exception handling

Is the chosen design methodology suitable for developing a type of software. Clarity: Is the project documentation clear / unambiguous? Could it be technically feasible Compatibility with existing software Determine the impact of this project on existing software We conducted an impact analysis Does this design describe the side effects of other software? Does this design have any dependency on any other related project?

Component Level: Are the interfaces well defined? The basic data structures are defined. Are the basic algorithms defined? Is the data / control flow defined? Data structure and algorithms Are data structures defined? Are access methods to data structures defined? Are algorithms defined? Do data structures and algorithms solve problems

Error / Exception Handling Are there data type errors? Does the software validate user input? Does the software provide explicit, non-threatening messages if an error occurs? (Quality of error messages). Can I restart the software from anywhere after an error? The software gracefully handles exception conditions, such as access violations and floating point errors.

Interfaces of the procedure. Does the number of actual parameters correspond to the number of formal parameters? Do the type and size of the actual parameters match the type and size of the formal parameters? Did we specify local and global functions correctly? Are global variables defined and invariably used in different modules? Are all documented messages (i.e. Parameters and general data)?

Procedure Level Does the procedure perform something very similar to an existing procedure? Is there a library procedure that will do the same? Is the procedure overly complex? Can the procedure be broken down into separate, more logical parts. Is the procedure an acceptable size?

Does the procedure perform only one logical thing? Does the procedure rely on a static variable of the procedure scale? Is the procedure easily stored and properly attached? Is it easy to check the procedure? Are any side effects described?

Quality Are design goals foreseen (reliability, flexibility, maintainability, performance, etc.)? Does the project meet its goals? (Tracking requirements) Is there evidence that more than one design option has been considered? Are there several design options along with a reason for accepting or rejecting them? Are design assumptions established? Are design compromises agreed upon? Is the design efficient? Is the structure repairable? Is the design portable? Can design changes change the environment with minimal changes? Whether the design parameter is controllable or are values ​​hardcoded in programs.

Requirements Does the design meet all the requirements? Is there traceability between design and system specifications? Can the design meet the requirements for development costs? Can it be done on time? Does the design stay within the limits of the memory requirements? Does the design stay within the limits of the required disk usage? Does the design meet the requirements of response time? Will the design handle the expected transaction rate? Will the design handle the expected volumes of the data stream?

Answer 4

Quality assurance does not quite fit into the design phase. QA deals with fixing defects after they occur, which was common practice in the last millennium. Of course, there may be defects in the specification documents created at the time of creation, but in addition to those that you do not have a product, therefore, no defects can be found.

Quality management, on the other hand, is the path to the 21st century. This is a comprehensive approach to defect prevention. It is extremely important to integrate it into your project from the very beginning, so it definitely should fit into the design.

There are thousands of books and web pages about this topic, but IMO are the most important things:

• Learn about previous errors. Analyze similar projects and see what were the biggest mistakes. Try to avoid them in your design.
• After completing the project, perform a post-action check to find out what was skipped in step 1 above. Use this information in the next similar project.

Answer 5

There is a rougly architectural design phase and a detailed design phase.

QA actions at these stages may include:

• Ensuring that the architecture supports all (non) functional requirements
• Ensuring that all important modules are covered and properly designed in detailed designs
• Ensuring that project documents are managed by configuration (changes)
• Performing (formal) reviews to review the architecture and its documentation
• Enforcing predefined design standards.

It is sometimes called "Critical Software Design Reviews". You can see a checklist of examples here .

Answer 6

To understand how it fits in your specific development process, you should consider:

• Product quality depends on the whole team. Each role group should bring its respective value to the project (bring help to the project if you feel that some skills are missing). It is not necessary for the quality team to carry out actions that should / should be expert evaluations, i.e. Architecture / Design Reviews.
• QA is not the place where you throw away any missing responsibilities in the project, i.e. project management should take care of the budget, risks, etc. His responsibility for this role must be guaranteed. In addition, you use audits + mentoring to help each team member fulfill their roles.
• QA contributes to architecture / design based on their perception that it should be tested. They actively consider / plan / design how they will test the indicated architecture / design, which is an important factor for effective / successful testing.
• QA contributes to various artifacts, as the development side does. Always focused on how it relates to the goals they want to achieve.
• QA needs to be prepared to start testing automation from the very beginning of development. It also involves important coordination with developers and a plan to take a development approach that will allow the qa team to continually / gradually test automation.
• Just as development activities have priority / priority, the qa team should do the same. There are so many testing options that can be performed in a project that it is actually impossible to do all of this with full coverage. This will affect qa's efforts in the project, and will also help to make clear what is left out of scope on the qa team side (there may be other measures to solve this problem from other roles).
• How and when the actions performed are closely related to the processes and methods used. The simplification will be as follows: if you are involved in development activities / efforts, there is something meaningful for qa efforts that must continue.
• Most of the roles and actions in different methodologies allow you to add to various aspects of project quality and related product (s).