I recently created a course on Udemy to help students prepare for the ISTQB Agile Tester Certification Exam.
This course will provide you with all the tools that you need to prepare an successfully pass the ISTQB Agile Tester Certification exam. The Agile Tester certification, will greatly boost your understanding of Agile and boost your career opportunities. I will cover in detail the information below.
The certification for Foundation Level Extension – Agile Tester is designed for professionals who are working within Agile. It is also for professionals who are planning to start implementing Agile methods in the near future, or are working within companies that plan to do so, The certification provides an advantage for those who would like to know the required Agile activities, roles, methods, and methodologies specific to their role.
1. Professionals who have achieved in-depth testing experience in traditional methods and would like to get an Agile Tester Certificate.
2. Junior professional testers who are just starting in the testing profession, have received the Foundation Level certificate, and would like to know more about the tester’s role in an Agile environment.
3. Professionals who are relatively new to testing and are required to implement test approaches, methods and techniques in their day to day job in Agile projects.
4. Professionals who are experienced in their role (including unit testing) and need more understanding and knowledge about how to perform and manage testing on all levels in Agile projects.
These professionals include people who are in roles such as testers, test analysts, test engineers, test consultants, test managers, user acceptance testers, and software developers. This Foundation Level Extension – Agile Tester certification may also be appropriate for anyone who wants a deeper understanding of software testing in the Agile world, such as project managers, quality managers, software development managers, business analysts, IT directors, and management consultants
The following content will be covered:
Chapter 1: Agile Software Development
The tester should remember the basic concept of Agile software development based on the Agile Manifesto.
The tester should understand the advantages of the whole-team approach and the benefits of early and frequent feedback.
The tester should recall Agile software development approaches.
The tester should be able to write testable user stories in collaboration with developers and business representatives.
The tester should understand how retrospectives can be used as a mechanism for process improvement in Agile projects.
The tester should understand the use and purpose of continuous integration.
The tester should know the differences between iteration and release planning, and how a tester adds value in each of these activities.
Chapter 2: Fundamental Agile Testing Principles, Practices, and Processes
The tester should be able to describe the differences between testing activities in Agile projects and non-Agile projects.
The tester should be able to describe how development and testing activities are integrated in Agile projects.
The tester should be able to describe the role of independent testing in Agile projects.
The tester should be able to describe the tools and techniques used to communicate the status of testing in an Agile project, including test progress and product quality.
The tester should be able to describe the process of evolving tests across multiple iterations and explain why test automation is important to manage regression risk in Agile projects.
The tester should understand the skills (people, domain, and testing) of a tester in an Agile team.
The tester should be able to understand the role of a tester within an Agile team.
Chapter 3: Agile Testing Methods, Techniques, and Tools
The tester should be able to recall the concepts of test-driven development, acceptance testdriven development, and behavior-driven development.
The tester should be able to recall the concepts of the test pyramid.
The tester should be able to summarize the testing quadrants and their relationships with testing levels and testing types.
For a given Agile project, the tester should be able to work as a tester in a Scrum team.
The tester should be able to assess quality risks within an Agile project.
The tester should be able to estimate testing effort based on iteration content and quality risks.
The tester should be able to interpret relevant information to support testing activities.
The tester should be able to explain to business stakeholders how to define testable acceptance criteria.
Given a user story, the tester should be able to write acceptance test-driven development test cases.
For both functional and non-functional behavior, the tester should be able to write test cases using black box test design techniques based on given user stories.
The tester should be able to perform exploratory testing to support the testing of an Agile project.
The tester should be able to recall different tools available to testers according to their purpose and to activities in Agile projects.
There has certainly been an impact of COVID-19 on the Software Testing Industry. There are several areas which I would like to analyze and break down into further detail. Those areas include: resource impact, testing impact, and workplace impact.
The impact of COVID-19 on the software testing industry first area of impact is on resources. This includes both employees and contractors. There have been so many industries that have been significantly impacted, that it has devastated the software testing industry. Four industries that come to mind is: manufacturing, travel/hospitality, restaurants and retail industries. These have probably been the ones that have been hammered the most. If you think about it, it makes sense that these are the hardest hit areas. These industries all require software, and that requires testers. When COVID-19 started to impact these industries, software testers were hit hard. This is especially true with contracting companies who heavily rely on these major industries in providing software testing resources. Typically, the companies will cut the software testing contractors first before software employees are impacted. There is also an additional impact in terms of travel and visa delays, since airline travel was impacted and visa restrictions hampered international travel. Software testing contracting firms rely heavily on resources across the globe and even if the resources were available and had the necessary visa paperwork in place, but if airlines weren’t operating, they wouldn’t be able to get to the customer’s location.
The impact of COVID-19 on the software testing industry second area of impact is on testing. COVID-19 has required companies to change how they support their customers. In certain industries such as insurance and banking, companies have given credits or refunds back to their customers to help them during this difficult time. This has required companies to change how those systems operate, especially to give credits or refunds for their entire customer base. In the United States, since companies are located across states, each state has different rules and governing bodies. This requires that the software testers understand the rules, and that testing has to be specific for each state. This requires time and test data that is unique to make sure that the testing is adequate. It took a while for most companies to wait and understand what the governing bodies required. The good news is that it gave companies time to figure out what changes were needed, so that bought them some additional time before those were implemented. Most companies gave two months worth of credit and reimbursements.
The impact of COVID-19 on the software testing industry third area of impact is on the workplace. The workplace was drastically impacted because of COVID-19. For most companies, software testers typically work within an office setting. With COVID-19, software testers were moved into a remote workforce. Most companies were already capable of working remotely since laptops and VPN’s were setup and operational. Typically most companies already have WebEx, Zoom, and Microsoft Teams available. The biggest challenge in some situations was the impact on the offshore testers. While some software testers already had laptops, that wasn’t the case for all contracting firms. This required a significant effort to get software testers with the laptops that were needed. In addition, there were some software testers who didn’t always have reliable internet, so that required companies to make adequate adjustments to get the software testers with what is needed. Some of the larger firms such as Infosys, have huge offices that have housing available where resources can remain on the campus.
I hope this information has been helpful. COVID-19 has certainly impacted the software testing industry, and I am hoping that it will make things better and prepared to handle current COVID-19 and other pandemics which will occur in the years to come.
There are several situations where test automation doesn’t make good financial sense. Let’s face it, test automation is great, and I am the greatest champion of test automation. If done effectively, it will result in tremendous Test Automation ROI and significantly increase the ability for the QA team to test a wide assortment of tests. The key is you have to be smart. Just because you can automate it, doesn’t mean that you should.
QA has become highly technical. The technical capabilities of teams today are far more advanced than they were 5 years ago. This has tremendous advantages but it can also be extremely dangerous. The same resources who can work circles around their predecessors are also the ones that are laser focused on proving their technical acumen and aim to prove their worth to their bosses and peers. One thing they forget: Test Automation ROI.
I have been using automation since I started my testing career 20+ years ago. I have learned a lot and I have both automated and had teams that automated things that other previous teams had miserably failed. I constantly heard statements like : “you can’t automate that”, “we have already tried that”, “I can execute it faster than a script”, “this is a waste of time”. I have proved all them wrong.
I have seen a few situations where test automation simply doesn’t make sense. I have made these mistakes and I have learned.
New Applications: It doesn’t make sense to automate brand new applications right from the start. With new applications, requirements are constantly changing and the UI goes through many iterations. Not only is this difficult to test from a manual perspective, it becomes impossible to keep up with the automated scripts. The best thing to do, is to give it time and come back once things have stabilized. You will be able to automate scripts a lot faster, and it will result in less frustration and a higher ROI.
Frequent UI changes: If you are creating test automation scripts and the UI is constantly in flux, it will result in constant script updates and it often results in things becoming unmanageable. Every code build will result in automation scripts which are broken, and those will have to be updated. My best advice is to be patient and wait.
Data Model updates: If your application is going through a lot of data model changes, it will result in UI changes which will have an impact on your scripts. These data model changes are often done early on, so if you give it sometime to settle, you can step in and automate those components.
Stable Code: One of the most important factors is to have stable code. If the code isn’t stable, and there are a lot of defects and frequent code builds, this will often result in a high degree of test automation failures. It is crucial to let the code settle, and in some situations have less code delivery, in order to maximize test automation coverage. More builds don’t necessarily mean better applications.
Cucumber is one of the most popular tools for behavior driven development testing. Cucumber enables the creation of automated behavior driven development acceptance tests leveraging the Gherkin framework. Cucumber is open-source so you don’t need to worry about paying expensive licensing fees. Cucumber testing tool is written in the Ruby programming language.
What is Behavior Driven Development?
Behavior-Driven Development (BDD) is a software development process within Agile that Cucumber was designed to support. It is one of the leading BDD testing tools on the market today.
Open communication and collaboration across roles
Work in small iterations increasing feedback and creating business value
Producing documentation that enables automation of user acceptance tests
BDD does not replace the Agile process but rather enhances the overall process.
Cucumber Testing Tool Benefits
Testers will be able to write automated tests without needing in depth understanding of a programming language
Cucumber supports multiple programming languages
There is a high degree of reusable code
Cucumber is quick and easy to setup
Cucumber allows integration with Selenium, Watir, Spring, Ruby on Rails and many more
If you are looking for information on how to install Cucumber you can go to the main website located here. Cucumber is widely used so there are many programming languages across multiple platforms. It is always a good idea to install the one that closely matches your application. Some of the most common programming languages used with Cucumber are: Java, Ruby, PHP, Python, and Perl.
Behavior Driven Development has gained a lot of traction over the past several years with the adoption of Agile across most IT organizations. One of the most common used tools is Cucumber and it uses the Gherkin framework to automate tests. Gherkin language is defined as a business readable, domain specific language created especially for behavior descriptions. The purpose of Gherkin is to promote behavior driven development across the entire team. This includes business analysts, developers, testers, and product owners. The Gherkin framework promotes firmly written requirements and eliminate ambiguity. While Gherkin is primarily used in English, there are a total of 37 spoken languages that can be used. Gherkin serves two basic purposes: provides project documentation and helps in creating automated tests. The most commonly used automation tool for Behavior Driven Development is Cucumber.
Gherkin Language Keywords
Here are the primary Gherkin keywords:
Example or Scenario
Given, When, Then, And, But
Scenario Outline or Scenario Template
Here are secondary Gherkin keywords:
Document Strings: ” “
Data Tables: |
Gherkin Syntax Example
#This is an example of how you can use the Gherkin syntax
Feature: Login functionality of Amazon
Given: I am an Amazon user
When: I enter username as username.
And I enter the password as password
Then I should be redirected to the home page of Amazon
Gherkin Best Practices
Each feature should be executed separately
Each scenario should be executed separately
Leverage your scenarios with your requirements
Make your steps modular and simple to understand
Combine common scenarios
Gherkin syntax is easy and simple for everyone including non-programmers to understand
Programmers can leverage Gherkin to write automated tests
Requirements are firm and unambiguous
Gherkin can be used to write user stories
You don’t need to be an expert to understand Gherkin
Gherkin automatically links acceptance tests to automated tests
There is significant reuse of tests
Requires a lot of collaboration across the team and business partners
There might be some situations where it isn’t an ideal solution
Poorly written Gherkin will result in high test maintenance