Bug Report (additional bugs)

                                                                 Additioinal bugs


Login page-

1. "Home" text is displayed unneccessarily
2. Company's name should be "Bebo techical education services" in logo instead of "Bebo techinal educational services".
3. "Welcome to btes" is displayed twice.
4. "Remember me" is not working.
5. Logo of the application should be aligned in center.

Home Page-

1. Username is not displayed throughout the application.

2. "All task" should be written instead of "All Open".

3. Incorrect label "TH tasks" of module.
4. Error 404 is displayed on clicking logout in "mozilla firefox".
5. Check box does not perform any operation.




EDIT MY PROFILE

1. Functionality of update button is not compatible with "Mozilla firefox","IE" and "Google chrome".
2. Error 404  is displayed in "mozilla firefox" on clicking update button.
3. "Save" and "Cancel" buttons are not available.



VIEW USERS-

1. New User link should not be displayed on View user page.
2.  Telephone detail is not displayed on clicking any username.



NEW USERS-

1. Mandatory fields are not marked with (*) sign.
2. The Username is not spelled properly.
3. Name textfield is accepting Numerics.
4. Name text field is accepting less than 2 .
5. Username textfield is accepting Numerics .
6. Username text field is accepting less than 6 .
 7.  Form accepts invalid email and format of email textfield.
  8.  Alphabets and special symbols are also accepatble by Telephone textfield.
9. Telephone textfield is accepting more than 13 and less than 10 digits.
10. New password and Verify password textfields are accepting more than 20 characters.

ADD NEW TASK

1. Same task should not be assigned to same user more than 1 time.
2. User should not assign task to peers.
3. When a task is reassigned to another user, it must be removed from the profile of first user.
4. "Needed by" date should always be after "Start date".
5. Sorting is not performed on "Type","Project" links in "Assigned to" field.
6. Roles and responsibility of every user and subordinate should be defined.
7. Assigned user should not allowed to edit and delete the task.
8. After saving the details, appropriate message is not displayed.
9. "No" option is not avaiable to cease the deleting process.

Manual Testing (Test Cases)

Manual Testing is a process carried out to find the defects. In this method the tester plays an important role as end user and verify all features of the application to ensure that the behaviour of the application. The Manual Testing is very basic type of testing which helps to find the bugs in the application under test. It is preliminary testing, must be carried out prior to start automating the test cases and also needs to check the feasibility of automation testing. The Test Plan is created & followed by the tester to ensure that the comprehensiveness of testing while executing the test cases manually without using automation testing tool.

In the document, Test cases are being executed for the website having URL "http://172.16.0.7:81/btes/ ". There are various modules in the website like Login-Logout, Home, View User,User detail , Edit User, New User creation .

The document have columns Serial no.,Test Case Id, Module, Test summary, Test description, Test data, Test environment, Prerequisite, Steps to follow, Type , Expected Result, Actual result and Status for different browsers.

The document is created on "OpenOffice.org Calc".

Testing Techniques

Testing Techniques

Testing Techniques is  required testing approach to be followed during testing. for eg: if we want to check the functionality of a module , then we go for black box testing.

Boundary value analysis and equivalence partitioning both are test case design strategies in black box testing.

Equivalence Partitioning:

In this method the input domain data is divided into different equivalence data classes. This method is typically used to reduce the total number of test cases to a finite set of testable test cases, still covering maximum requirements.

In short it is the process of taking all possible test cases and placing them into classes. One test value is picked from each class while testing.

E.g.: If you are testing for an input box accepting numbers from 1 to 1000 then there is no use in writing thousand test cases for all 1000 valid input numbers plus other test cases for invalid data.

Using equivalence partitioning method above test cases can be divided into three sets of input data called as classes. Each test case is a representative of respective class.

So in above example we can divide our test cases into three equivalence classes of some valid and invalid inputs.

Test cases for input box accepting numbers between 1 and 1000 using Equivalence Partitioning:

1) One input data class with all valid inputs. Pick a single value from range 1 to 1000 as a valid test case. If you select other values between 1 and 1000 then result is going to be same. So one test case for valid input data should be sufficient.

2) Input data class with all values below lower limit. I.e. any value below 1, as a invalid input data test case.

3) Input data with any value greater than 1000 to represent third invalid input class.

So using equivalence partitioning you have categorized all possible test cases into three classes. Test cases with other values from any class should give you the same result.

We have selected one representative from every input class to design our test cases. Test case values are selected in such a way that largest number of attributes of equivalence class can be exercised.

