Extent Reports Log Generation in C#

Extent Reports Log Generation will discuss about how to generate log steps in the Extent Reports. While running the test suite user want to log some information about the execution in the report. This information will help the user to understand the test step execution flow and any failures during the test suite execution.
By using Extent Reports we can generate logs in the HTML report. For this we need use the Log() method of the ExtentTest Class. By using this method not only log the step information, we can provide the Pass, Fail and Skip information of the particular test case. To log the information we need to use the LogStatus.Info as first parameter in the Log() method. And we need to use LogStatus.Pass for the passed test case and LogStatus.Fail for the failed test cases.
Below is the methods related for generating step logs in the report:
using RelevantCodes.ExtentReports;
public static ExtentTest test
public static ExtentReports extent;
 test = extent.StartTest("Test Case Name");
test.Log(LogStatus.Pass, "Test Case Name is Passed"); 
test.Log(LogStatus.Fail, "Test Case Name is Failed");
extent.EndTest(test);    
extent.Flush();

 Finally, you may get a test report like following (The sample is the last case at left-bottom):





How to call keys in selenium C # if there is already a project named 'Keys'?

Today I encountered a problem when I was trying to call the method SendKeys(Keys.ArrowDown) in selenium C#

I defined an IWebElement object named 'searchAddress', I was trying to use this object to call ArrowDown key and then Enter key, so I wrote two lines of code:

searchAddress.SendKeys(Keys.ArrowDown);
searchAddress.SendKeys(Keys.Enter);

Because the namespace is 'Keys', I was reminded that ArrowDown doesn't exist in the namespace 'Keys'/Enter doesn't exist in the namespace 'Keys'.

Later, I change the codes as following:

 searchAddress.SendKeys(OpenQA.Selenium.Keys.ArrowDown);
 searchAddress.SendKeys(OpenQA.Selenium.Keys.Enter);

They worked!

D5 of 30 Days' ISTQB: Test Conditions, Test Cases, and Test Procedures

Let's look at dynamic testing, where the software we are interested in is run by executing tests on the running code.

Before we actually execute a test, we need to know what I are trying to test, the inputs, the results that should be produced by those input, how we get ready for and run the tests. In this section, we are looking at three things: Test Conditions, Test Cases, and Test Procedures.

Test Conditions are documented in a Test Design Specification. Test Cases are documented in a Test Case Specification. Test Procedures are documented in a Test Procedure Specification. Testing may be performed with varying degrees of formality. Very formal testing would have extensive documents under well control, exact and specific input and expected outcome of the test. Very informal testing may have no document at all, or only some notes kept by the individual testers, but we still expect that they have in their mind or notes some idea of what they are intended to test and the expected outcome of the test. Most people are somewhere in between. The right level of formality depends on your context: a commercial safety-critical application should be at a high level of formality, whilst a one-off application which might be only used by a few people for a short time obviously doesn't need a very high level of formality.

Test analysis: Identifying test conditions
Test analysis is the process of looking at something that can be used to derive test information. It is called "test basis", and could be a system requirement, a technique specification, the code itselt(for structural testing), or a business process. Sometimes tests can be based on an experienced user's knowledge of the system, which could not be documented. We are looking at test basis in order to see what could be tested--these are test conditions. A test condition is simply something that we could test. 

Test design: specifying test cases
Test conditions can be rather vauge,covering quite a large range of possibilities, or a test condition may be more specific. However, when we come to a test case, we are required to be very specific. We need to write down clear every input, step by step scenarios, and expected results for each step. In a test condition, we can use something like "enter a name with valid data", but in it's test case, we must point out a specific name like"Erroll Shand".

Test implementation: specifying test procedures or scripts
When we execute testing, we normally execute a set of tests which are all related to a given functionality or feature, in a particular sequence. These tests need to be testes in correct order, or they won't test what they are meant to test. The document that describes the steps to be taken in running a set of tests is called a test procedure.


D4 of 30 Days' ISTQB: The most important static technique--Review

Static test techniques provide a powerful way to improve the quality and productivity of software development.
Review is the most important one of static techniques. All software organizations can use review in all major aspects including requirements, design, implementation, testing, and maintenance.
In summaries, the use of static testing, e.g.review has various advantages:
--Start test early and then get feedback early on quality issues. E.g an early validation of user requirements, not just get it in late life cycle during acceptance testing.
--By detecting defects in early stage, the rework costs will be relatively low, and so the improvement of the quality of software will be relatively cheap.
--Since the rework effort is reduced, the development productivity figures are likely to increase.
--There is an exchange of information between the participants when doing review.
-- Static testing help to make team keep aware of quality issues.

