1.

Types of testing

The different types of tests

1. Unit tests

Unit tests are very low level and close to the source of an application. They consist in
testing individual methods and functions of the classes, components, or modules
used by your software. Unit tests are generally quite cheap to automate and can run
very quickly by a continuous integration server.

2. Integration tests

Integration tests verify that different modules or services used by your application
work well together. For example, it can be testing the interaction with the
database or making sure that microservices work together as expected. These types
of tests are more expensive to run as they require multiple parts of the application to
be up and running.

3. Functional tests

Functional tests focus on the business requirements of an application. They only

verify the output of an action and do not check the intermediate states of the system
when performing that action.

There is sometimes a confusion between integration tests and functional tests as

they both require multiple components to interact with each other. The difference is
that an integration test may simply verify that you can query the database while a
functional test would expect to get a specific value from the database as defined by
the product requirements.

4. End-to-end tests

End-to-end testing replicates a user behavior with the software in a complete

application environment. It verifies that various user flows work as expected and can
be as simple as loading a web page or logging in or much more complex scenarios
verifying email notifications, online payments, etc...
End-to-end tests are very useful, but they're expensive to perform and can be hard to
maintain when they're automated. It is recommended to have a few key end-to-end
tests and rely more on lower level types of testing (unit and integration tests) to be
able to quickly identify breaking changes.

5. Acceptance testing

Acceptance tests are formal tests that verify if a system satisfies business
requirements. They require the entire application to be running while testing and
focus on replicating user behaviors. But they can also go further and measure the
performance of the system and reject changes if certain goals are not met.

6. Performance testing

Performance tests evaluate how a system performs under a particular

workload. These tests help to measure the reliability, speed, scalability, and
responsiveness of an application. For instance, a performance test can observe
response times when executing a high number of requests, or determine how a
system behaves with a significant amount of data. It can determine if an application
meets performance requirements, locate bottlenecks, measure stability during peak
traffic, and more.

7. Smoke testing

Smoke tests are basic tests that check the basic functionality of an application. They
are meant to be quick to execute, and their goal is to give you the assurance that the
major features of your system are working as expected.

Smoke tests can be useful right after a new build is made to decide whether or not
you can run more expensive tests, or right after a deployment to make sure that they
application is running properly in the newly deployed environment.

Challenges in Software Testing

• Unstable Test Environment. ...
• Tight Deadlines. ...
• Wrong Testing Estimation. ...
• Last-Minute Changes to Requirements. ...
• You may Test the wrong things. ...
• Lack of Communication. ...
 • Testing the Complete Application. ...
• Lack of Skilled Testers.
2.Identfying and designing class diagrams

https://creately.com/blog/diagrams/class-diagram-tutorial/

3.Design UML diagrams using corollaries

https://www.vidyarthiplus.com/vp/attachment.php?aid=45205

5.GUI/View layer interface

View layer objects are more responsible for user interaction and these view layer
objects have more relation with the user where business layer objects have less
interaction with users.
Another feature of view layer objects are they deal less with the logic. They help the
users to complete their task in an easy manner.
The Major responsibilities of view layer objects are
1. Input – View Layer objects have to respond for user interaction. The
user interface is designed to translate an action by the user (Eg. Clicking the button)
in to a corresponding message.
2. Output - Displaying or printing information after processing.
View Layer Design Process:
1. Macro Level UI Design Process
a. Identify classes that interact with human actors
b. A sequence/ collaboration diagram can be used to represent a clear picture of
actor system interaction.
Name = getName()
c. For every class identified determine if the class interacts with the human actor. If so
i. Identify the view layer object for that class.
ii. Define the relationship among view layer objects.
2. Micro Level UI Design Process
a. Design of view layer objects by applying Design Axioms and Corollaries.
b. Create prototype of the view layer interface.
3. Testing the usability and user satisfaction testing.
4. Iterate and refine the above steps.
[Note: Explain the above process for an essay]
User Interface Design Rules:
UI Design Rule 1: Making the interface simple
For complex application if the user interface is simple it is easy for the users to learn
new applications. Each User Interface class should have a well define single purpose.
If a user cannot sit before a screen and find out what to do next without asking
multiple questions, then it says your interface is not simple.
UI Design Rule 2: Making the Interface Transparent and Natural.
The user interface should be natural that users can anticipate what to do next by
applying previous knowledge of doing things with out a computer. This rule says
there should be a strong mapping and users view of doing things.
UI Design Rule 3: Allowing users to be in control of the Software.
The UI should make the users feel they are in control of the software and not the
software controls the user. The user should play an active role and not a reactive role
in the sense user should initiate the action and not the software.
Some ways to make put users in control are 1. Make the interface forgiving.
2. Make the interface visual.
3. Provide immediate feedback.
4. Avoid Modes.
5. Make the interface consistent.
Purpose of View Layer Interface – Guideline