Equivalence partitioning uses fewest test cases to cover maximum requirements.

Boundary value analysis:

It’s widely recognized that input values at the extreme ends of input domain cause more errors in system. More application errors occur at the boundaries of input domain. ‘Boundary value analysis’ testing technique is used to identify errors at boundaries rather than finding those exist in center of input domain.

Boundary value analysis is a next part of Equivalence partitioning for designing test cases where test cases are selected at the edges of the equivalence classes.

Test cases for input box accepting numbers between 1 and 1000 using Boundary value analysis:

1) Test cases with test data exactly as the input boundaries of input domain i.e. values 1 and 1000 in our case.

2) Test data with values just below the extreme edges of input domains i.e. values 0 and 999.

3) Test data with values just above the extreme edges of input domain i.e. values 2 and 1001.

Boundary value analysis is often called as a part of stress and negative testing.

Note: There is no hard-and-fast rule to test only one value from each equivalence class you created for input domains. You can select multiple valid and invalid values from each equivalence class according to your needs and previous judgments.

E.g. if you divided 1 to 1000 input values in valid data equivalence class, then you can select test case values like: 1, 11, 100, 950 etc. Same case for other test cases having invalid data classes.

This should be a very basic and simple example to understand the Boundary value analysis and Equivalence partitioning concept.

Cause-Effect Graph:

Cause-Effect Graph graphically shows the connection between a given outcome and all issues that manipulate the outcome. Cause Effect Graph is a black box testing technique. It is also known as Ishikawa diagram because of the way it looks, invented by Kaoru Ishikawa or fish bone diagram.

It is generally uses for hardware testing but now adapted to software testing, usually tests external behavior of a system. It is a testing technique that aids in choosing test cases that logically relate Causes (inputs) to Effects (outputs) to produce test cases.

A “Cause” stands for a separate input condition that fetches about an internal change in the system. An “Effect” represents an output condition, a system transformation or a state resulting from a combination of causes.

The Cause-Effect Diagram can be used under these Circumstances:

• To determine the current problem so that right decision can be taken very fast.
• To narrate the connections of the system with the factors affecting a particular process or effect.

• To recognize the probable root causes, the cause for a exact effect, problem, or outcome.

Benefits of making cause-Effect Diagram

• It finds out the areas where data is collected for additional study.
• It motivates team contribution and uses the team data of the process.
• Uses synchronize and easy to read format to diagram cause-and-effect relationships.
• Point out probable reasons of difference in a process.
• It enhances facts of the procedure by helping everyone to learn more about the factors at work and how they relate.
• It assists us to decide the root reasons of a problem or quality using a structured approach.

Steps to proceed on Cause-Effect Diagram:

Firstly: Recognize and describe the input conditions (causes) and actions (effect)

Secondly: Build up a cause-effect graph

Third: Convert cause-effect graph into a decision table

Fourth: Convert decision table rules to test cases. Each column of the decision table represents a test case

Decision table testing: 

A decision table is a good way to deal with different combination inputs with their associated outputs and also called cause-effect table. Reason to call cause-effect table is an associated logical diagramming technique called ’cause-effect graphing that is basically use to derive the decision table.

Decision table testing is black box test design technique to determine the test scenarios for complex business logic.

We can apply Equivalence Partitioning and Boundary Value Analysis techniques to only specific conditions or inputs. Although, if we have dissimilar inputs that result in different actions being taken or secondly we have a business rule to test that there are different combination of inputs which result in different actions. We use decision table to test these kinds of rules or logic.

Advantage of decision table technique:

1. Any complex business flow can be easily converted into the test scenarios & test cases using this technique.
2. Such type of table are work iteratively, means the table created at the first iteration is used as input table for next tables. Such iteration can be carried out only if the initial table is unsatisfactory.
3. Simple to understand and everyone can use this method design the test scenarios & test cases.
4. It provide complete coverage of test cases which help to reduce the rework on writing test scenarios & test cases.
5. These tables guarantee that we consider every possible combination of condition values. This is known as its “completeness property”.

Error guessing

