:::: MENU ::::

Software testing enthusiast.

Showing posts with label quality assurance. Show all posts
Showing posts with label quality assurance. Show all posts

 

Software testing is an important part of developing software. There are many different types of software testing, each with their own goals and methods.



Functional Testing

Functional testing is used to test the features and functions of a program. Functional testing includes Unit Testing, Integration Testing, System Testing and Acceptance Testing.

Functional testing can be used at any level of development: unit level (testing individual units), integration level (testing groups of units), system level (testing entire systems) or acceptance level (testing whole applications).


lambdatest

Non-Functional Testing

If you’re not a software developer, the terms “functional” and “non-functional” may sound like jargon. But they’re actually quite straightforward:

Functional testing refers to how well your application performs its intended tasks. If it’s supposed to help users search for flights and hotels, does it actually do that?

Non-functional testing is all about other factors that can affect how well your app works in real life — things like security and performance (how fast does it load?), usability (are there any confusing parts of the design), compatibility with different browsers or devices (will this app work on my phone?).

The problem with functional testing alone is that it doesn’t tell you much about whether your product will be successful in the real world — and as we’ve seen over time, many companies end up releasing products that don’t meet user needs because they didn’t include enough non-functional tests during development stages.

If you are interested more about Functional vs Non-Functional Testing. You can check my writing at https://medium.com/@k-hartanto/functional-vs-non-functional-testing-caf14e1766fe

 

lambdatest

Other Type of Testing

Other types of software testing include ad-hoc testing, back-end testing, browser compatibility and backward compatibility.

Ad-hoc testing is an unstructured form of testing with no reference to the test case, or without any plan or documentation in place. This type of testing is done manually at random intervals during the development cycle so that problems can be identified and fixed before they become too serious.

Back end testing is a type of software testing that checks the server or database of an application or software. In back-end testing, testers don’t use a GUI; they can directly connect to the database with proper access and run queries on it to verify data. Tester usually access it using an API.

Browser compatibility means making sure your website looks good across all browsers so that visitors don’t see any glitches when visiting from different devices such as computers, mobile phones or tablets.

Backward compatibility refers specifically towards older versions of operating systems like Windows XP which still has many users worldwide despite being discontinued over ten years ago now.”

lambdatest

Software testing is an important part of developing software.

Software testing is an important part of developing software. It’s a process of validating and verifying that a software application or computer system conforms to its operational requirements, and satisfies user needs.

If you are looking for software testing materials, training, and certification guides and much more, then Software Testing Help is the only website that you need. Access all the e-books, Courses Videos, and Online Training to get started right away.

Conclusion

I hope you found this article helpful. With so many different types of software testing, it can be hard to keep track of them all. The best way to learn about each type is by reading up on it and seeing how they work in practice!

MydoQA: Twitter | Blog | Instagram | Facebook

Connect with me

Krisnawan: Twitter | Linkedin | Medium

MydoQA: Twitter | Blog | Instagram | Facebook

 Image of Ice cream chart with a note from above: Manual Tests, End to End Tests, Integration Tests, and Unit Tests Image of pyramid chart with a note from above: End to End Tests, Integration Tests, and Unit Tests


lambdatest

What is Testing Pyramid?

Image of pyramid chart with a note from above: End to End Tests, Integration Tests, and Unit Tests
                                                               

  1. Unit Tests
  2. Service Tests
  3. User Interface Tests

It’s all about the cost

‘It costs almost five times more to fix a coding defect once the system is released than it does to fix it in unit testing.’

— Paul Grossman, IT consultant, in ‘Automated testing ROI: fact or fiction?’

Testing Pyramid Component

Unit testing focuses on individual pieces of code. This can give you a detailed view of the code’s quality and performance, enabling you to get fast feedback as to whether your changes will improve things. As such, it makes sense to automate them. Furthermore, automated unit testing makes it easier to pinpoint where problems are so that you can more quickly fix them.

It is expensive to automate high-level tests

