:::: MENU ::::

Software testing enthusiast.

Showing posts with label Software Testing. Show all posts
Showing posts with label Software Testing. 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

 

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

 

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







Find this blog interesting? Follow us