• The Error guessing is a technique where the experienced and good testers are encouraged to think of situations in which the software may not be able to cope. Some people seem to be naturally good at testing and others are good testers because they have a lot of experience either as a tester or working with a particular system and so are able to find out its weaknesses. This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. It also saves a lot of time because of the assumptions and guessing made by the experienced testers to find out the defects which otherwise won’t be able to find.
• The success of error guessing is very much dependent on the skill of the tester, as good testers know where the defects are most likely to be.
• This is why an error guessing approach, used after more formal techniques have been applied to some extent, can be very effective. In using more formal techniques, the tester is likely to gain a better understanding of the system, what it does and how it works. With this better understanding, he or she is likely to be better at guessing ways in which the system may not work properly.
• Typical conditions to try include division by zero, blank (or no) input, empty files and the wrong kind of data (e.g. alphabetic characters where numeric are required). If anyone ever says of a system or the environment in which it is to operate ‘That could never happen’, it might be a good idea to test that condition, as such assumptions about what will and will not happen in the live environment are often the cause of failures.
• A structured approach to the error-guessing technique is to list possible defects or failures and to design tests that attempt to produce them. These defect and failure lists can be built based on the tester’s own experience or that of other people, available defect and failure data, and from common knowledge about why software fails.

Testing Fundamentals

There are different levels during the process of Testing. In this chapter a brief description is provided about these levels.

Levels of testing include the different methodologies that can be used while conducting Software Testing. Following are the main levels of Software Testing:

• Functional Testing.
• Non-Functional Testing. 

Functional Testing

This is a type of black box testing that is based on the specifications of the software that is to be tested. The application is tested by providing input and then the results are examined that need to conform to the functionality it was intended for. Functional Testing of the software is conducted on a complete, integrated system to evaluate the system's compliance with its specified requirements.

There are five steps that are involved when testing an application for functionality.

Steps	Description
I	The determination of the functionality that the intended application is meant to perform.
II	The creation of test data based on the specifications of the application.
III	The output based on the test data and the specifications of the application.
IV	The writing of Test Scenarios and the execution of test cases.
V	The comparison of actual and expected results based on the executed test cases.

An effective testing practice will see the above steps applied to the testing policies of every organization and hence it will make sure that the organization maintains the strictest of standards when it comes to software quality.

Unit Testing

This type of testing is performed by the developers before the setup is handed over to the testing team to formally execute the test cases. Unit testing is performed by the respective developers on the individual units of source code assigned areas. The developers use test data that is separate from the test data of the quality assurance team.

The goal of unit testing is to isolate each part of the program and show that individual parts are correct in terms of requirements and functionality.

LIMITATIONS OF UNIT TESTING

Testing cannot catch each and every bug in an application. It is impossible to evaluate every execution path in every software application. The same is the case with unit testing.

There is a limit to the number of scenarios and test data that the developer can use to verify the source code. So after he has exhausted all options there is no choice but to stop unit testing and merge the code segment with other units.

Integration Testing

The testing of combined parts of an application to determine if they function correctly together is Integration testing. There are two methods of doing Integration Testing Bottom-up Integration testing and Top Down Integration testing.

S.N.	Integration Testing Method
1	Bottom-up integration This testing begins with unit testing, followed by tests of progressively higher-level combinations of units called modules or builds.
2	Top-Down integration  This testing, the highest-level modules are tested first and progressively lower-level modules are tested after that.

In a comprehensive software development environment, bottom-up testing is usually done first, followed by top-down testing. The process concludes with multiple tests of the complete application, preferably in scenarios designed to mimic those it will encounter in customers' computers, systems and network.

System Testing

This is the next level in the testing and tests the system as a whole. Once all the components are integrated, the application as a whole is tested rigorously to see that it meets Quality Standards. This type of testing is performed by a specialized testing team.

System testing is so important because of the following reasons:

• System Testing is the first step in the Software Development Life Cycle, where the application is tested as a whole.
• The application is tested thoroughly to verify that it meets the functional and technical specifications.
• The application is tested in an environment which is very close to the production environment where the application will be deployed.
• System Testing enables us to test, verify and validate both the business requirements as well as the Applications Architecture.

Regression Testing

Whenever a change in a software application is made it is quite possible that other areas within the application have been affected by this change. To verify that a fixed bug hasn't resulted in another functionality or business rule violation is Regression testing. The intent of Regression testing is to ensure that a change, such as a bug fix did not result in another fault being uncovered in the application.

Regression testing is so important because of the following reasons:

• Minimize the gaps in testing when an application with changes made has to be tested.
• Testing the new changes to verify that the change made did not affect any other area of the application.
• Mitigates Risks when regression testing is performed on the application.
• Test coverage is increased without compromising timelines.
• Increase speed to market the product.

Acceptance Testing

This is arguably the most importance type of testing as it is conducted by the Quality Assurance Team who will gauge whether the application meets the intended specifications and satisfies the client.s requirements. The QA team will have a set of pre written scenarios and Test Cases that will be used to test the application.