As you climb up the testing pyramid, you will encounter issues like:

  • Test fragility (tests that break easily and unexpectedly, even when changes ‘shouldn’t’ have influenced the test)
  • Longer feedback time
  • Increased effort levels
  • Higher costs to implementation
  • More specialized knowledge required

Benefits of the test automation pyramid

  • Time and cost savings
  • Elimination of human error for accuracy
  • Ability to reuse, repeat, and scale application tests to meet your software requirements

What is Ice Cream Cone Pyramid?

Image of Ice cream chart with a note from above: Manual Tests, End to End Tests, Integration Tests, and Unit Tests

Why Ice Cream Cones Are Bad

The anti-pattern that followed the pyramid test pattern was the Testing Ice Cream Cone. Ice cream cone is what happens if you put the majority of testing effort into a manual test.

Resources

Testing Pyramid and Testing Ice Cream Cone

 

The image consists of “Test Process fundamental” text. Picture  of man and woman and a gear, illustrating a process.
Software Testing Process

Introduction

Software testing is the process of evaluating a software system or its components to find defects and assess the quality of the product. It is an integral part of the software development process, as it helps ensure that the developed product meets the specified requirements and is fit for its intended purpose.

Since we can agree on the importance of software testing, we may agree that software testing requires a set of activities to achieve its established objectives. This set of software testing activities is called the software testing process.

The decision about the proper and specific software testing process will depend on several contextual factors. Those contextual factors include, but are not limited to:

  • Software development lifecycle model and project methodologies being used
  • Test levels and test types being considered
  • Product and project risks
  • Business domain
  • Operational constraints, including but not limited to:
    — Budgets and resources
    — Timescales
    — Complexity
    — Contractual and regulatory requirements
  • Organizational policies and practices
  • Required internal and external standards

lambdatest

Test Activities and Tasks

Image of a hand holding a pen creating planning in a white paper
Photo by Kelly Sikkema on Unsplash

Test planning and control

In test planning, we specify the objectives of our testing, as well as the approach for meeting those objectives within constraints imposed by our context (e.g., specifying suitable techniques and tasks for testing). We may revisit these plans based on feedback from monitoring and control activities.

Management of any activity doesn’t stop with planning, there is more to it. For example, we need to control and measure progress against the plan. This is called test control and it is an ongoing activity. We need to compare actual progress against the planned progress and report to the project manager and customer on the current status of testing, including any changes or deviations from the plan.

Image of a gadget screen with “design” text
Photo by Edho Pratama on Unsplash

Test analysis and design

The activity of test analysis and design involves transforming general testing objectives into specific test conditions, as well as creating designs for those conditions.

During the test analysis phase, we analyze the test basis and define associated test conditions. In other words, we determine “what to test” in terms of measurable coverage criteria.

During test design, high-level test cases and sets of high-level test cases are created. These are used to answer the question “how to test?” while test analysis answers the question “what to test?”

Image of someone implementing design in a laptop
Photo by ThisisEngineering RAEng on Unsplash

Test implementation and execution

During the implementation and execution phase, we build a high-level design for our tests by transforming test conditions into test cases and procedures. So, test implementation addresses the question “Have we built everything we need to run our tests?”.

We also need to set up an environment where we will run the tests, build our test data and generate reports. Setting up environments and data often involves significant time and effort, so you should plan and monitor this work carefully.

Image with “exit” text
Photo by Dustin Tramel on Unsplash

Evaluating exit criteria and reporting

Evaluating exit criteria is a way to assess your testing activities against the defined objectives. Every test level needs to be evaluated against its objectives to see if it has met the requirements. This can be done for each project by looking at coverage and completion, acceptance, and process exit criteria.

Coverage and completion tell us how complete the tests are and how many cases must be tested for a given functionality.

Acceptance criteria tell us how we know whether the software has passed or failed overall and may include items such as checking that a system works as expected or that it meets all design standards.

Process exit criteria tell us whether we have completed all the tasks we need to do.

Image with “closed” text
Photo by Tim Mossholder on Unsplash

Test closure activities

During the closure of a test phase, we collect information from the completed activities to consolidate experience and check our knowledge. We might need to do this when the software is delivered or when testing has finished. We also might close testing for other reasons, such as when we have gathered all the information needed from testing, when a particular milestone has been achieved, when a project is canceled, or when an update or maintenance release is done.

