:::: MENU ::::

Software testing enthusiast.

Can ChatGPT Replace Software Tester?

,

 

ChatGPT

I am very curious whether chatGPT can help in software testing or even replace the role of a software tester. So today I checked to see if chatGPT can replace QA in software testing. The target under test is http://zero.webappsecurity.com/login.html. The figure below is the front page.

Front page of http://zero.webappsecurity.com

What is ChatGPT?

ChatGPT is a variation of the GPT (Generative Pre-training Transformer) language model developed by OpenAI. It is pre-trained on a large dataset of conversational text and can be fine-tuned for a variety of natural language understanding tasks such as dialogue systems and question answering.

How do I generate test scenarios and what is the result

In this fun experiment, I will make chatGPT to create a test scenario by writing a few sentences at the prompt.

Create a test scenario for the website’s front page

For the first experiment, I’ll have chatGPT create a test scenario for the target website. The prompt I’m using is “generate test case scenario for this site http://zero.webappsecurity.com/". And the result is shown in the attached image.

ChatGPT Result for a positive scenario

The result is quite good actually. It can write a test scenario systematically. The scenario is pretty basic. It only covers seen elements from a website. Even it creates a fictional flow. For example, clicking the “Online Banking” link will not redirect the user to the login page. But it can be a good start to understanding test scenarios and helping software testers write test scenarios.

Because the first experiment only results in a positive scenario, now for the second experiment, I’ll have chatGPT create a negative test scenario. The prompt I’m using is “generate negative case scenario for website http://zero.webappsecurity.com/". And the result is shown in the attached image.

ChatGPT Result for a negative scenario

The results are not quite different from the first result. But it was too focused on logging in.

 

Create a test scenario for the login page

For the third experiment, I will do something different. This time I’ll have chatGPT create a test scenario for the login page.

Zero bank login page

The prompt I’m using is “generate test case scenario for http://zero.webappsecurity.com/login.html".

Test scenario result for login page

ChatGPT is quite complete in making Test Scenarios. However, there are a few things to note:

  1. The scenario that is made is still limited to what appears on the screen. Not yet accommodate invisible flows, such as; failing to log in many times, logging in with saved cache, successfully login in then clicking the back button, etc.
  2. Create its fictitious pages. There is no “account summary page” page, let alone the contents of “account balance” and “transaction history”.
  3. The “Sign Up” button also doesn’t exist, let alone the “Sign Up page”.

Create a test scenario in cucumber

Then I have it to create a test scenario in cucumber.

Test scenario result for cucumber

Again, the result is very basic, even though it gives a disclaimer about it. But it can serve as a good template for testers to create test scenarios in cucumber.

Create a test script in Cypress

For the next experiment, I go further by having it create a cypress script.

Cypress script result

I even try to produce the cypress script using a different prompt, and here is the result.

Cypress script another result

From the result, we’ll know that chatGPT only produce an example script and didn’t get the actual element. It needs a lot of tweaking for the script to work properly.

Then BOOM!!! It can’t handle it anymore.

error

So, I guess this is the end of my experiment. I already have a lot of fun doing it, and maybe will do it again in the future.

How to use AI to make an article

Copy AI

 

 

Conclusion

ChatGPT can create good, systematic test scenarios. Although the scenario is pretty basic and only covers seen elements, it can serve as a good start to creating the actual scenarios.

It needs a lot of adjustment to actually work properly with our software.

It can’t do the essential work of a software tester, which is to run the test.

Connect with me

Krisnawan: Twitter | Linkedin | Medium

MydoQA: Twitter | Blog | Instagram | Facebook

Software Testing Process

, ,

 

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

Functional vs Non-Functional Testing

,

 

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

SECURE: Mindset Framework for Software Tester

, ,

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

Cypress Test: How to Create Custom Commands

, , , ,
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.

What is Software Testing?

, , , , , ,

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







Cypress Test: How to Save an HTML Path Into a Constant

, , , ,
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.

Cypress Test: How to Separate Test Data Using Fixture

, , , ,
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]

Cypress Test: How to Use Viewport

