Introduction
The following is a report for the FMEA/Quality Risk Register developed for Golden Goose Limited. The report incorporates three major parts:
Domains: This section will look at six of the key domains that were used for testing. For each domain, its purpose is described, its importance in the test is explained and the link between the business requirements and the FMEA /QRR items is shown. Also identified, are at least 2 test constraints for each domain as well as the department manager responsible for ‘signing off’ each domain test.
Test phases: This section will look into test phases from a broader perspective. Four main stages of software testing will be analyzed looking into the various characteristics of each phase, the timing, and the purpose of each phase. Finally, this section will look at the controls that govern each phase with a particular focus on the entry and exit criteria.
Implied requirements: Finally, the report will look at the implied requirements that emerge after developing the FMEA/QRR. Each of these implied requirements will be assigned an individual unique name, before it is briefly described, followed by a concise look at its impact on quality.
Domains
Domain testing, according to Kaner (n.d.), is illustrated as the stratified testing technique of choosing a few test cases from several candidate test cases available. This method is particularly prevalent in software testing. In the FMEA/Quality Risk Register developed for Golden Goose Limited, there were several candidate test domains. This report will focus on the six key domains which include;
Product inquiry: This is categorized as a key domain for this system due to its immense significance to the company. Customers use this domain to find information about various products directly from the system. Golden Goose Limited, being a product-based company, requires a place to showcase their products, hence the importance of this domain for this system. The two key test constraints used when testing this domain are;
The search function
This is ‘signed off by the business department manager. This is because it is within his/her department that business matters are regulated hence they know what they want when using the search function.
Product information
This area of the domain is ‘signed off by the business department. This is simply because it is in charge of the overall business process, thus has a better understanding of the product information a customer should find.
Security: The security issue is core to any system. Good security infrastructure ensures that a system is not easily manipulated by malicious people in a bid to steal from the user. The security domain is used to ensure that the system is not easily manipulated from unauthorized sources. Security tests are important as they lead to a secure system thus winning customer confidence. Below are the two main constraints that are checked when testing for security:
Compliance
This includes factors such as legality and standards.
They are approved by the ICT department as they are aware of the standards and legality issues when dealing with software.
Passwords
They are approved by the ICT department manager because he/she has a better understanding of how password safety is achieved.
Performance and capacity: A good system should ensure that it meets its expected user capacity, failure to which the company suffers losses in business. This is tested during domain testing to ensure the standards are met. The two key constraints that are used to test this domain are:
Response time
Tested and ‘signed off by the ICT department as they understand how the system should respond including finer details such as response time.
b. Reliability: The extent to which the system can be expected to meet its purpose accurately.
Tested and ‘signed off by the business department as they understand the business role of the system.
Payment/ Transactions: The extent to which the system can handle payments from customers is also a key domain to test. This is particularly important as it is from the payments that the company sustains itself. A functional payment domain ensures that the company is always in business even during off-hours, as customers can still be able to make payments. The two key constraints used for testing this domain are;
Security
This is tested and ‘signed off by the ICT department manager. This is because he/she has a better understanding of the general security loopholes of any system.
Correctness
This is tested and ‘signed off by the business department manager. This is because he/she understands the process by which the transactions are required to flow.
Account creation: This domain is a vital part of this system. This is because it is practically the source of all business for the company. It is through these accounts that customers can carry out transactions. The two main constraints used when testing this domain are;
Security
The ICT department ‘signs off’ and tests this constraint of the domain. This is in essence because they have a better understanding of system security.
Integrity
This is tested and ‘signed off by the ICT department. This is because they are aware of the privileges all users of the system have.
Account modification: This domain is invaluable for the system, as the accounts are fundamentally the main areas that the company uses to make transactions with customers. Therefore, this domain needs to be functional and should allow the customer to change his/her original details lest the company risks losing valuable business. The two major constraints that are checked when testing this domain are;
Security
The ICT department tests and ‘signs off’ this constraint of the domain. They are aware of all security requirements of any system.
Integrity
This is tested and ‘signed off by the ICT department. This is because they are aware of the privileges all users of the system have.
Test phases
During system testing, various phases are involved, each with its focus points. The various testing phases include:
Unit testing
The main goal of carrying out unit testing is to pick out a single module of a system in isolation and look at its importance to the overall system. It is more like real-world debugging. Characteristics of unit testing include; it falls under white box testing. In some cases, it is performed during the coding stage. This requires a good understanding of the internal code work and involves developing test cases and test plans. It takes the shortest time among all testing phases. It essentially rectifies errors in the code.
Integration testing
This phase falls immediately after the unit testing. Its characteristics include; it falls under white box testing, it uses the test cases from unit testing and it is fairly easy. It eliminates the finer errors that were left out during unit testing. According to Mochal (2001), this stage lasts longer than unit testing as the developers always look into the finest details.
System testing
This is, perhaps, the phase that consumes the most time during system testing. This is the last stage for developers to test the system before releasing it to users. This phase is characterized by various factors such as; it is time-consuming, it falls under the black box category, and feedback obtained is used to make changes before release to the mass market.
User acceptance testing
This phase is mostly linked to system testing. They both have similar characteristics. It is in this phase that feedback is captured from users. During this phase, the system is released to the market for all day-to-day users. The main purpose of this phase, as the name suggests, is to capture users’ feedback and thoughts on the system to help in making changes and improvements.
Implied requirements
This section records all the requirements that have been implied during the development of the FMEA/Quality Risk Register. They include:
Login: This falls under the security domain. The system has to ensure that during login the user cannot be logged in with blank details. This helps maintain the system’s integrity. It also ensures that customer information is protected.
Login: This also falls under the security domain. The system must ensure that the customer password and username do match before logging in. This will ensure that the system is trusted by the customer. It also guarantees that a customer’s information is well-protected and secure thus gaining customer confidence and hence improving business.
Superannuation: This falls under the payment domain. Superannuation means that the system can do correct calculations, especially calculations dealing with payments. A system that has errors on this part will lead to a loss of customer confidence and trust. This will in turn lead to a loss in business.
Customer payment history: This falls under the domain of payment. The system must ensure that it accurately records and traces customer transactions and the information made visible to the customer. This will allow customers to track transaction history and thus in case of complaints; solutions can arrive easily. This adjustment will help boost customer trust.
Banking reports: This falls underpayments domain. This requirement will ensure that customers can view all the bank reports from their accounts and thus track how the company deducted money. This works towards boosting customer trust and confidence in the system.
Approvals: This falls under the security domain. This requirement will ensure that only authorized users can sanction payments. This will inhibit instances of theft from the customer and in turn improve system quality. The customer will also feel secure and trust the system.
Validation: This falls under the data quality domain. This requirement essentially ensures that all data input into the system is correct. This will limit instances of data discrepancies, improve the system quality and make it better for the users.
Data security: This falls under the data quality and the security domains. The system should ensure that all data transmitted over the system is encrypted. This protects the system from data theft, ensuring that the customer’s, as well as the company’s information, is secured. This requirement improves the quality of the system making it trustworthy among its users.
Data retention: This falls under the category of data quality. The system should be able to hold data without losing it. This makes the system credible thus increasing user trust. Having this feature improves the overall quality of the system.
Privacy: This falls under the security and data quality category. This requirement will ensure that customer’s information is protected under the legal requirements and none of the transactions that the customer makes are publicized. The purpose of this is to ensure customer confidentiality as required by law. This also works towards improving the quality of the system and in turn boosts business.
References
Kaner, J, n.d. Teaching domain testing: A status report, Florida Institute of Technology. Web.
Mochal, T., 2001. Integration testing will show you how well your modules get along, Tech Republic. Web.