More ideas will be shared about the application and more tests can be performed on it to gauge its accuracy and the reasons why the project was initiated. Acceptance tests are not only intended to point out simple spelling mistakes, cosmetic errors or Interface gaps, but also to point out any bugs in the application that will result in system crashers or major errors in the application.

By performing acceptance tests on an application the testing team will deduce how the application will perform in production. There are also legal and contractual requirements for acceptance of the system.

ALPHA TESTING

This test is the first stage of testing and will be performed amongst the teams (developer and QA teams). Unit testing, integration testing and system testing when combined are known as alpha testing. During this phase, the following will be tested in the application:

• Spelling Mistakes
• Broken Links
• Cloudy Directions
• The Application will be tested on machines with the lowest specification to test loading times and any latency problems.

BETA TESTING

This test is performed after Alpha testing has been successfully performed. In beta testing a sample of the intended audience tests the application. Beta testing is also known as pre-release testing. Beta test versions of software are ideally distributed to a wide audience on the Web, partly to give the program a "real-world" test and partly to provide a preview of the next release. In this phase the audience will be testing the following:

• Users will install, run the application and send their feedback to the project team.
• Typographical errors, confusing application flow, and even crashes.
• Getting the feedback, the project team can fix the problems before releasing the software to the actual users.
• The more issues you fix that solve real user problems, the higher the quality of your application will be.
• Having a higher-quality application when you release to the general public will increase customer satisfaction.

Non-Functional Testing

This section is based upon the testing of the application from its non-functional attributes. Non-functional testing of Software involves testing the Software from the requirements which are non functional in nature related but important a well such as performance, security, user interface etc.

Some of the important and commonly used non-functional testing types are mentioned as follows:

Performance Testing

It is mostly used to identify any bottlenecks or performance issues rather than finding the bugs in software. There are different causes which contribute in lowering the performance of software:

• Network delay.
• Client side processing.
• Database transaction processing.
• Load balancing between servers.
• Data rendering.

Performance testing is considered as one of the important and mandatory testing type in terms of following aspects:

• Speed (i.e. Response Time, data rendering and accessing)
• Capacity
• Stability
• Scalability

It can be either qualitative or quantitative testing activity and can be divided into different sub types such as Load testing and Stress testing.

LOAD TESTING

A process of testing the behavior of the Software by applying maximum load in terms of Software accessing and manipulating large input data. It can be done at both normal and peak load conditions. This type of testing identifies the maximum capacity of Software and its behavior at peak time.

Most of the time, Load testing is performed with the help of automated tools such as Load Runner, AppLoader, IBM Rational Performance Tester, Apache JMeter, Silk Performer, Visual Studio Load Test etc.

Virtual users (VUsers) are defined in the automated testing tool and the script is executed to verify the Load testing for the Software. The quantity of users can be increased or decreased concurrently or incrementally based upon the requirements.

STRESS TESTING

This testing type includes the testing of Software behavior under abnormal conditions. Taking away the resources, applying load beyond the actual load limit is Stress testing.

The main intent is to test the Software by applying the load to the system and taking over the resources used by the Software to identify the breaking point. This testing can be performed by testing different scenarios such as:

• Shutdown or restart of Network ports randomly.
• Turning the database on or off.
• Running different processes that consume resources such as CPU, Memory, server etc.

Usability Testing

This section includes different concepts and definitions of Usability testing from Software point of view. It is a black box technique and is used to identify any error(s) and improvements in the Software by observing the users through their usage and operation.

According to Nielsen, Usability can be defined in terms of five factors i.e. Efficiency of use, Learn-ability, Memor-ability, Errors/safety, satisfaction. According to him the usability of the product will be good and the system is usable if it possesses the above factors.

Nigel Bevan and Macleod considered that Usability is the quality requirement which can be measured as the outcome of interactions with a computer system. This requirement can be fulfilled and the end user will be satisfied if the intended goals are achieved effectively with the use of proper resources.

Molich in 2000 stated that user friendly system should fulfill the following five goals i.e. Easy to Learn, Easy to Remember, Efficient to Use, Satisfactory to Use and Easy to Understand.

In addition to different definitions of usability, there are some standards and quality models and methods which define the usability in the form of attributes and sub attributes such as ISO-9126, ISO-9241-11, ISO-13407 and IEEE std.610.12 etc.

UI VS USABILITY TESTING

UI testing involves the testing of Graphical User Interface of the Software. This testing ensures that the GUI should be according to requirements in terms of color, alignment, size and other properties.

