:::: MENU ::::

Software testing enthusiast.
Showing posts with label mydoqa. Show all posts
Showing posts with label mydoqa. Show all posts

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

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

QA Techniques: Black Box Testing

, , , ,

Now you can also read about White Box Testing from the link below:

[embed]https://k-hartanto.medium.com/qa-techniques-white-box-testing-fecf9779b374[/embed]

Quality assurance is used to test software, when executing testing, we need to use a technique, so our testing can be done with minimum cost. In this article, I’ll talk about black box testing as a way to evaluate the quality of an application.

Black box testing
Black box testing

What is Black box testing?

Black box testing definition is a type of software testing in which the functionality of the software is not known. The testing is done without the internal knowledge of the products and their internal structures, so it’s frequently called “black” box testing.

Black box testers focus on finding defects that lie within their black-boxed system rather than trying to figure out how they work from an internal perspective.

They usually verify whether user interfaces do what they’re supposed to do by looking at input/output data provided by users or automated tests running against them.

Why do we need Black box testing?

Black box testing is a type of software testing in which the software’s functionality is unknown. The testing is done without internal knowledge of the products and their user interface.

Black box test cases help you provide maximum coverage with minimum test cases because they don’t have any external dependencies like user interaction or other factors that can affect your test results.

Black box testing techniques

Equivalence Partitioning

Equivalence Partitioning
Photo by Will Francis on Unsplash

Equivalence class partitioning is a black box testing technique that divides the input domain of the software under test into several equivalence classes.

For example — “userId” field is consist of 32 alphanumeric characters. So, we divide the input into; > 32 digits (invalid), =3 2 digits (valid), < 32 digits (invalid).

Boundary Value Analysis

Photo by Kevin Butz on Unsplash

The boundary value analysis focuses on detecting and correcting boundary conditions in cases where unexpected results occur because of these variables’ values.

For example — To enroll in classes, the valid student “age” range should be between 15–25. Then the test will be; 15 and 25 for the valid range, and 14 and 26 for the invalid range.

Decision Table Testing

decision
Photo by Alex Gorin on Unsplash

Decision tables are a great way to test the functionality of your application. They allow you to create complex business rules, document them, and apply them at runtime.

We use decision tables when we need to execute complex business rules. The input combinations and corresponding outputs are listed in a table, creating test cases.

For example — below is a simple decision table. It shows the eligibility of students to enroll a class in this semester. Students are eligible to register if their age is within range, pay an admission fee, admitted to this semester, and not being suspended.

╔══════════════╦═══════════════╦═══════════════╦═══════════════╗
║   condition  ║ combination 1 ║ combination 2 ║ combinations 3║
╠══════════════╬═══════════════╬═══════════════╣═══════════════╣
║ age          ║      Y        ║      Y        ║      Y        ║
║ admission fee║      Y        ║      Y        ║      Y        ║
║ admitted     ║      Y        ║      Y        ║      N        ║
║ suspended    ║      Y        ║      N        ║      N        ║
╚══════════════╩═══════════════╩═══════════════╩═══════════════╝

State Transition Testing

state transition
Photo by Damon Hall on Unsplash

State Transition Testing is a black box testing technique that is used to validate the functionality of the software against state changes. This can be done by writing tests using specific values twice.

State Transition Testing helps you to identify the possible transition for your application during runtime.

For example — You simulate a student that enrolls in a class using valid values, then enrolls in the very same class again using the same values. The first enrollment will succeed. Meanwhile, the second enrollment will result in a failure.

Use Case Testing

Photo by Brands&People on Unsplash

Use case testing is a black box testing technique that uses use cases to test the functionality of a component or system. The tester without any internal knowledge of the component or system creates use cases and uses them to test the functionality. Use cases are documents that describe an interaction between actors (i.e., users) and/or objects (i.e., components).

Error Guessing

Photo by charlesdeluvio on Unsplash

Error guessing is a technique that helps testers find defects in the system. It’s a simple technique and can be used by testers with little or no programming knowledge.

It involves testing all possible combinations of inputs and outputs, then comparing them to what you expect to see based on your previous experience with the product or service you’re testing.

If there are errors left over after this process, then something has gone wrong somewhere in your system!

Conclusion

We hope that you have learned something from this article. We know that testing can be a difficult field, but it is also one of the most important for your organization. As always, we are here to help you learn more about what we do and how we do it. Please keep in mind that every project is unique and has different requirements so feel free to contact us if you have any questions or concerns!

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

Resources

[embed]https://k-hartanto.medium.com/qa-techniques-white-box-testing-fecf9779b374[/embed][embed]https://k-hartanto.medium.com/qa-techniques-white-box-testing-fecf9779b374[/embed][embed]https://k-hartanto.medium.com/qa-techniques-white-box-testing-fecf9779b374[/embed]