Conclusion

Those testing process activities can be implemented sequentially, but for different occasions, they may overlap, take place concurrently, and often be implemented iteratively.

The software testing process is a crucial set of test activities in software testing as it helps ensure that the test objectives are achieved.

How to use AI to make an article

Copy AI

 

Connect with me

Krisnawan: Twitter | Linkedin | Medium

MydoQA: Twitter | Blog | Instagram | Facebook

 

In this article, I will talk about functional and non-functional testing, and how both of them complement each other.

The image contains sentence “Functional testing vs non-functional testing”, two personal computers, the monitors show: list, bug, gear, gauge, cloud, and graphic.
Functional vs non-functional testing

What is?

Functional testing is a type of software testing that focuses on the user’s experience with the application. It’s usually performed by manually executing the application to determine whether or not it meets the functional requirements.

Functional testing is performed using the functional specification provided by the client and verifies the system against the functional requirements. Functional testing is executed first, using manual testing or automation tools.

Business requirements are the inputs to functional testing. Functional testers ensure that products work as intended by verifying that they meet all business requirements as defined in specifications and user stories.

“Functional testing is testing that the software works as it should. Testing that the design and requirement specifications have been met. We test the application from the perspective of the end-user.” ~ Ozan İlhan

Non-functional testing is the process of performing a test against a product, software, or system, for its non-functional requirements.

Non-functional tests are often performed after functional testing and can include things like performance, reliability, scalability, and other non-functional aspects of the system. It can give insights into how well the product works. Using the right tools will be effective for this testing.

Performance parameters like speed and scalability are goals for non-functional testing. Performance parameters also influence user experience. For example, if a website takes 1 min to load then users might not find it acceptable and leave it immediately or they might wait for a while before leaving only to find out that their site was down because of heavy traffic or something else but they had no way to know that until they tried to use it. This type of information is important for designers so they know what kind of performance they need in their products.

“Non-Functional testing is concerned with the non-functional requirements and is designed specifically to evaluate the readiness of a system according to the various criteria which are not covered by functional testing.”~ Ozan İlhan

Testing Type

Examples of Functional testing are

  • Unit Testing
  • Smoke Testing
  • Sanity Testing
  • Integration Testing
  • White box testing
  • Black Box testing
  • User Acceptance testing
  • Regression Testing

Examples of Non-functional testing are

  • Performance Testing
  • Load Testing
  • Volume Testing
  • Stress Testing
  • Security Testing
  • Installation Testing
  • Penetration Testing
  • Compatibility Testing
  • Migration Testing

Conclusion

Even though both types of testing serve different purposes, it can be said that both types of testing are complementing each other and can be integral parts of the whole software testing activities. Functional testing focuses the testing on the functional requirement of the software. Meanwhile, non-functional testing focuses on the different requirements of the software like performance, reliability, scalability, and other non-functional aspects of the system.

Connect with me

Krisnawan: Twitter | Linkedin | Medium

MydoQA: Twitter | Blog | Instagram | Facebook

Image of city in a background, with word "secure" and lock

 


Testing is a challenging task that requires practice and experience to do well. It is also an activity that some people seem to be better at than others — some people just seem to have a “tester mindset”.

For effective testing to be successful, you must approach it with a mindset that is focused on proving that software doesn’t work. This means thinking like a tester and acting like one in your day-to-day work. A tester is someone who believes that software can fail and should therefore be tested as often as possible.

What are the mindsets that testers must have?

For this sole purpose, I want to introduce the SECURE framework. SECURE stand for SKEPTIC, EXPLORATIVE, CURIOUS, URGE TO BREAK THINGS, RISK ORIENTED, and EMPATHY.

If you are interested in my other writing about software tester skill, you could read 10 Must-Have Skills for Software Testers or Soft skill for Testers: Keys to Effective Communication.

Do you know that we have a different mindset and approach to the work we are doing as testers?

As a tester, you have to understand the difference between a developer’s mindset and yours. Developers are more focused on writing code while testers are more focused on testing the code.