On the other hand Usability testing ensures that a good and user friendly GUI is designed and is easy to use for the end user. UI testing can be considered as a sub part of Usability testing.

Security Testing

Security testing involves the testing of Software in order to identify any flaws ad gaps from security and vulnerability point of view. Following are the main aspects which Security testing should ensure:

• Confidentiality.
• Integrity.
• Authentication.
• Availability.
• Authorization.
• Non-repudiation.
• Software is secure against known and unknown vulnerabilities.
• Software data is secure.
• Software is according to all security regulations.
• Input checking and validation.
• SQL insertion attacks.
• Injection flaws.
• Session management issues.
• Cross-site scripting attacks.
• Buffer overflows vulnerabilities.
• Directory traversal attacks.

Portability Testing

Portability testing includes the testing of Software with intend that it should be re-useable and can be moved from another Software as well. Following are the strategies that can be used for Portability testing.

• Transferred installed Software from one computer to another.
• Building executable (.exe) to run the Software on different platforms.

Portability testing can be considered as one of the sub parts of System testing, as this testing type includes the overall testing of Software with respect to its usage over different environments. Computer Hardware, Operating Systems and Browsers are the major focus of Portability testing. Following are some pre-conditions for Portability testing:

• Software should be designed and coded, keeping in mind Portability Requirements.
• Unit testing has been performed on the associated components.
• Integration testing has been performed.
• Test environment has been established.

Software Development Life Cycle Models(2)

Software Development Life Cycle Models

Evolutionary Prototyping Model

Description

It refers to the activity of creating prototypes of software applications, for example, incomplete versions of the software program being developed. It is an activity that can occur in software development. It used to visualize some component of the software to limit the gap of misunderstanding the customer requirements by the development team. This also will reduce the iterations may occur in waterfall approach and hard to be implemented due to inflexibility of the waterfall approach. So, when the final prototype is developed, the requirement is considered to be frozen.

It has some types, such as:

· Throwaway prototyping: Prototypes that are eventually discarded rather than becoming a part of the finally delivered software

· Evolutionary prototyping: prototypes that evolve into the final system through iterative incorporation of user feedback.

· Incremental prototyping: The final product is built as separate prototypes. At the end the separate prototypes are merged in an overall design.

· Extreme prototyping: used at web applications mainly. Basically, it breaks down web development into three phases, each one based on the preceding one. The first phase is a static prototype that consists mainly of HTML pages. In the second phase, the screens are programmed and fully functional using a simulated services layer. In the third phase the services are implemented

The usage

· This process can be used with any software developing life cycle model. While this shall be focused with systems needs more user interactions. So, the system do not have user interactions, such as, system does some calculations shall not have prototypes.

Advantages	Disadvantages
· Reduced time and costs, but this can be disadvantage if the developer lose time in developing the prototypes                                                           · Improved and increased user involvement	· Insufficient analysis                                                  · User confusion of prototype and finished system      · Developer misunderstanding of user objectives        · Excessive development time of the prototype           · Expense of implementing prototyping

Spiral Method (SDM)

Description

It is combining elements of both design and prototyping-in-stages, in an effort to combine advantages of top-down and bottom-up concepts. This model of development combines the features of the prototyping model and the waterfall model. The spiral model is favored for large, expensive, and complicated projects. This model uses many of the same phases as the waterfall model, in essentially the same order, separated by planning, risk assessment, and the building of prototypes and simulations.

 

The usage

It is used in shrink-wrap application and large system which built-in small phases or segments.

Advantages and Disadvantages

Advantages	Disadvantages
· Estimates (i.e. budget, schedule, etc.) become more realistic as work progresses, because important issues are discovered earlier                                     .· Early involvement of developers                             · Manages risks and develops system into phases	· High cost and time to reach the final product.           · Needs special skills to evaluate the risks and assumptions                                                              · Highly customized limiting re-usability

Software Development Life Cycle Models

Software Development Life Cycle Models

Waterfall Model

Description

The waterfall Model is a linear sequential flow. In which progress is seen as flowing steadily downwards (like a waterfall) through the phases of software implementation. This means that any phase in the development process begins only if the previous phase is complete. The waterfall approach does not define the process to go back to the previous phase to handle changes in requirement. The waterfall approach is the earliest approach that was used for software development.

Advantages

Disadvantages

· Easy to explain to the user                                       · Structures approach.                                               · Stages and activities are well defined                        · Helps to plan and schedule the project                     · Verification at each stage ensures early detection of errors / misunderstanding                                            · Each phase has specific deliverables