, , , ,
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:

QA Techniques: White Box Testing

, , , ,

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]

Software Testing Approaches

, ,

Photo by Christina @ wocintechchat.com on Unsplash

Introduction


In this article, we’re going to talk about different approaches to testing. We’ll also talk about how to consider the best approach before diving into any particular approach.



Two techniques


A test approach has two techniques: proactive and reactive. Proactive help identifies and fixes errors early, while reactive is only used when products have already been developed.

List of Test Approaches




Software Testing Approaches instagram.com/mydoqa/

Analytical approach


The analytical approach is commonly used in software development projects. It focuses on the most critical functionality and uses some formal and informal analytical techniques.

The main advantage of this approach is that it allows you to focus testing on the most important parts of your system, which reduces risk.

This type of testing methodology focuses on the specified requirements instead of focusing on what users need or want from a product or service.

Model-based approach


The Model-based approach generate or uses statistical model for defining system behavior.

When designing or selecting a formal or informal model for critical system behavior (e.,g., response time), this information will be used during the requirements and design stages of the project

Methodical approach


A methodical approach is a step-by-step approach to testing. It has a pre planned, systematized approach, assembled from various concepts. It is a formal way of testing and it has been used in many industries like software development, product development, etc.

A thorough understanding of this methodology will help you achieve better results and improve your quality assurance processes

Process or standard-compliant approach


The process- or standard-compliant approach is the most common in software testing. It involves testing against a particularly known standard, such as an IEEE 829 standard for embedded systems.

Software testing standards are usually created by industry bodies such as ISO and IEEE, which aim to ensure consistency across countries by defining what should be done within their scope of work.

The benefits of using these standards include:

  • Consistency — everyone knows what they should do and how they should do it

  • Uniformity — there’s no need to reinvent the wheel each time you start working on something new


Dynamic and heuristic testing approach


This approach concentrates on finding as many defects as possible during test execution, it also adapts to the realities of the system under test as it is when delivered. Such an approach usually involves exploratory testing, where a tester tries out various variations of input data, such as user actions or configurations (the latter can be done using simulation). The goal here is not only to find all bugs but also to understand how these bugs can be fixed and where they might occur in future releases. In addition, this method allows for the execution of independent evaluation tasks such as planning tests for new features or fixing known issues before deployment

Consultative approach


A consultative approach is a type of test strategy in which the software tester acts as a consultant to the software development team. The two parties communicate with each other and work together on finding defects, fixing them, and testing new functionality.

This type of collaboration can be beneficial for both parties involved because it allows developers to make changes without having any fear about breaking things for testers, who might need time to come up with ways around these obstacles.

Regression-averse testing approach


Regression testing is the process of re-testing a previously tested program after a software change to ensure that it continues to function as expected. It can be performed on any new build of the software, or any modified portion of the software.

Regression testing involves automating the functional test before its release to detect defects in newly added features and functionalities (e.g., new UI elements). In this case, regression testing requires early testing because it takes longer than manual regression tests which have been implemented earlier in the development life cycle

Selecting the best approaches/ strategy


The selection of the right approach or strategy will depend on the nature of your product, as well as the nature of your team. You should consider every aspect of your project, including:

  • Risks involved with making a product or risk of failure

  • Expertise and experience of your people in the proposed tools and techniques

  • Regulatory and legal aspects such as external and internal regulations of the development process

  • The nature of the product and its domain


Conclusion


Software testing is a highly specialized and technical field. There are many ways to test software, but some of them are described here.

Connect with me

Krisnawan: Twitter | Linkedin | Medium

MydoQA: Twitter | Blog | Instagram | Facebook

Resources


[embed]https://www.tutorialspoint.com/software_testing_dictionary/test_approach.htm[/embed]

[embed]https://www.tutorialspoint.com/software_testing_dictionary/test_approach.htm[/embed]

https://www.tutorialspoint.com/software_testing_dictionary/test_approach.htm
Find this blog interesting? Follow us

About Me

My photo
Hello, I'm a professional software quality assurance and I like to share my enthusiasm.