There are six phases in a formal review, as descripted as following:
1, Planning. When an author request for a paritcular review, the review process begins. A moderator is often assigned to take care of the scheduling of the review. They need to make plan for dates, time, place and invitation. For more formal reviews, the moderator always performs an enry check and defines exit criteria.

2, Kick-off. A kick-off meeting is an optional step. During kick-off meeting, the reviewers received a short introduce of the document under review. The goal of the kick-off meeting is to get every body on the same wavelength.

3, Preparation. In this stage, all participants work individually on the document under review, using the related document, rules,procedures and checklist provided.

4, Review meeting. Three main things will be done in the review meeting: logging, discussion, decision.
Logging all the defects, issues which are found in preparation stage , page by page, reviewer by reviewer.
Discuss all the logged tiems.
Make decision on the document under review.

5, Rework. The author will improve the document under review, based the decision made in the reivew meeting.

6, Follow-up. The moderator take the responsibility to make sure that the rework actions are done to improve the document under review.


D3 of 30 Days' ISTQB: Test types

There are four test types:

1, Testing of function(functional testing)
The function of a system (or component) is 'what it does'. This is typically described in a requirements specification, a functional specification, or in user cases. There also may be some functions that are 'assumed' to be provided but not documented, which should be tested as well.
Functional testing considers the specified behavior and is often referred to as black-box testing. But this is not entirely true, since black-box testing also includes non-functional testing.
Testing functionality can be done from two perspectives: requirements-based and business-process-based. Requirements-based-testing uses a specification of the functional requirements for the system as the basis for designing tests. Business-process-based testing uses knowledge of the business processes. Business processes describe the scenarios involved in the day-to-day business use of the system.

2, Testing of software product characteristics(non-functional testing)
Non-functional testing, as functional testing, is performed at all test levels.
Non-functional testing includes, but is not limited to, performance testing, load testing, stress testing, usability testing, maintainability testing, reliability testing and portability. It is the testing of "how well the system works".

3, Testing of software structure/architecture(structural testing)
The third target of testing is the structure of the system or component. The techniques used for structural testing are structure-based techniques, also referred to as white-box techniques. Control flow models are often used to support structural testing.

4, Testing related to changes(confirmation and regression testing)
When a test fails, it is reported, and then most often is fixed. We need to execute the test again to confirm that the defect has been fixed. This is known as confirmation test(also known as re-testing.) When doing confirmation testing, it is important to ensure the test is executed in the exactly same way as it was the first time.
After confirmation testing, we also need to check that the system has not regressed because of the change. Regression tests are executed whenever the software changes,either as a results of fixes or new or changed funtionality.


D2 of 30 Days' ISTQB: Test levels

Image result
There are four Test levels according to the above V Model in software life circle:

1, Component testing, also known as unit, module and program testing, searches for defects in, and veriries the functioning of software(e.g. modules, programs, objects,classes,etc.)that are separately testable.

2, Integration testing tests interfaces between components, interactions to different parts of a system such as operating system, file system and hardware or interfaces between system. Integration testing is often carried out by the integrator, but preferably by a specific integration tester or test team.

3, System testing is concerned with the behavior of the whole system/product as defined by the scope of a development project or product.
System testing is most often the final test on behalf of development to verify that the system to be delivered meets the specification and its purpose may be to find as many defects as possible. Most often it is carried out by specialist testers that form a dedicated, and sometimes independent, test team within development, reporting to the development manager or project manager.
System testing should investigate both functional and non-functional requirements of the system. Typical non-functional tests include performance and reliability.

4, Acceptance testing. When the development organization has performed its system test and has corrected all or most defects, the system will be delivered to the user or customer for acceptance testing.
The acceptance test should answer questions such as:
Can the system be releases?
What, if any, are the outstanding(business) risks?
Has development met their obligations?
Acceptance test is most often the responsibility of the user or customer, although other stakeholders may be involved as well.
The goal of acceptance testing is to establish confidence in the system, part of the system or specific non-functional characteristics, e.g.usability, of the system.
Acceptance testing is most often focused on a validation type of testing, whereby we are trying to determine if the system is fit for purpose. Finding defects should not be the main focus in acceptance testing.
Subscribe to: Posts (Atom)