Selenium 4 is releasing soon: What every QA must know?

Selenium 4 version is all set to release this Christmas. Simon Stewart (founding member of Selenium) has officially announced at the recently held selenium conference at Bangalore. Some major changes in the upcoming Selenium 4 have been revealed. So, it’s time to get ahead of the curve and figure out what is going to be changed, added and deprecated. In this article, we will take a look a few important features and give an insight on updates you can expect for your automation framework.

W3C WebDriver Standardization

The Selenium 4 WebDriver will be completely W3C Standardized. The WebDriver API has grown to be relevant outside of Selenium. It is used in multiple tools for automation. For example, it’s used heavily in mobile testing through tools such as Appium and iOS Driver. The W3C standard will encourage compatibility across different software implementations of the WebDriver API.

Let’s take an example of how Selenium Grid communicates with Driver executables as of now –

A test in Selenium 3.x, at local end (through json wire protocol) communicates with browser at End node.This requires encoding and decoding of API. In Selenium 4, test will directly communicate without any encoding and decoding of API requests (through W3C Protocol) though java bindings will be backward compatible but focusing more on W3C Protocol.

The Json wire protocol will no longer be used.

There are multiple contributors in webdriver  W3C specs. All of the work done is on github which can be found on- https://github.com/w3c/webdriver

Selenium 4 IDE TNG

The Selenium IDE support for Chrome is in bucket. As we all know that Selenium IDE is a record and playback tool. It will now be available with much more rich and advance features such as:

  • New plugin system– Any browser vendor will now be able to easily plug-in to the new selenium IDE. You can have your own locator strategy and can plug in selenium IDE.
  • New CLI runner – It will be completely based on nodejs and not old html based runner. It will have following capabilities-
    • WebDriver Playback – The new Selenium IDE runner will be completely based on WebDriver.
    • Parallel execution- The new CLI runner will also support parallel test case execution and will provide useful information like time taken, number of test cases passed and failed.

Improved Selenium Grid

The one who have worked on Selenium Grid must know how difficult it is to setup and configure.Selenium Grid supports test case execution on different browsers, operating systems and machines. Thus it provides parallel execution capability.

There are two main elements in Selenium Grid-  Hub and  Node.

Hub- Acts as a server,a central point to control all the test machines in a network. In selenium grid there is only one hub which allocates the test execution to a particular node based on capability matches.

Node- In simple words node is a test machine where test cases actually run.

For more details on selenium grid,follow the tutorial here- https://www.seleniumhq.org/docs/07_selenium_grid.jsp

The typical process to setup selenium grid till now caused testers sometimes to face difficulty in connecting node to hub.

In Selenium 4 the grid experience is going to be easy and smooth. As there will not be any need to setup and start hub and node separately. Once we start selenium server, the grid will act as both hub and node.

Selenium 4 will come up with more stable selenium grid in terms of removing all thread-safety bugs, and a better support for docker.

Better Selenium Grid UI

The Selenium 4 would come up with more user friendly UI of grid having relevant informations about sessions running, capacity etc.

Better Observability

“Passive observability is the ability to do descriptive tracing.”  
– Simon Stewart

Observability, logging and debugging is no more confined to DevOps in recent times. As part of this release request tracing and logging with hooks will be improved so as to provide automation engineers a hold on debugging.

Refreshed Documentation

Documentation plays a key role in any project’s success. Selenium docs were not updated since selenium 2.0 release. In the latest upgrade selenium documentation is also going to be refreshed and detailed [WIP].You can access it on – https://seleniumhq.github.io/docs/

Selenium 4 In a nutshell

Upgrading to the latest version of selenium should not require any code changes.  Setting up node and hub will become smooth and the entire grid experience is going to be streamlined. For automation engineers, the latest version should not be challenging and existing automation framework should work with minimal changes.

Agile Scrum Ceremonies

Abstract

Many of us are very familiar with the inputs, tools, techniques, and outputs (ITTOS) of traditional project management in a Project Management Institute way. I am making an attempt here to map the Scrum model into ITTOs for anyone’s understanding and easy implementation.

