Q- Can functional testing be replaced or significantly reduced by integration testing? For example, by using a CI server?

A- Web Application that requires a login - Login page that requires an account name and password.

Unit test checks

• Field length of User & Password fields
• Enable and Disable Login button
• Password Character & Strongest

Integration test checks

• User views message after entering invalid details
• User views a home page after entering valid values and pressing the login button.

Here are a few more tests:

• Correct information stored in cookie as per previously visited on same PC
• How does having a cookie affect or not affect the login and home pages?
• Can a user that has been inactivated log in?
• Reset password functionality available if a user forgets their password
• Error message appears during entering invalid & no value in the field

Web Page is cached in browser during lost Internet connection and messaging appears on an attempt to login with connection.

Six Functional Tests to ensure Software Quality

Six types of functional testing can be used to ensure the quality of the end product. Understand these testing types and scale the execution to match the risk to the project.

1.                  Ensure every line of code executes properly with Unit Testing.

·        Unit testing is the process of testing each unit of code in a single component.

• Testing is carried out by the Developer as the component is being developed.

·        Unit tests are normally discussed in terms of the type of coverage they provide:

o        Function coverage: Each function/method executed by at least one test case.

• Statement coverage: Each line of code covered by at least one test case (need more test cases than above).
• Path coverage: Every possible path through code covered by at least one test case (need plenty of test cases).

2.                  Ensure every function produces its expected outcome with Functional Testing.
Functional testing as black box testing addresses concerns surrounding the correct implementation of functional requirements, this type of testing requires no knowledge of the underlying implementation.

·        Functional test suites are created from requirement use cases, with each scenario

·        Prioritize critical and widely used functions and include other functions as time and resources permit.

·        Develop use cases correctly to support functional testing

3.                  Ensure all functions combine to deliver the desired business result with System Testing.

·        System testing executes end-to-end functional tests that cross software units, helping to realize the goal of ensuring that components combine to deliver the desired business result.

·        In defining the project's system testing goals, focus on those scenarios that require critical units to integrate.

·         Components should be integrated incrementally after each has been tested in isolation.

4. Ensure new changes did not adversely affect other parts of the system with Regression Testing.
   
   

·        Regression testing ensures code modifications have not inadvertently introduced bugs into the system or changed existing functionality.

·        Goals for regression testing should include plans from the original unit, as well as functional and system tests phases to demonstrate that existing functionality behaves as intended.

5. Ensure the system integrates with and does not adversely affect other enterprise systems with System Integration Testing.
   
   

·        System integration testing is a process that assesses the software's interoperability and cooperation with other applications.

·        Define testing goals that will exercise required communication.

6. Ensure the customer is satisfied with the system with Acceptance Testing.
   
   

·        Acceptance testing aims to test how well users interact with the system, that it does what they expect and is easy to use. Although it is the final phase of testing before software deployment, the tests themselves should be defined as early as possible in the SDLC.

·        To that end, acceptance test cases are developed from user requirements and are validated in conjunction with actual end users of the system. The process results in acceptance or rejection of the final product.

How to design and test for usability

 A series of roundtables on the subject of usability. The first roundtable took a

• High level view of the area
• Investigated the importance of usability
• What barriers there are to it being implemented
• How it can be imbedded into the development process

The second meeting assumed that the

• Importance was understood
• The barriers had been removed
• Concentrated on the question "How to design and test for usability?"

The roundtable was made up of

• Representatives of academia
• Large enterprise
• Web development
• Internet psychology
• Journalism
• Usability testing

These conclusions came out of the discussion of four questions:

• How to collect usability requirements?
• How to design for usability?
• What usability testing is needed?
• How to run usability testing?

Requirements Gathering

At the highest level the System Usability Scale defines general usability requirements, a system must be:

• Effective (the user can successfully achieve their objectives).
• Efficient (with the least amount of time and effort).
• Satisfactory (the user must be satisfied, and delighted, by the experience).

Design

The detailed design of the system must ensure that the user can easily do what they need to. The design can be divided into: navigation, process and look and feel.

Navigation

To help design the system the developer should:

• Try different menu structures.
• Check user understanding of terminology.
• Provide alternative navigation techniques and potentially provide multiple routes to the same place.
• Be consistent across the system and use standard best practice

Process

It is worth trying different designs for the processes looking at form layout, amount of information processed in each step, the order of the steps, and processing of errors.

Look and feel

For a user to be satisfied it is not sufficient for the system to be ease and quick to use it has also got to look and feel good. Creative media designers can help to ensure that the system looks right and reflects the user's image of themselves as well as the branding of the supplier.

Testing

Usability and accessibility testing should be done as part of the overall testing of the system. The usability of certain areas of the system will be more critical than others, and the scenarios designed to assess the usability of the system should concentrate on these areas. The important areas are not just those that are used a lot but also areas where it is important that the user has a satisfactory experience; for example when an error is highlighted it is particularly important that the user can fix it easily as if they cannot they are likely to drop out and go to some other system.

Conclusion

The design, development and testing of systems are all interconnected and affect one another. Usability has to be an integral part of the development process.

Q-What is the difference between quality assurance testing and user acceptance testing?

QA (Quality Assurance Testing)

• Technology Oriented Tester
• Functional Component
• Integrated features
• Requirements specification
• Design Specification
• Interface level entry points
• Analysis testing tools
• UI end to end features
• Prior to UAT

UAT (user acceptance testing)

• Business Oriented Testers
• Business Scenarios
• Real World business needs
• UI end to end features
• Final and Integrated
• Prior to signoff/prod deployment

Q- I am a test engineer working on Windows applications. I do manual testing. In the agile world, when things keep on changing every now and then, it's difficult to get well-defined requirement specifications from developers, which disturb test case writing, traceability, and test execution. What would be the right strategy to make sure we are delivering quality product?

If you have dynamic requirements to test software then do follow the below steps:

• Make it your plan as per list of goals
• No need to keep actual steps in you plan
• No need to write every requirement in your planed document
• Write requirement to help keep everything straight
• Summarize a group of requirements with a simple sentence
• Plan should not be documented as huge
• If the requirement changed during executing test then change it into your document
• If original requirement changed during executing test then stop testing and make new document
• Ensure that application or module is stable then update the main document (test case & traceability) and execute updated test cases and finally the sign off the document

The impact of changing requirements is greatly reduced by using this method