Sekolah dan Matinya Kreatifitas

, ,
Photo by Bayu Syaits on Unsplash

Ada sebuah anekdot

Orang Indonesia dan orang India dengan skill dan keterampilan yang sama bekerja di suatu perusahaan rintisan di amerika.

Photo by Jason Goodman on Unsplash

Suatu ketika saat dilakukan sprint planning, product manager bertanya,

“We’ll deal with a big project, this project will bring our company great fortune, who wants to be the lead engineer?”

Kemudian engineer dari India dengan antusias dan penuh percaya diri mengacungkan tangan sambil setengah berteriak,

Photo by Levi Hernández on Unsplash
“I can do this, give me a chance and I will successfully lead our team.”

Dan tahukah kalian apa yang dilakukan software engineer dari Indonesia? dia duduk di kursi terjauh sambil menggerutu,

“Kalau cuma gitu aja aku juga bisa, tapi aku mending diam saja.”
Photo by Kristina Flour on Unsplash

Pertanyaanya,

Kenapa hanya memilih diam?

Kenapa tidak mengajukan diri?

Kenapa tidak menunjukan bahwa dirinya memiliki skill yang bisa diunggulkan?

Photo by CDC on Unsplash

Tahun ini adalah tahun pertama anak kedua saya masuk Taman kanak-kanak. Dan tahukah apa yang dipelajari di hari-hari pertamanya?

Ya betul!! TEPUK DIAM!!

Begini liriknya

Tepuk Diam
Prok 3X Bila aku
Prok3 X Sudah tepuk
Prok 3X maka aku
Prok 3X harus diam
DIAM
One, two, three, four Yes DIAM
Photo by Jackson Simmer on Unsplash

Apakah memang harus begitu? Apakah untuk memperoleh pendidikan harus ditukar dengan kemampuan mengutarakan sesuatu? Padahal nantinya di masyarakat maupun dunia kerja kita dituntut untuk dapat

SPEAK UP

Anak saya juga memiliki kebiasaan menulis nama dirinya dengan membubuhkan tanda “love” di atas huruf “i” sebagai ganti tanda titik. Menurut saya, itu manis sekali dan sangat kreatif.

Photo by Michael Fenton on Unsplash

Suatu hari saya melihat dia menulis nama dengan titik yang normal. Saya pun terheran dan bertanya. “Biasanya kamu nulis pakai tanda love kok sekarang nggak lagi?”. Dan jawabanya adalah,

“Nggak boleh sama bu guru.”
“Kok bisa?”
“Nggak sopan katanya.”
“Ya itu kan di sekolah, kalau nulis di rumah ya gapapa to.”
“Tetep ga boleh.”
“Kan kalau di rumah boleh sama papah.”
“Kan bu guru yang bener.”

Ini bagaimana konsepnya?

Kenapa hal-hal kreatif dilarang?

Misal tidak boleh berkreasi untuk catatan di buku resmi atau tugas, kan bilang aja

“untuk konteks tugas tidak boleh, tapi kalau untuk kreasi boleh”

Mengapa kreativitas anak dihambat?

Mengapa potensi dibatasi justru oleh orang yang seharusnya mendorong anak menuju potensi terbaiknya?

Bagaimana bisa anak saat dewasa nanti dituntut untuk adding value jika sekedar menambahkan keindahan saja dilarang?

Mengapa hanya kreasi yang diajarkan dari sekolah yang diperbolehkan sedangkan yang muncul dari anak dilarang?

Kenapa model pembelajaran seperti ini masih exist bahkan di tahun 2022? Ketika kurikulum merdeka sedang gencar-gencarnya?

Tidak berhenti di situ saja, pembungkaman juga menanti anak-anak setelah mereka nanti beranjak dewasa. Contohnya: saya merasa ragu-ragu apakah aman menulis seperti ini.

Sebuah catatan dari seorang ayah.

How To Create A Superhero In Super Easy Steps Using Dream By Wombo

, , ,

Using Wombo, I created a high-quality, detail-packed character in less than 5 minutes.

AI-generated art superhero character

Wombo — is a free AI-powered artwork creation platform that has everything you need to quickly design and create a beautiful digital painting. On this occasion, I will use it to show you, how to create your exceptional superhero character in just a few easy steps.

This is the second article of the AI-generated superhero character series. You can read the first article from the link below.

[embed]https://medium.com/data-driven-fiction/mindblowing-ai-generated-art-3-simple-step-to-create-art-using-midjourney-aef880149a66[/embed]

Yes, I’m obsessed with AI-generated art, especially superhero character creation. I always imagine how my children look if they are depicted as superhero characters.