Introduction

To become expert in any system, one must understand the ecosystem by knowing the inputs to the system, the tools and technologies used to process the inputs, and finally the outputs of the system. In the Agile/Scrum delivery model we have various inputs, tools, and technologies to process, and finally there will be outputs.

Scrum in nutshell

Scrum suggests three roles: the team, ScrumMaster, and product owner; four ceremonies: the sprint planning meeting, Daily Scrum, sprint review meeting, and sprint retrospective meeting; and three artifacts: the product increment, product backlog, and sprint backlog. We will try to understand the various elements that support these ceremonies in terms of ITTOs. The complete Scrum team attends all the ceremonies except the retrospective, which the product owner may or may not attend.

Sprint planning meeting

Timebox: Eight hours for a four-week sprint, proportionately shorter for shorter sprints
Attendees: The complete Scrum team, including all roles
Most important: Team capacity and DoD (Definition of Done)

Daily Scrum

Timebox: Fifteen minutes is standard, irrespective of the duration of the sprint length
Attendees: The complete Scrum team, including all roles
Most important: To speak about any impediments

Sprint review meeting

Timebox: Four hours for a four-week sprint, proportionately shorter for shorter sprints
Attendees: The complete Scrum team, including all roles, plus any other stakeholders who are interested in the project success
Most important: Demo of working software and assessing the feedback

Sprint retrospective meeting

Timebox: Three hours for a four-week sprint, proportionately shorter for shorter sprints
Attendees: The complete Scrum team, including all roles; the product owner’s attendance is optional
Most important: To brainstorm and agree on what is working and what is not

Conclusion

I think this helps map Scrum for those familiar with PMI, and any PMP can easily relate the concepts of Agile/Scrum that would be useful in transitioning from a Waterfall delivery model to an Agile delivery model. These ITTOs can be extended to a few other Scrum practices, such as Sprint Zero, Sprint H, and a mid-sprint health check. As these best practices are not prescribed in the Scrum framework, I do not focus on them here.

Skills required to become a Software Tester

Non-Technical Skills

Following skills are essential to becoming a good software tester. Compare your skill set against the following checklist to determine whether Software Testing is a reality for you-

  • Analytical skills: A good software tester should have sharp analytical skills. Analytical skills will help break up a complex software system into smaller units to gain a better understanding and create test cases. Not sure that you have good analytical skills – Refer this link – if, if you can solve at least ONE problem you have excellent analytical skills.
  • Communication skill: A good software tester must have good verbal and written communication skill. Testing artifacts (like test cases/plans, test strategies, bug reports, etc.) created by the software tester should be easy to read and comprehend. Dealing with developers (in the event of bugs or any other issue) will require a shade of discreetness and diplomacy.
  • Time Management & Organization Skills: Testing at times could be a demanding job especially during the release of code. A software tester must efficiently manage workload, have high productivity, exhibit optimal time management, and organization skills
  • GREAT Attitude: To be a good software tester you must have a GREAT attitude. An attitude to ‘test to break’, detail orientation, willingness to learn and suggest process improvements. In the software industry, technologies evolve with an overwhelming speed, and a good software tester should upgrade his/her technical skills with the changing technologies. Your attitude must reflect a certain degree of independence where you take ownership of the task allocated and complete it without much direct supervision.
  • Passion: To Excel in any profession or job, one must have a significant degree of the passion for it. A software tester must have a passion for his / her field. BUT how do you determine whether you have a passion for software testing if you have never tested before? Simple TRY it out and if software testing does not excite you switch to something else that holds your interest.

Technical Skills