· Assumes that the requirements of a system can be frozen                                                                       · Very difficult to go back to any stage after it              finished                                                                     .· Little flexibility and adjusting scope is difficult and expensive                                                                 .· Costly and required more time, in addition to detailed plan

 

V-Shaped Model

Description

It is an extension for waterfall model, Instead of moving down in a linear way, the process steps are bent upwards after the coding phase, to form the typical V shape. The major difference between v-shaped model and waterfall model is the early test planning in v-shaped model.

The usage

· Software requirements clearly defined and known
· Software development technologies and tools is well-known

Advantages

Disadvantages

· Simple and easy to use.                                            · Each phase has specific deliverables                         .· Higher chance of success over the waterfall model due to the development of test plans early on during the life cycle.                                                                        · Works well for where requirements are easily understood.

· Very inflexible, like the waterfall model.                    · Little flexibility and adjusting scope is difficult and expensive.                                                                 · Software is developed during the implementation phase, so no early prototypes of the software are produced.                                                                 · Model doesn’t provide a clear path for problems found during testing phases.                                       · Costly and required more time, in addition to detailed plan

Software Testing Life Cycle

Software Testing Life Cycle

Software Testing Life Cycle (STLC) defines the steps/stages/phases in testing of software.

Requirement Analysis:

Requirement Analysis is the very first step in Software Testing Life Cycle (STLC). In this step Quality Assurance (QA) team understands the requirement in terms of what we will testing & figure out the testable requirements. If any conflict, missing or not understood any requirement, then QA team follow up with the various stakeholders like Business Analyst, System Architecture, Client, Technical Manager/Lead etc to better understand the detail knowledge of requirement.
From very first step QA involved in the where STLC which helps to prevent the introducing defects into Software under test. The requirements can be either Functional or Non-Functional like Performance, Security testing.

Test Planning:

Test Planning is most important phase of Software testing life cycle where all testing strategy is defined. This phase also called as Test Strategy phase. In this phase typically Test Manager (or Test Lead based on company to company) involved to determine the effort and cost estimates for entire project. This phase will be kicked off once the requirement gathering phase is completed & based on the requirement analysis, start preparing the Test Plan. The Result of Test Planning phase will be Test Plan or Test strategy & Testing Effort estimation documents. Once test planning phase is completed the QA team can start with test cases development activity.

Test Case Development:

The test case development activity is started once the test planning activity is finished. This is the phase of STLC where testing team write down the detailed test cases. Along with test cases testing team also prepare the test data if any required for testing. Once the test cases are ready then these test cases are reviewed by peer members or QA lead.
Also the Requirement Traceability Matrix (RTM) is prepared. The Requirement Traceability Matrix is an industry-accepted format for tracking requirements where each test case is mapped with the requirement. Using this RTM we can track backward & forward traceability.

Test Environment Setup:

Setting up the test environment is vital part of the STLC. Basically test environment decides on which conditions software is tested. This is independent activity and can be started parallel with Test Case Development. In process of setting up testing environment test team is not involved in it. Based on company to company may be developer or customer creates the testing environment. Mean while testing team should prepare the smoke test cases to check the readiness of the test environment setup.

Test Execution:

Once the preparation of Test Case Development and Test Environment setup is completed then test execution phase can be kicked off. In this phase testing team start executing test cases based on prepared test planning & prepared test cases in the prior step.
Once the test case is passed then same can be marked as Passed. If any test case is failed then corresponding defect can be reported to developer team via bug tracking system & bug can be linked for corresponding test case for further analysis. Ideally every failed test case should be associated with at least single bug. Using this linking we can get the failed test case with bug associated with it. Once the bug fixed by development team then same test case can be executed based on your test planning.
If any of the test cases are blocked due to any defect then such test cases can be marked as Blocked, so we can get the report based on how many test cases passed, failed, blocked or not run etc. Once the defects are fixed, same Failed or Blocked test cases can be executed again to retest the functionality.

Test Cycle Closure:

Call out the testing team member meeting & evaluate cycle completion criteria based on Test coverage, Quality, Cost, Time, Critical Business Objectives, and Software. Discuss what all went good, which area needs to be improve & taking the lessons from current STLC as input to upcoming test cycles, which will help to improve bottleneck in the STLC process. Test case & bug report will analyze to find out the defect distribution by type and severity. Once complete the test cycle then test closure report & Test metrics will be prepared. Test result analysis to find out the defect distribution by type and severity.