When we test software, we want to make sure it works as expected and meets customer requirements. We check that all functionalities are working correctly before delivering them to customers or stakeholders who will use them in real-world scenarios.

SECURE framework.

You may not have heard of the SECURE framework. that is a new framework that I propose from a summary of several mindsets that a software tester must have. It is a model that describes the mindset of a tester, and it’s something that I think every software tester should know about.

The SECURE framework consists of four characteristics: SKEPTIC, EXPLORATIVE, CURIOUS, URGE TO BREAK THINGS, RISK ORIENTED, and EMPATHY. These traits are not unique to testers but they are particularly important in testers because they help us when we are trying to find bugs in our products or services (or at least this is how I see it).

Being skeptical of all things, programs, processes, services, services integration, etc.

The first step to becoming a secure software tester is to develop a skeptical mindset. Always assume that the bug exists somewhere in the corner of the codes and question everything you see, hear, and do.

“Anything that can go wrong will go wrong.”

This means that we should be always looking at things from different perspectives, questioning our assumptions, being skeptical of things we do not understand, and thinking of ways in which the software may break or fail unexpectedly.

An explorative nature and instinct which prompts us to try out things to see how they behave

Exploration is the key to creativity, problem-solving, and curiosity. Exploratory is all about asking questions, trying things out, and seeing what happens. It’s about being curious about your software and its behavior so you can find new bugs.

The best way to understand the mindset of an exploratory tester is by looking at their actions:

  • Ask lots of questions about the product we’re testing (what does it do? What are its features? How does it work?).
  • Play around with it until we know enough about its behavior so that we can start using deductive reasoning skills to find bugs (what might happen if I do this?).

Curious and questioning mind in general, including other how things work or ways of doing things

You should be curious about the software and how it works. You should be curious about how the service interacts with another service, whether that’s through an API or a user interface.

You should also be curious about why the software works the way it does, and if there are any limitations or assumptions made by developers that could lead to problems later on in development.

Finally, you need to think critically about what could happen if your assumptions are wrong: what would happen if users didn’t like this feature? How would we handle X scenario?

Having the urge to break or do things unconventionally which is also born out of curiosity

In a sense, you’re like a little kid who wants to see what happens if he pulls the plug off his TV or pokes it with a fork. You want to know how far you can go with your testing and whether you can break something.

The urge to break things is also born out of curiosity: “What will happen if I do this?” In other words, it’s an expression of our desire for understanding by trying different things until we have an answer.

Risk-oriented behavior is where we tend to think about the risks

We’re risk-oriented people. You think about the risks and try to minimize them, which is a good thing because it helps find bugs early in the development cycle.

But this can also lead to some problems: you may find yourself focusing too much on how things could go wrong instead of focusing on finding ways for them to go right!

When we focus too much on what might go wrong, it can lead us down rabbit holes that distract us from our actual goal —assure that our software is good enough before they get into the production environment.

Empathy for the users of the systems we develop

Empathy for the users of the systems we develop is an important part of our job. It helps us understand their needs and wants, which can help make our products better.

Empathy is also important because it helps testers understand their business context better, which means they can give feedback on what’s needed by the business in terms of testing services or tools. This can be especially valuable when working with new projects or teams where there isn’t much knowledge yet about how things work (or don’t).


SECURE may be not the best framework or even the best way to represent the software tester mindset. But in my opinion, it summarizes my experience of how I think as a software tester.

Conclusion

When you think about it, SECURE is about always Skeptical bugs exist and living in the corner of the codes. Explore the software to find those bugs. Be curious about everything. Find how to break things in as creative ways as possible. Always think about the risk in the software, it may during implementing a new framework/library, building new architecture, or implementing new ideas. And think using a user’s hat. What the user wants, how the user will use the end product, and will the product bring benefit to the user?

Connect with me

Krisnawan: Twitter | Linkedin | Medium

MydoQA: Twitter | Blog | Instagram | Facebook

This article is a part of the Cypress Test series. To read another story in this series, please follow the links below:

Cypress Test Series:





In this article, I will show you how to create custom commands in Cypress.
Cypress Custom Commands
Cypress Custom Commands

What are Custom Commands in Cypress?


Cypress custom commands are commands that are described by the user and used to create repeating steps in an automation test. By using custom commands you only need to define the command once and only use one line to call those commands.

Syntax


The syntax for the custom commands in Cypress is as follows:
Cypress.Commands.add(function-name, func)

Cypress.Commands.add(function-name, options, func)

Cypress.Commands.overwrite(function-name, func)


  • function-name is the name of the command you are about to invoke.

  • func is a function that accepts the arguments passed to the command.

  • opts is an optional parameter used to describe the implicit characteristics of a custom command.


How to implement custom commands in Cypress?


For this article’s simulation, I will use a dummy test automation website from zero.webappsecurity.com.

This site is not a real banking site and any similarities to third-party products and/or Web sites are purely coincidental. To access the website, you can click the link below.

http://zero.webappsecurity.com/index.html

Suppose our application has a scenario where we need to log in to a website before we can do the real test within the user page. In doing so, we need to clear cookies and local storage. Then insert the username and password into the user_login and user_password fields. After that click remember_me and Sign in button

So, instead of invoking the get() and click() commands before every test scenario, we can add a new custom command which will execute the login procedure every time it is called. So, to achieve the result, we can declare a new custom command as follows. The script below is the implementation of a custom command in commands.js
Cypress.Commands.add(‘login’, (username, password) => {
cy.clearCookies()
cy.clearLocalStorage()
cy.get(‘#user_login’).type(username)
cy.get(‘#user_password’).type(password)
cy.get(‘#user_remember_me’).click()
cy.contains(‘Sign in’).click()
})

And, now it’s time to invoke the command:
describe(‘Login with Custom Command’, ()=>{
it(‘should execute custom command’, () => {
cy.visit(‘http://zero.webappsecurity.com/login.html');
cy.login(‘username’, ‘password’)
});
})

So, it will call the login command and pass the parameter ‘username’ and ‘password’. Both parameters will be used as input values for the user_login and user_password fields. This way, we can execute login only using one line rather than typing every step in the login procedure.

Run the Cypress, and you will get the result as follows:
Result of custom command execution in Cypress

Custom command result

You can see in the log that the commands in the custom command are being executed.

Software Testing




Software testing is an activity to make sure that the software product meets the expected criteria and to make sure that the software has a minimal defects. Software testing aims to minimize bugs, find a missing requirement, or identify that the software meets acceptance criteria. What activities can be done manually and/or automatically?

Why we need software testing?

We need software testing because bugs in production are either very expensive or dangerous. We can lost our potential customer, sell opportunity, or even cause a disaster. If we can catch the bug earlier than we can fix it sooner before the delivery of the product. Thus the cost will be cheaper.


Software Testing Life Cycle (STLC)

What is STLC?


Software Testing Life Cycle (STLC) is a sequence of systematic and planned activities which are executed during software testing activities. STLC is an important process because it ensure the quality of the software. Different with SDLC, that covers the whole software development process, STLC only covers testing activity.

Software Testing Life Cycle (STLC) has six major steps, which are:

  1. Requirement Analysis
  2. Test Planning
  3. Test Case Development
  4. Test Environment Setup
  5. Test Execution
  6. Test Closure
Each of those step has an entry criteria, activity, deliverable and exit criteria related to it.

Entry criteria are initial conditions that must be met before the test process can be run 

Exit criteria are items that must be completed during the testing process so that testing can be considered complete.

Activity is activities that are carried out during the testing process.

Deliverable is the result that can delivered after the test is finished.

To read more about STLC please follow the link bellow.

 

6 Major Steps of Software Testing Life Cycle (STLC)


Testing levels

  • Unit testing
  • Integration testing
  • System testing
  • Acceptance testing

Testing types, techniques and tactics


  • Acceptance testing: Make sure that all services is working as intended.
  • Integration testing: Make sure that all components are working together.
  • Unit testing: Checking that function is working in the unit level.
  • Functional testing: Validating the functionality of the services by simulating user behavior or business process. Can be done using black box testing.
  • Performance testing: Checking how the software performs under a ramping up workloads. Can be done using Load testing.
  • Regression testing: Validating that the old menus or services still working after new features are introduced.
  • Stress testing: Testing how much request can be processed before the system is breaking.
  • Usability testing: Validating how well a customer can use a system or web application to complete a task.

White box VS Black box


White-box testing (also known as clear box testing, glass box testing, transparent box testing, and structural testing) verifies the internal structures or workings of a program, as opposed to the functionality exposed to the end-user. In white-box testing, an internal perspective of the system (the source code), as well as programming skills, are used to design test cases. The tester chooses inputs to exercise paths through the code and determine the appropriate outputs. While white-box testing can be applied at the unit, integration, and system levels of the software testing process, it is usually done at the unit level. It can test paths within a unit, paths between units during integration, and between subsystems during a system–level test. Though this method of test design can uncover many errors or problems, it might not detect unimplemented parts of the specification or missing requirements.



Black-box testing (also known as functional testing) treats the software as a “black box,” examining functionality without any knowledge of internal implementation, without seeing the source code. The testers are only aware of what the software is supposed to do, not how it does it. Black-box testing methods include: equivalence partitioning, boundary value analysis, all-pairs testing, state transition tables, decision table testing, fuzz testing, model-based testing, use case testing, exploratory testing, and specification-based testing.

Testing Artifact

  • Test Plan
  • Traceability matrix
  • Test case
  • Test script
  • Test suite
  • Test fixture or test data
  • test run

Follow me on

Facebook: https://www.facebook.com/mydoqa/ 

Instagram: https://www.instagram.com/mydoqa/

Twitter: https://twitter.com/MydoQa







This article is a part of the Cypress Test series. To read another story in this series, please follow the links below:

Cypress Test Series:





In this article, I will show you how to create a constant that contains an HTML path in Cypress.
How to Save an HTML Path Into a Constant

Sometimes, when creating tests for the front end, we need to access elements under the long HTML path. It will be troublesome if we need to assert elements under the same long path. The workaround I suggest is to save the path into a constant then we call the constant to assert the element.

To achieve the result, we can implement the script below:
describe('Login with Cypress.$ Function', ()=>{
before(function() {
cy.visit('http://zero.webappsecurity.com/login.html');
})

it('should execute login procedure', () => {

const userLogin = cy.get('#user_login')
const userPassword = cy.get('#user_password')
const userRememberMe = cy.get('#user_remember_me')
const signInButton = cy.contains('Sign in')

userLogin.type("username")
userPassword.type("password")
userRememberMe.click()
signInButton.click()
});
})

That script will save the user_login, user_password, user_remember_me, and Sign in button to a constant, then we can call the constant to create an assertion.
End to end testing using cypress: fixtures
Cypress Fixture

In this article, I will show you how to separate test data from the test script. While designing a Test Automation Framework, it is important to segregate the test scripts from the test data. With help of fixtures, Cypress is capable to do that.

What is a fixture in Cypress?


Cypress fixtures are used to store test data for automation, and the fixtures folder is placed inside the Cypress project. The fixtures folder contains JSON files, which contain test data that can be read by multiple tests. We store this data in a key-value format, which allows us to access it in our test scripts.

How to use Fixtures in Cypress Tests?


For this article’s simulation, I will use a dummy test automation website from zero.webappsecurity.com.

This site is published by Micro Focus Fortify for the sole purpose of demonstrating the functionality and effectiveness of Micro Focus Fortify’s WebInspect products in detecting and reporting Web application vulnerabilities.

This site is not a real banking site and any similarities to third-party products and/or Web sites are purely coincidental. To access the website, you can click the link below.

[embed]http://zero.webappsecurity.com/index.html[/embed]

Write the test data


The test data is stored in the fixtures folder:
Fixtures folder in cypress hierarchy

Fixtures folder in cypress hierarchy

Within the folder, create a file in JSON or other formats, and the data is maintained in “key:value” pairs. For this login simulation, I will create JSON and name it user.json. We can specify our test data with the following values:
{
“username”: “invalid_username”,
“password”: “invalid_password”
}

The implementation automation testing in Cypress is as follows:
describe(‘Login with Fixture Data’, ()=>{
it(‘should try to login’, () =>{
cy.visit(‘http://zero.webappsecurity.com/login.html')

cy.fixture(‘user’).then(user => {
const username = user.username
const password = user. password

            cy.get(‘#user_login’).type(username)
cy.get(‘#user_password’).type(password)

            cy.contains(‘Sign in’).click()
})
})
})

As we can see, I use cy.fixture to call the data from the fixture file “user.json” and use the values obtained to fill in the username and password fields. Save the above test files as and run the test as per the steps mentioned in the article “Cypress Test: Create your first End-to-End Testing”.

Loop a dynamic test data


In this section, I will show you, how the fixture file is consist of an array and want to use all the data as test data. I will create JSON and name it userDynamic.json with the following values:
{
“data”: [
{
“username”: “username1”,
“password”: “password1”
},
{
“username”: “username2”,
“password”: “password2”
}
]
}

The implementation automation testing in Cypress is as follows:
describe(‘Login with Fixture Data’, ()=>{
it(‘should try to login’, () =>{
cy.visit(‘http://zero.webappsecurity.com/login.html')

cy.fixture(‘userDynamic’)
.its('data')
.then(user => {
user.forEach((user) => {
const username = user.username
const password = user. password

                cy.get(‘#user_login’).type(username)
cy.get(‘#user_password’).type(password)

                cy.contains(‘Sign in’).click()
})
})
})
})

Save the above test files as and run the test. It will iterate array data from dataDynamic.json and use the values obtained to fill in the username and password fields.

Conclusion


The fixture provides segregation between test data and test script and allows the uses external data to be used in the test. It also allows the test to use multiple input data.

Follow me on


Facebook: https://www.facebook.com/mydoqa/

Instagram: https://www.instagram.com/mydoqa/

Twitter: https://twitter.com/MydoQa

This article is a part of the Cypress Test series. To read another story, please follow the links below:

Cypress Test Series:

API Test Series:

Software Testing Series:

Resources


[embed]http://zero.webappsecurity.com/index.html[/embed]

[embed]http://zero.webappsecurity.com/index.html[/embed]
The viewport is used to control the size and orientation of the screen for your application.
How to Emulate Different Devices Using Viewport
Emulate Different Devices Using Viewport

This is an example of how to use a viewport to emulate different device’s screens:
describe('Device Tests', () => {
it('1080p', () => {
cy.viewport(1980, 1080);
cy.visit('https://books.toscrape.com/')
cy.wait(3000);
});

it('iPhone X', () => {
cy.viewport('iphone-x');
cy.visit('https://books.toscrape.com/')
cy.wait(3000);
});
})

As we can see together, I use cy.viewport to declare the size of the screen. In addition to using the size of the resolution, the viewport can also be defined using the type of device.

Save the above test files as and run the test as per the steps mentioned in the article “Cypress Test: Create your first End to End Testing”.

Now, you can see, Cypress will open the site using two different devices screen.
The figure below is a screen for desktop

Cypress viewport screen for desktop

Screen for desktop

The figure below is a screen for iPhone X

Cypress viewport Screen for iPhone X

Screen for iPhone X

Conclusion


Using the viewport, we can simulate testing using various screen sizes

Follow me on


Facebook: https://www.facebook.com/mydoqa/

Instagram: https://www.instagram.com/mydoqa/

Twitter: https://twitter.com/MydoQa

This article is a part of the Cypress Test series. To read another story, please follow the links below:

Cypress Test Series:

API Test Series:

Software Testing Series:

This article is a continuation of the QA technique series. To read previous articles in the same series, you are welcome to follow the link below.





QA Techniques: Black Box Testing





If in the previous article I wrote about black box testing, in this article I will write about white box testing,





White box testing




What is White Box Testing?






White box testing is a software testing method that takes advantage of an internal view of the software code.






It is called a ‘white box’ because you can see inside an application’s source code and observe the way it is put together. With white box testing, test data enters the system via parameters, variables, and stored procedures and exits through return codes and stored procedures. This allows you to follow logic paths through the system as well as error-handling paths.





White Box Testing Techniques





White box testing is a technique that allows you to test your code at the source level. This means that you can test every line of code in a module or class. It also means that you can test the relationships between different modules and classes.





White box testing techniques include statement coverage, branch coverage, condition coverage, basis path testing, graph notation, Cyclomatic Complexity, and loop testing.





Statement coverage





Statement Coverage is the most basic and fundamental test coverage technique.






It focuses on testing all individual statements in a program at least once. Thus every node in the flowchart is tested.






Although this may seem trivial, it helps to achieve 100% statement test coverage. Because of this, it’s often considered a minimum requirement for any level of testing.





Branch Coverage





Branch Coverage ensures that the test for every possible path (if-else and loops) has been executed at least once by running all combinations of boolean expressions.






The idea behind branch coverage is that each decision condition should be tested with both true and false values; covering these branches is an important step toward achieving full branch coverage.






Branch coverage may also be referred to as condition-decision coverage or decision-branch coverage.





Condition Coverage






Condition Coverage ensures that every conditional statement has been evaluated at least once by running through all possible combinations of boolean expressions.






For example, there are conditions; X<0 and Y>0. Then we’ll have 4 possible conditions; TRUE and TRUE, TRUE and FALSE, FALSE and TRUE, and FALSE and FALSE.





Basis Path Testing






Basis path testing is a method that allows test case designers to make measurements of the logical complexity of the procedural design and use these measurements as a guide for defining the basis set of execution paths.






Test cases created to test the basis set are guaranteed to execute every statement in the program at least once during testing





Flow graph notation






This technique uses a directed graph to identify all possible paths and then maps those paths to create tests for them.






The graph is consist of nodes, decision nodes, junction nodes, and edges, and each node represents a sequence or decision point.





Cyclomatic Complexity






Cyclomatic complexity is used to determine the number of paths that need to be searched.






Cyclomatic complexity is a software metric that provides a quantitative measure of the logical complexity of a program. The value calculated for cyclomatic complexity determines the number of independent paths in the base set of a program and provides the minimum number of tests that must be performed to ensure that all statements have been executed at least once.





Loop testing





This test is mandatory to test various loops in the program, such as do-while, for, and while. In this test, you can also check the condition of the loop, whether it is running correctly or not.










Advantages of White Box Testing






  1. White box testing is very thorough so it can increase accuracy in implementing software.




  2. Makes it easy to find errors or bugs in software that were not previously seen.




  3. Can be executed early so that it can detect bugs early.




  4. Facilitates testing because it is carried out thoroughly so as to minimize the possibility of errors in the code.





Disadvantages of White Box Testing






  1. Quite complex.




  2. Hard to maintain, because if there is any changes in the code, we need to rewrite the testcase.




  3. Consumes a lot of resources because White-box testing is a fairly expensive test.




  4. Expensive.





Conclusion





So, we already talk about White Box Testing, as a part of the Testing Technique series. We already talk about the definition of white-box testing, the technique of white-box testing, also the advantages and disadvantages of white-box testing.





I hope we can learn something new every day.





Don’t forget to follow my other social media





Facebook: https://www.facebook.com/mydoqa/





Instagram: https://www.instagram.com/mydoqa/





Twitter: https://twitter.com/MydoQa





https://www.youtube.com/@mydoqa





Resources





[embed]https://k-hartanto.medium.com/qa-techniques-black-box-testing-637afc122e10[/embed]



[embed]https://k-hartanto.medium.com/qa-techniques-black-box-testing-637afc122e10[/embed]



[embed]https://k-hartanto.medium.com/qa-techniques-black-box-testing-637afc122e10[/embed]



[embed]https://k-hartanto.medium.com/qa-techniques-black-box-testing-637afc122e10[/embed]



[embed]https://k-hartanto.medium.com/qa-techniques-black-box-testing-637afc122e10[/embed]
Find this blog interesting? Follow us