This list is long, so please bear with me

  • Basic knowledge of Database/ SQL: Software Systems have a large amount of data in the background. This data is stored in different types of databases like Oracle, MySQL, etc. in the backend. So, there will be situations when this data needs to be validated. In that case, simple/complex SQL queries can be used to check whether proper data is stored in the backend databases.
  • Basic knowledge of Linux commands: Most of the software applications like Web-Services, Databases, Application Servers are deployed on Linux machines.So it is crucial for testers to have knowledge about Linux Commands.
  • Knowledge and hands-on experience of a Test Management Tool:  Test Management is an important aspect of Software testing. Without proper test management techniques, software testing process will fail. Test management is nothing but managing your testing related artifacts.For example – A tool like Testlink can be used for tracking all the test cases written by your team.There are other tools available that can be utilized for Test Management. So, it is important to have knowledge and working experience of such tools because they are used in most of the companies.
  • Knowledge and hands-on experience of any Defect Tracking tool- Defect Tracking and Defect life cycle are key aspects of software testing. It is extremely critical to managing defects properly and track them in a systematic manner. Defect tracking becomes necessary because the entire team should know about the defect including managers, developers, and testers. Several tools are used to lock defects including QC, Bugzilla, Jira etc. 
  • Knowledge and hands-on experience of Automation tool: If if you see yourself as an “Automation tester” after a couple of years working on manual testing, then you must master a tool and get in-depth, hands-on knowledge of automation tools.
  • Note – Only knowledge of any Automation tool is not sufficient to crack the interview, you must have good hands-on experience, so practice the tool of your choice to achieve mastery. Knowledge of any scripting language like VBScript, Java Script, C#  is always helpful as a tester if you are looking for a job into automation. Few companies also use Shell/Perl scripting, and there is a lot of demand for testers having knowledge of the same. Again, it will depend on the company and which tools are used by that company.

There is also a lot of scope for Performance Testing tools because applications need to be tested for their performance which is a part of non-functional testing.

Note: That’s it to technical knowledge. Please note you do not need ALL the technical skills listed above. The technical skill sets required vary with the Job Role and company processes.

Why is Software Testing Important?

Testing is important because software bugs could be expensive or even dangerous. Software bugs can potentially cause monetary and human loss, history is full of such examples.

  • In April 2015, Bloomberg terminal in London crashed due to software glitch affected more than 300,000 traders on financial markets. It forced the government to postpone a 3bn pound debt sale.
  • Nissan cars have to recall over 1 million cars from the market due to software failure in the airbag sensory detectors. There has been reported two accident due to this software failure.
  • Starbucks was forced to close about 60 percent of stores in the U.S and Canada due to software failure in its POS system. At one point store served coffee for free as they unable to process the transaction.
  • Some of the Amazon’s third party retailers saw their product price is reduced to 1p due to a software glitch. They were left with heavy losses.
  • Vulnerability in Window 10. This bug enables users to escape from security sandboxes through a flaw in the win32k system.
  • In 2015 fighter plane F-35 fell victim to a software bug, making it unable to detect targets correctly.
  • China Airlines Airbus A300 crashed due to a software bug on April 26, 1994, killing 264 innocent live
  • In 1985, Canada’s Therac-25 radiation therapy machine malfunctioned due to software bug and delivered lethal radiation doses to patients, leaving 3 people dead and critically injuring 3 others.
  • In April of 1999, a software bug caused the failure of a $1.2 billion military satellite launch, the costliest accident in history
  • In may of 1996, a software bug caused the bank accounts of 823 customers of a major U.S. bank to be credited with 920 million US dollars.

Software Testing

Software testing is an activity to check whether the actual results match the expected results and to ensure that the software system is Defect free. It involves execution of a software component or system component to evaluate one or more properties of interest.

Software testing also helps to identify errors, gaps or missing requirements in contrary to the actual requirements. It can be either done manually or using automated tools. Some prefer saying Software testing as a white box and Black Box Testing.

Statement & Decision Coverage

Statement Coverage is said to make sure that make sure that every statement in the code is executed at least once.

Decision / Branch Coverage is said to test that each branch/output of a decisions is tested, i.e. all statements in both false/true branches will be executed.

If the tests have complete branch coverage then we can say it also has complete statement coverage, but not the vice versa.

100% branch coverage => 100% statement coverage

100% statement coverage does not imply 100% branch coverage

