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.

Performance Testing and performance testing tool: Jmeter


What is performance testing?
performance testing is in general, a testing practice performed to determine how a system performs in terms of responsiveness and stability under a particular workload. It can also serve to investigate, measure, validate or verify other quality attributes of the system, such as scalability, reliability and resource usage.

And I've just a wonderful performance testing tool--Jmeter!

  • Ability to load and performance test many different applications/server/protocol types:
    • Web - HTTP, HTTPS (Java, NodeJS, PHP, ASP.NET, …)
    • SOAP / REST Webservices
    • FTP
    • Database via JDBC
    • LDAP
    • Message-oriented middleware (MOM) via JMS
    • Mail - SMTP(S), POP3(S) and IMAP(S)
    • Native commands or shell scripts
    • TCP
    • Java Objects
For more information about Jmeter, may visit: https://jmeter.apache.org/

D1 of 30 Days' ISTQB : Why is Testing Necessary?

1.1  Why is Testing Necessary?


1.1.1 Software Systems Context
Software systems are an integral part of life, from business applications(e.g. banking)to consumers(e.g. cars). Most people have had an experience with software that did not work as expected. Software that does not work correctly can lead to many problems, including loss of money, time or business reputation, and even cause injury or death.

 1.1.2  Causes of software Defects
A human being can make an error(mistake), which produces a defect(fualt, bug) in the program code, or in a document. If a defect in code is executed, the system may fail to do what it should do (or do something it shouldn't),causing a failure. Defects in software, systems or documents may result in failures, but not all defects do so.

Defects occur because  human beings are fallible and because there is time pressure,complex code, complexity of infrastruture, changing technologies, any/or many system interactions.

Failure can be caused by environmental conditions as well. For exsample,radiation, magnetism, electronic fields, and pollution can cause faults in firmware or influence the execution of sftware by changing the hardware conditions.

1.1.3  Role of Testing in Software Development, Maintenance and Operations
Rigorous testing in systems and documentation can help to reduce the risk of problems occuring during operation and contribute to the quality of the software system, if the defects found are corrected before the system is released for operational use.

Software testing may also be required to meet contractual or legal requirements, or industry-specific standards.

1.1.4  Testing and Quality
With the help of testing, it is possible to measure the quality of software in terms of defects found, for both functional and non-functional software requirements and characteristics (e.g. reliability, usability, maintainability and portability).

Testing can give confidence in the quality of the software if it finds few or no defects. A properly designed system that passes reduces the level of risk in a system. When testing does find defects, the quality of the software system increases when those defects are fixed.

Lessons should be learned from previous projects. By understanding the root causes of defects found in other projects, processes can be improved, which in turn should prevent those defects from reoccuring and ,as a consequence, improve the quality of future systems. This is an aspect of quality insurance.

1.1.5  How Much Testing is Enough
Deciding how much testing is enough should take account of the level of risk, including technical, safety, and business risks, and project constraints such as time and budget.

Testing should provide sufficient information to stakeholder to make decisions about the release of the software or system being tested, for the next development step or handover to the customers.

Why is it necessary to have expected results for every test step?


We should better write expected results for every test step when we are designing test cases, why?

 Just image: If there is a test case with 15 test steps and one expected result, how would a test executor know which step of the test case failed. So, in order to make it very clear it is important to have expected result designed for every test step.

 There are two test cases as following, one has only the final expected results, the other one has results for every step. See the difference:

Test Case ID Test Case Name Scenario Expected Result Complexity
TC_001_01 Check if the user can navigate to "Add New Property" page by clicking "Add New Property " button on "Owners->Properties" page. Step 1: Navigate to the URL http://dev.property.community/ , will go to Login page.
Step 2 : Enter the username as "****@gmail.com" and password as "****" to sign in. 
Step 3 : Click on Owners.
Step 4 : Click on Properties.
Step 5 : Click on Add New Property.		 "Add New Property" page should be opened where the user can edit a new property record Simple
TC_001_02 Check if the user can add a new property with valid data on "Add New Property" page. Step 1: Navigate to the URL http://dev.property.community/
Step 2 : Enter the username as "****@gmail.com" and password as "****" to sign in.
Step 3 : Click on "Owners".
Step 4 : Click on "Properties".
Step 5: Click "Add New Property"
Step 6: Enter valid data on the "PROPERTY DETAILS" page and click on Next button.
Step 7: Enter valid data on the "FINANCIAL DETAILS" page and click on Next button.
Step 8: Enter valid data on the "TENANT DETAILS" page and click on Save button.		 Step 1: User should be navigated to the login page successfully
Step 2: The Dashboard should be opened.
Step 3: The drop-down menu of "Owners" should be opened.
Step 4:  "Owners>Properties" page should be opened
Step 5: "Add New Property" page should be opened.
Step 6: User should go "FINANCIAL DETAILS" page.
Step 7: User should go "TENANT DETAILS" page.
Step 8: User should go back to "Owners>Properties" page and the new property just added should appear on this page		 Medium

A solution of "Seach something on Google" in C# using Specflow

First, create a feature

Feature: GoogleSearch
@mytag
Scenario: Search in Google for something
Given I am in the Google Home
And I have entered  'selenium'
When I press Enter button
Then the result should be displayed with 'selenium' page

Secondly, generate step definitions of the feature.

using OpenQA.Selenium;
using OpenQA.Selenium.Chrome;
using System;
using TechTalk.SpecFlow;

namespace GoogleSearch
{
    [Binding]
    public class GoogleSearchSteps
    {
        private IWebDriver driver;

        [Given(@"I am in the Google Home")]
        public void GivenIAmInTheGoogleHome()
        {
            driver = new ChromeDriver();
            driver.Navigate().GoToUrl("https://www.google.co.nz/");
        }
     
        [Given(@"I have entered  '(.*)'")]
        public void GivenIHaveEntered(string p0)
        {
            driver.FindElement(By.XPath(".//*[@id='lst-ib']")).SendKeys(p0);
        }
     
        [When(@"I press Enter button")]
        public void WhenIPressEnterButton()
        {
            driver.FindElement(By.XPath(".//*[@id='lst-ib']")).SendKeys(Keys.Enter);
        }
     
        [Then(@"the result should be displayed with '(.*)' page")]
        public void ThenTheResultShouldBeDisplayedWithPage(string p0)
        {
            //var pageTitle = driver.Title;
            //var expectedTitle = p0 + " - Google 搜索";
            if (driver.Title == p0 + " - Google 搜索")//if (pageTitle==expectedTitle)
                Console.WriteLine("Test Success");
            else
                Console.WriteLine("Test Failed");
        }
    }
}

Seven Testing Principles


Seven testing principles:

Principle 1: Testing shows presence of defects--Testing can show that defects are present, but cannot prove that there are no defects. Testing reduce the probabilily of undiscovered defects remaining in the software but, even if no defects are found, it is not a proof of correctness.

Principle 2: Exhaustive testing is impossible--Testing everything (all combinations of inputs and preconditions)is not feasible except for trivial cases. Instead of exhaustive testing, we use risks and priorities to focus testing efforts.

Principle 3: Early testing--Testing activities should starts as early as possible in the software of system development life cycle and should be focused on defined objectives.

Principle 4: Defect clustering--A small number of modules contain most of the defects discovered during pre-release testing or show the most operational failures.

Principle 5: Pesticide paradox--If the same tests are repeated over and over again, eventually the same set of test cases will no longer find any new bugs. To overcome this 'pesticide paradox', the test cases need to be regularly reviewed and revised, and new and different tests need to be written to exercise different parts of the software or system to potentially find more defects.

Principle 6: Testing is context dependent--Testing is done differently in different contexts. For example, safety-critical software is tested differently from an e-commerce site.

Principle 7: Absence-of-errors fallacy--Finding and fixing defects does not help if the system built is unusable and does not fulfill the user's needs and expectations.

ISTQB definition of software testing


    Let's look at the ISTQB definition of software testing.
 
    The definition starts with a description of testing as a process and then lists some objectives of the test process.

    First, let's look at testing as a process:


  • Process ----Testing is a process rather than a single activity-there are a series of activities involved.
  • All life cycle activities----Testing takes place throughout the software development life cycle.
  • Both static and dynamic----tests where the software code is executed to demonstrate the results of running tests,often called dynamic testing. tests, reviewing of documents(including source code)and static analysis, are called static testing.
  • Planning----Activities take place before and after test execution to manage the testing.
  • Preparation----To choose what testing we'll do, by selecting test conditons and designing test cases.
  • Evaluation----To check the results and evaluation the software under test and the completion criteria, to decide whether the software product has passed the test.
  • Software products and related work products----We don't just test code.We test the requirements and design specifications and the related documents. Static and dynamic testing are both needed to cover the range of products we need to test.
    The second part of the definition covers the some of the objectives for testing-the reasons why we do it:
  • Determine that(software products)satisfy specified requirements.
  • Demonstrate that(software products)are fit for purpose.
  • Detect defects. 
    This is a suitable definition of testing for any level of testing, from component testing through to acceptance testing.

What is Git----A first glance of Git


Git: Version Control System (VCS) are used for tracking changes in source code file.

---Distributed version control
---Coordinates work between multiple developers/testers.
---Who made what changes and when
---Revert back at any time
---Local and Remote - DevOps
---Keeps track of code history
---Takes snapshop of your files
---You decide when to commit your changes
---You can visit code change anytime
---You stage files before commiting

Start to learn GitHub from today----Day1 on GitHub



What is GitHub?
----GitHub is a code hosting platform for version control and collaboration. It lets you and others work together on projects from anywhere.

GitHub essentials: repositories, branches, commits, and Pull Requests. 

Today I created my first github repository named "hello-world". I did some actions as fpllowing:

  1. Create a Repository
  2. Create a Branch
  3. Make a Commit
  4. Open a Pull Request
  5. Merge Pull Request
Subscribe to: Posts (Atom)