6.Alpha & Beta testing

Alpha Testing Beta Testing

It is done by internal testers of the

It is done by real users.
organization.

It is an internal test, performed within the It is an external test, carried out in the
organization. user's environment.
 Alpha Testing uses both black box and Beta Testing only uses the black box
white box testing techniques testing technique.

Identifies possible errors. Checks the quality of the product.

Developers start fixing bugs as soon as Errors are found by users and feedback
they are identified. is necessary.

Long execution cycles. It only takes a few weeks.

It can be easily implemented as it is done It will be implemented in the future

before the near end of development. version of the product.

It is the final test before launching the

It is performed before Beta Testing.
product on the market.

It answers the question: Does the product It answers the question: Do customers
work? like the product?

Usability, functionality, security and

Functionality and usability are tested.
reliability are tested with the same depth.

7.steps involved in creating user interface

https://www.geeksforgeeks.org/software-engineering-user-interface-design/
8. Documentation in ooad

https://www.techtarget.com/searchsoftwarequality/definition/documentation

10.Black box and White box testing

S.
No. Black Box Testing White Box Testing

It is a way of software testing in It is a way of testing the software in

which the internal structure or the which the tester has knowledge about
program or the code is hidden and the internal structure or the code or
1. nothing is known about it. the program of the software.

Implementation of code is not needed Code implementation is necessary for

2. for black box testing. white box testing.

It is mostly done by software

3. It is mostly done by software testers. developers.

No knowledge of implementation is Knowledge of implementation is

4. needed. required.

It can be referred to as outer or It is the inner or the internal software

5. external software testing. testing.

6. It is a functional test of the software. It is a structural test of the software.

This testing can be initiated based on

the requirement specifications This type of testing of software is
7. document. started after a detail design document.

No knowledge of programming is It is mandatory to have knowledge of

8. required. programming.

It is the behavior testing of the

9. software. It is the logic testing of the software.

It is applicable to the higher levels of It is generally applicable to the lower

10. testing of software. levels of software testing.
 S.
No. Black Box Testing White Box Testing

11. It is also called closed testing. It is also called as clear box testing.

12. It is least time consuming. It is most time consuming.

It is not suitable or preferred for

13. algorithm testing. It is suitable for algorithm testing.

Data domains along with inner or

Can be done by trial and error ways internal boundaries can be better
14. and methods. tested.

Example: Search something on Example: By input to check and

15. google by using keywords verify loops

Black-box test design techniques-

• Decision table testing White-box test design techniques-
• All-pairs testing • Control flow testing
• Equivalence partitioning • Data flow testing
16. • Error guessing • Branch testing

Types of Black Box Testing: Types of White Box Testing:

• Functional Testing • Path Testing
• Non-functional testing • Loop Testing
17. • Regression Testing • Condition testing

It is less exhaustive as compared to It is comparatively more exhaustive

18. white box testing. than black box testing.

12

.CRChttp://pages.cpsc.ucalgary.ca/~eberly/Courses/CPSC333/Lectures/Design/CRC_modeling.html