the reason is in branch coverage apart from executing all the statements, we should also verify if the tests executes all branches, which can be interpreted as covering all edges in the control flow branch 

if(a)
{
   if(b)
   {
     bool statement1 = true;
   }
}

a = true, b = true will give 100% statement coverage, but not branch coverage

enter image description here

In the branch coverage we need to cover all the edges, which we missed in the statement coverage shown as red lines in the above image.

ISTQB – Changes in Foundation Level Certification

ISTQB – Changes in Foundation Level Certification

On June 4, 2018, ISTQB, launched the new version of the Foundation Level certification. It migrated from the 2011 version to 2018. The Foundation Level is the base certification of ISTQB. It establishes the minimum and essential knowledge about testing. The rest of the certifications of this institution, have as a prerequisite, have passed this level.

As it became known, this change occurs for two main reasons. First, because the testing industry has changed a lot in recent years and they wanted to accompany this change. On the other hand, they wanted to make a more practical certification, giving more importance to the applied knowledge.

On the official ISTQB website you can find:

This 2018 syllabus has following updates in terms of software development

  • Agile methods
  • Continuous Integration/Continuous Delivery
  • Delivery pipelines
  • IoT

The updates reflect market feedback and current status of the software testing industry. For More information, see the press release.

As the ISTQB certificate on the foundation and Advanced Level is lifelong, there is no requirements to take the new course or certify again to keep you certified.

The purpose of the new syllabus is that newcomers in the testing world will get the training and/or certification corresponding to the environment they now will work in and gain the knowledge that earlier certified people have learned during their practical work.

Yes, the number of learning objectives have been changed and redistributed across the 6 chapters of the syllabus therefore the number of exam questions per chapter have changed also.

Foundation Level 2011 in a Nutshell

Note: On 4th June 2018, ISTQB released the new 2018 Foundation Level syllabus. The 2011 Foundation Level Certificate will remain valid and will be accepted as a pre-requisite for Advanced, Agile and Specialist certifications.

The 2011 Syllabus will be phased out as follows:

  • English language by 3rd June 2019 (12 months from release of the 2018 Foundation syllabus)
  • Non-English language by 3rd December 2019 (18 months from release of the 2018 Foundation syllabus)

For more information please go to the 2018 Syllabus FAQs here.

Please refer some Frequently Asked Question (FAQ):

What has changed in general compared to the 2011 syllabus?

There are fewer K1 and K2 learning objectives and there is increased focus on practical K3 learning objectives. Additionally, there is more emphasis on review in Chapter 3 and less on white box testing in Chapter 4.

Has the ISTQB Glossary been updated?

The glossary has been updated to align with the new 2018 Foundation Level syllabus. For the glossary click here.

Is there a change in the structure of the exam?

Yes, the number of learning objectives have been changed and redistributed across the 6 chapters of the syllabus therefore the number of exam questions per chapter have changed also.

What’s has changed in the 2018 Foundation?

  • Fewer K1 Learning Objectives (LO) in general (15 LO in 2018 compared with 27 LO in 2011)
  • Less focus on Chapter 5 Test Management (15 LO in 2018 compared with 24 LO in 2011)
  • More emphasis on review, a K3 LO has been added to Chapter 3 (Static Analysis by Tools section has been removed, and will be covered in other syllabi)
  • More emphasis on test techniques in Chapter 4 (Section 4.1 of 2011 moved and merged with section 1.4 of Chapter 1)
  • Agile is mentioned in the content of the syllabus (But not included in the wording of any LO)
  • White-box techniques are downgraded (K4 and K3 LO removed – these topics will be covered in other ISTQB® syllabi.)

Additional changes made to the 2018 Foundation Syllabus are:

  • ISO/IEC/IEEE 29119 is now used for reference instead of IEEE Standard 829.
  • ISO/IEC 25010 is now used for reference instead of ISO 9126.
  • ISO/IEC 20246 is now used for reference instead of IEEE 1028
  • The Code of Ethics has been moved from chapter one to ISTQB®.ORG website