Software Testing – Test Analysis

Software testing is a process, of testing software performance to determine whether an improved software meets the stated requirements or not and to identify errors to ensure that a product is flawless to produce a high-quality product.

Test Analysis

In software testing, test analysis is the process of testing and analyzing test art materials to create test scenarios or test cases. The goal of exam analysis is to gather requirements and create objectives for assessment in order to establish assessment conditions. As a result, it is also known as the Testing Foundation. Test evaluation is the process of evaluating the basis of evaluation (all papers from which part or system requirements can be found) and defining the objectives of the assessment. Specifies WHAT should be tested in the context of test conditions and may begin immediately after the test base for each test level has been set.

Factors Determining Levels of Details of Test Conditions:

1. Test level, the level of detail, and the quality of the test base.
2. System/software complexity and life cycle of development used.
3. Risks associated with projects and products.
4. The relationship between the basics of testing, what should be tested, and how it should be tested.
5. A test management tool.
6. Maturity of the evaluation process, as well as the skills and knowledge of analysts.
7. The level of specificity of the Test Design and other implications of the test task.
8. Customers’ willingness to participate in the consultation.

The following are the various sources for gathering test information:

1. Software Requirements: The software requirements specification (SRS document) sets out how the software system should be built. In a nutshell, SRS provides a project path for everyone involved. Provides advanced descriptions of active and inactive software specifications, as well as operating conditions that indicate how the user can interact with the system once completed. The following are common features of SRS:

• What is the purpose of the software being built?
• All software reviews.
• Software performance, or what it is designed to do.
• Software performance in the production environment.
• Valid & Invalid details.
• External visual connectors, or how the software will interact with hardware or other software.
• Restrictions on the design of the software or those set in the operating environment.

2. Business Requirements: Displays high-performance software details. This is an official document that describes the needs of the client (written, oral). It is usually produced by a Business Analyst who works with clients and is based on the interaction and needs of clients. Business Process is a detailed description of how our trading partners aim to fulfill their roles, build business relationships, and share tasks in order to participate effectively with the help of their information systems.

3. Functional Design Document: Functional Design Specification, or FDS, is a document that describes how a process or control system will work. It explains how the planned system will work, how people will interact with it, and what can be expected from a variety of operating conditions. Specific design specification helps for a variety of reasons. One of the main reasons is that it takes a lot of time to produce drawings or write a PLC code without some kind of written agreement on what the system should accomplish. Functional Design specifications can be shared with relevant team members, buyers, and stakeholders for feedback and review until the final document is agreed upon and signed. This review process and changes are important in ensuring that the final design is objective and meets the needs of the participants. Thereafter, the document is provided to the teams of engineers for technical design and programs, with operational details that serve as a guide. Engineers will know what to draw, Developers will know what the code should do, and Customers will know what to bring when the Functional Design Specification is done. The specific design specification identifies what should be used in the life cycle of industrial software engineering.

4. Operating Requirements: Performance requirements are important to your product because, as they say, they provide a few types of functionality. Asking yourself the question “does this load on the performance of my tool?” Or “What is the significance of this?” can help with this program. Within Medical Specialty Gadgets, those purposeful needs may have a lower set of risks and requirements. You can also have requirements that explain how your software system will interact with different tools, which brings us to the needs of external interactions.

5. External Relationship Requirements: External interaction requirements are the most accurate variety of purposeful needs. These are especially important when working with embedded systems. They describe how your product will interact with different components.

Consider a simple e-Commerce Website development.

Fig 1.1 Flow Diagram of the flow of a website for a store

The Website should have a Login Page and the Login must be successful only if the correct credentials are entered. On the Home Page, All Offer Details and Quick Links to other pages should be provided. Test it to make sure, it is entering the proper page. Make sure the Search works based on the value entered and valid contents are displayed. Also, make sure while ordering, the corresponding payment is proper. Let’s look in detail.

1. Home Page Testing:

• Will it scroll automatically?
• If so, at what point will the image be updated?
• If the user navigates through it, will it still scroll to the next one?
• Can it be moved at the top?
• Can it be clicked on?
• If so, does it lead to the right page and the right agreement?
• Does it load along with the rest of the page or does it load at the end compared to other features on the page?
• Can all content be viewed?
• Does it provide the same content for different browsers and different screen resolutions?

2. Search Algorithm Test:

• Search based on the Product name, brand name, or more specifically, category. Example Camera, Canon EOS 700D, electronics, etc.
• Search results should be consistent
• Different types of options should be available – based on Product, Price, Reviews/ratings, etc.
• How many results will be displayed per page?
• With multi-page results, there are navigation options.
• Also, searches take place in many places. Please consider declining the search to multiple levels when verifying this functionality.

3. Product Details Page:

• Photo or product images.
• Product price.
• Product details.
• Updates.
• Check out the options.
• Delivery options.
• Shipping information.
• Available / Expires in stock.
• Multiple colors or contrast options.

4. Payment Test:

• Check out the different payment options.
• If you agree to go out as a guest, just complete the purchase and offer the registration option at the end.
• Return customers – Sign in to check.
• Register a user.
• If you keep a customer’s credit card or any other financial information, perform a security check to make sure it is secure (Compliance PCI must).
• If the user has been registered for a long time, make sure the session has expired or not. Each site has a different limit. For others, 10 minutes. For others, it may be different.
• Emails / Verification text with the order number generated.

5. Shopping Cart Test:

• Add items to the cart and continue shopping.
• If the user adds the same item to the cart while continuing to purchase, the number of items in the cart should increase.
• All items and their totals must be displayed in the cart.
• Local taxes should be used.
• The user can add more items to the cart value should display the same.
• Update content added to the cart value should reflect that as well.
• Remove items from the cart.
• Proceed to checkout.
• Calculate shipping costs with different shipping options.
• Enter coupons.
• Do not check, close the site, and come back later. The site should keep cart items.

6) After Order Test

Check out:

• Change Order.
• Cancel order.
• Track order.
• It’s coming back.

Test Analysis for the Website:

• Checking Compatibility of Various Browsers.
• Page display Errors / Delay in download.
• Session Expiry and Autosave data.
• Ease of Access.
• 24 * 7 Available.
• No offensive content.
• Backup and recovery.
• Secured Transactions.
• Performance.

Performance Testing = Highly Important in E-commerce

Sometimes there are delays of about 250 milliseconds of page load time, which is what keeps your customer competing. Walmart, a major retailer, is adjusting its site speed and has seen a 2% increase in visitor conversion rates and 1% revenue.

The performance of your site depends on these factors:

1. Throughput:

• Ask in a second.
• Activity per minute.
• Perform with each click.

2. Response time:

• Duration of work.
• Seconds per click.
• Page Upload.
• DNS check.
• The duration between clicks and page view.

Review the basics of testing: This is the first and foremost step towards achieving the same goal. Each specification is put in place for the team to receive advice on functions, features, UI, etc. providing a good understanding of system structure.

Identify test scenarios: After team analysis, the next task is to create scenarios that validate the performance and features of the system. For example, a user should be able to cancel an order he or she has placed on an order cancellation order.

Designing test scenarios: After identifying the various scenarios that need to be verified, there is a need to create experimental scenarios by preparing experimental data. Test data includes creating input and output values ​​on the basis of understanding the application. One can refer to the end-user data usage pattern. An example of a test status would be user login -> apply filter by category-> add the product to cart. The actual test data is corrected at this stage.

Expected and unexpected inputs: Now the results have been compared to determine if there are any expected and actual deviations. The cause of the deviation is considered and noted for the same correction.