If you are curious about how I make superhero characters just continue reading.

One of the most well-known and capable AI tools for producing art is Dream by WOMBO. Creating art using Dream by WOMBO is super easy just follow these simple steps and you will be a master of art in no time.

Step 1 Go to Dream by WOMBO

Go to Dream by WOMBO website and click the sign-in button. You can also access it using your smartphone. Just search it in Google Play (android user) or App Store (apple user).

Dream by WOMBO front page

Step 2 Create your art

Click the “START CREATING” button and you will be redirected to a create page. Enter the prompt with any description you want. Because I want to create a superhero character then I type in “Robot superhero” and choose “HDR” art style.

In this step, you can type any description you want, from sunset cliff, futuristic city, space cowboy, or anything. Then press the “Create” button.

Dream by WOMBO front page

Step 3 Publish your work

And voila, your character is done.

Give a name to your artwork, you can pick any name you want, and add tags so your artwork can be easily found by others.

As an extra action, you can mint your work as an NFT or/and print it on canvas for several dollars. To be able to mint as NFT directly you need to connect to your crypto wallet.

Click Publish, and now your artwork is created. It can be accessed from your profile page.

Unlike Midjourney which demands money after 25 attempts in creating AI-generated art. WOMBO is completely free, at least until I write this article.

Conclusion

Will AI replace humans in creating digital art?

I don’t think so, just like any art utensil like canvas, brush, or even tablet, AI is just a tool. It helps humans depict their imagination. So

Imagination is the limit

Follow me on

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

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

Twitter: https://twitter.com/MydoQa

[embed]https://medium.com/data-driven-fiction/mindblowing-ai-generated-art-3-simple-step-to-create-art-using-midjourney-aef880149a66[/embed]

AI-Generated Article: Is this the death of creative writing?

, , ,

Disclaimer: This article is created by AI. Not because I’m being lazy and don’t want to make an original story. I am publishing this just to show how fascinated I’m with AI. It can take over every aspect of human creativity.

After this point, it is AI generated article.

Artificial intelligence is a growing technology that has the power to change many aspects of daily life. Many believe this technology can replace human writers, including journalists and creative writers. However, others believe AI cannot replace human writers because it is incapable of writing well. This debate is important because it helps us to understand the effects of artificial intelligence on the literary world. Ultimately, AIs ability to write shows that it can become an essential part of the literary world.

One reason why artificial intelligence can’t replace human writers is that it can’t write about emotional subjects as well as humans can. AI is good at writing about facts and figures, but it isn’t as adept at writing about emotional stories. This means that AI wouldn’t be able to craft the same types of stories that humans can. In some ways, AI can only mimic what humans already do well; it can’t create unique stories that humans haven’t already written. In that sense, AI is less capable of writing than humans are.

Although artificial intelligence can’t replace human writers, it can help create more diverse content. AI is capable of writing in many different genres and formats. For example, AI can write in poetry and dramatic prose just like humans can. It’s also capable of writing in different genres that humans aren’t skilled enough to write in. For example, AI can write in sci-fi, a genre that only humans are capable of writing about. This means that AI is capable of writing about subjects that humans aren’t skilled enough to write about. In this sense, AI can create a more diverse range of content than human writers.

AI also has a more accurate understanding of human emotion than humans do. This means that AI will be better at writing about certain emotions and concepts than humans will be. For example, AI will be better at writing about loss and grief than humans will be because it has more data to work with and has a more accurate understanding of human emotion. In this sense, AI helps create better stories than human writers do.

On the other hand, some people feel uncomfortable with artificial intelligence writing emotional content because they feel it undermines their work. They also feel this undermines their personal relationships with other people they know. These people believe that the emotional content created by AI is less than genuine because they feel it’s not based on reality or they’re being manipulated by the creator. In their eyes, it’s dishonest and lessens their credibility as writers.

Additionally, some believe that humans are still better writers than AI because it can only write about facts and figures. Humans are still better at creating emotional content, so it’s still not good enough to replace human writers in this area. In essence, it would only be able to write about one thing: facts and figures; which would turn out to be very boring for readers!

Overall, although artificial intelligence can’t replace human writers, it can help create more diverse content. It’s capable of writing in many different genres and formats and has a more accurate understanding of human emotion than humans do. The creator would be able to create better stories than humans because it understands human emotion so well. This technology shows us that there is no limit to what AIs creative power could do for literature!

Hello, I’m back

It’s me again

a human

like a real human.

Have you read the above article? fascinating isn’t it? That’s what an AI capable of.

So what do you think? Will AI replace human in every aspect? Even in art and writing? Can it feel any emotions?

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

About Me

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