In this article I am really interested to share something that hype recently, that is: AI GENERATED ART. AI generated art or Artificial intelligence art refers to any artwork created through the use of artificial intelligence.
For this article I will try to create abstract art using python code from Abstract-Art-Generator.
Please follow these 4 Easy Steps:
Step 1
To get the code, you can clone or download from his github and save it in your local machine.
Step 2
Before you run this code, make sure to install all the requirements:
pygame
python -m pip install pygame
pygame_gui
python -m pip install pygame_gui
tkinter
python -m pip install tkinter
Step 3
After all requirements are fulfilled, run the python code using this script:
python art_generator.py
Wait until the UI is prompted.
Abstract art generator
Step 4
You can generate abstract art randomly or custom it with your own preference.
To generate randomly click “Generate Randomly” button.
Let’s try it:
Fig 1
2. Fig 2
3. Fig 3
Or, you can customize it in OPTIONS tab.
Choose color palette
Styling layer one
Styling layer two
Generate
Let’s see the result
and
Voila!!!
It’s so beautiful.
You can also add overlay on top of it.
Don’t be afraid to experiment with other combination of shape and color, and create your ultimate masterpiece.
This article will show how to create basic End to End testing using Cypress.
What is End-to-End (E2E) Testing?
End-to-end testing, often abbreviated as E2E, is a testing technique that tests an entire product or an entire piece of software. This test is carried out from start to finish to ensure the application flow behaves as expected. E2E test can be interpreted in the abstract is to validate the workings of an application or website from the point of view of a user.
Automate End-to-End (E2E) Testing in Cypress
For this article’s simulation I will use dummy test automation website from books.toscrape.com. This site is good enough for practice purpose. It simulates e-commerce site so we can practice as if create automated testing for e-commerce website. To access the website, you can click the link below.
[embed]https://books.toscrape.com/[/embed]
Preparation
I’m assuming, you already installed the prerequisite software. In this tutorial I use:
Windows 11
Visual studio version 1.52.1
Node js v14.16.1
Cypress version 10.9.0
Of course you can use other version, but the details maybe slightly different.
Write the test
Now we are ready to create end to end test in Cypress. First create bookstore.cy.js file under folder “cypress/e2e/3-example”. My project structure is look like this.
Within the file, write the describe() function. Describe() function comes from mocha bundled library as cypress adopt mocha BDD syntax. It provides a way to keep tests easier to read and organized.
describe(‘Browser Actions’, () => {
})
In this test scenario I will divide the test into 3 segments: Visit the page, click a hyperlink, and verify an element.
Step 1: Visit the page and validate the url return
To visit a page, write down the code below within the describe() function.
it() is used for an individual test case. it() takes two arguments, a string naming our test, and a callback function which contains our actual test.
The code above can be broken-down into:
cy.visit(‘https://books.toscrape.com/', { timeout: 10000 }) will open page books.toscrape.com with 10 seconds timeout. cy.url().should(‘include’, ‘toscrape.com’) will verify the returned url should contain string “toscrape.com”.
Step 2: Click a hyperlink and validate the opened page
To visit a page, write down the code below under the previous it() function.
cy.get(‘a’).contains(‘Travel’).click() will inspect “a” html element and click an element that contains “Travel”. cy.get(‘h1’).contains(‘Travel’) will verify that the opened page contains string “Travel” as an h1.
To know where the element is located, we can open our web browser and open the page. After that, find it in inspect element. In this scenario string “Travel” is located in “a” element.
Step 3: Verify an elementin the opened page
In this step I will add another assertion, which is make sure the first book contain correct price. Please write down the code below under the previous it() function.
The code above contain a method that will search an HTML class .product_pod then go down to class .product_price. We add . in front of class name but nothing in front of HTML element. After we get price element, make sure that the value is £45.17.
To know where the price is located exactly, you can find it in inspect element, like above.
After we write down the code, complete code will be looks like this:
It will open Cypress Launchpad. The Launchpad offers two biggest decision first: What type of testing to do. E2E Testing, Which will run the whole application and open pages to test them. Or Component Testing, Which isolate individual component of application and test it.
Cypress Launchpad
Launching a Browser
Lastly, Cypress will presents list of compatible browsers Cypress found on your system.
This time I will use Chrome, we can always change it later.
Run the test
Our test is located under E2E specs/3-example. Click bookstore.cy.js and wait until Cypress open books.toscrape.com.
As we can see right now, all the test is succeed.
All the test cases that I show you above are positive cases. You can also create scenario that covers negative cases.
Software testing is an important activity. It provides certain level of confidence with the product. That level of confidence achieved through a series of testing activities. Software testing activities is a procedures that are executed to catch bugs, errors, defects as early as possible, ensure that the product meets acceptance criteria, and the completeness of specifications in accordance with business, user, and product requirements.
To run that procedures, we need to have a strategy, so our testing activities will not take too long time but still optimum enough to reach the goal.
How can we develop a good strategy? Or Base on what we develop that strategy? One of the rules that have been proven to be used as a basis for building strategy is 7 Principles Of Software Testing.
In this article, we’ll take a look at what is 7 Principles Of Software Testing and its component, one-by-one.
7 Principles Of Software Testing
1. Testing shows presence of defects
Presence of defects
The purpose of software testing is to reduce bugs occurrence in software using various methods and techniques. By doing series of testing procedures, it detect the presence of bugs or defects . Software testing can only ensure that bugs are present, not those that are absent. Even after we execute test endlessly, it is impossible to be sure that the software is completely bugs-free.
2. Exhaustive testing is not possible
Exhaustive testing
It is a practice of testing a software using all possible inputs and preconditions. It is very difficult to test all modules and their functionality with valid and invalid combinations of input data throughout the testing process.
Imagine an input field that accept age information, we need to execute test using 1, 2, 3, 4, 5, and so on. And don’t forget to also test it using invalid value, such as a-z, A-Z. It is a very time consuming procedure and very not cost effective.
3. Early testing
Early testing
Testing should start as early as possible so that any possible defect can be captured in early stage. It is less costly to fix defect in the beginning. But how early it should be performed? Once we get the requirement.
4. Defect clustering
Defect clustering
Defect clustering state that the most bugs will detected in a small number of modules. Usually it follows the Pareto 20/80 law. About 80% bugs will be found in about 20% of modules.
5. Pesticide paradox
Pesticide paradox
Imagine a farmer that are using the same type and doses of pesticide to spray bugs, again and again repetitively, eventually bugs will develop immunity to that kind of pesticide. The same thing happened to software testing. If the same methods and approaches are used repetitively, the method will be useless to catch a new bugs.
To overcome this, the test case needs to be evaluated and replaced periodically. Also, tester need to be more creative and run the test outside the test case.
6. Testing is context dependent
Context dependent
Software testing is not a one-for-all scenarios. It is important to design tests based on the context of software development. Different strategies, methods, and kinds of testing are utilized relying upon the idea of an application. For example, software for the aviation industry requires more detailed, thorough and thorough testing than the company’s website. And e-commerce page will require different test than login form.
7. Absence of errors fallacy
Absence of errors fallacy
Although software is 99% bug-free, it is still possible that the software cannot be used at all. It is still important that the software must be practical and able to accomplish the client’s requirements and needs.
Conclusion
Based on what we have learned together, 7 Principles Of Software Testing can help us gain greater efficiency, focus, and also improve our strategy for designing testing scenario.
One of the tasks of the software tester is to tell bug occurrences to the software developer. A bug is bad news. And just like other bad news, people tend to avoid it. Some people will feel uneasy if they hear that there is bad news in the code.
The wrong communication feedback will bring a wrong response. Of course, we are familiar with defensive responses like, — “It is working on my machine.”, “It must be from another service, go check somewhere else.” , “It didn’t happen when I follow your step to reproduce.”— and something similar. Those reactions could affect the productivity of a company.
As software testers, we don’t want to get a reaction similar to that or even worse, make it. So, what is the better communication approach? How to tell bad news without making any anxiety?
I’m proposing the use of the Situation-Behavior-Impact framework.
What is the Situation-Behavior-Impact framework?
It is a direct, non-judgmental, and widely-recognized model for delivering feedback. Situation-Behavior-Impact or SBI is proven to reduce the anxiety of delivering feedback and also reduce the defensiveness of the recipient.
The Situation-Behavior-Impact method is simple and direct: You capture and clarify the Situation where bugs occur, describe the specific Behaviors observed, and explain the Impact of the behavior of the bug on the software.
How You Can Use Situation-Behavior Impacts to tell bug occurrence?
1. Situation:
Describe the specific situation/environment in which the bug occurred. Avoid generalities, such as “in my browser…, in my machine…” as that can lead to confusion. Often bugs only happen in certain environments so it is good to be as specific as possible. Make sure to list the operating system or browser you are using, and if applicable, which version of software and hardware you are using.
Example: “In Firefox browser version 105.6.1 64 bit…”
2. Behavior:
Describe the actual, observable behavior. Keep to the facts. Avoid using ambiguous terms such as “not working, broken”. Be more specific, write every detail that you can get.
Example: “…When I click the ‘search’ button the browser is not responding.”
But don’t forget to write down the expected behavior.
Example: “…When I click the search button, the item I’m looking for should appear.”
3. Impact:
Describe the results of the behavior. Because you’re describing exactly what happened and explaining the real impact of the bug, a developer will be less likely to feel offended and react positively.
So how to state the impact of bug behavior? You can follow this example.
Example: “…When I click the ‘search’ button the browser is not responding. It causes memory usage to spike sharply.”
The success of the Situation-Behavior-Impact will minimize the negative reaction. If the reaction is positive, then productive cooperation can be continued. And you can resolve the bug along with the software developer rather quickly and with less drama.
Please bear in mind, writing bug reports follows a different format, I will write a format to create bug reports in a different story. This approach is useful to tell bug occurrence in a written form or verbally.
In this article I will show how to create basic request in postman.
Basic Features
Before creating postman request, first let me show you postman basic features. I will show features like
Params — Allows you to add query parameter in request URL
Authorization — It might be basic authentication, bearer token, or just simply username and password
Headers — Where you will write needed header for the request
Body — This is where you put customization values.
Pre-request Script — Executed before running the request. You can add environment variables or test preconditions here.
Tests — This is where you put our assertion script for the test. It is important to add assertion for each request so we know whether the request is succeed or not.
Create Our Request
Now after we know Postman’s basic features, we are ready to create our first postman request. For this article’s simulation I will use demo site from dummyjson. You can access the swagger here:
For this simulation I will use endpoint “Add a new product”. This endpoint will simulate POST request and mock a create new product behavior.
Add a new product simulation
Create a Collection to organize our request — Yes we can create single request without a collection, but a collection will help us to make our request more well organized. We also can group our collection into folders under the same category, such as: Setup, Positive Cases, Negative Cases, and Cleanup.
Collection creation
2. Create request — In this step we will create a request. To create a request within a collection, click triple dot from collection then Add Request. Write down Request name and Request description (Optional). Click “Save to HTTP Method”.
Request creation
3. After request is created then we are ready to make a postman request.
In the body tab click raw as body type and JSON as the format. Then write
{ “titles”: “BMW Pencil” }
Request body
4. Click “Send” button — After this step is executed we already get the result whether fail or success. In this simulation the request return 200 as response code and “id”: 101 as response body.
Request response
5. Test Assertion — now, after we get the response code and response body, we need to assert the test to assure endpoint returned expected response.
To add assertion, click “Tests” tab
For this simulation, create an assertion using snippets is enough. So move to snippets and choose on of them.
Test Snippets
I will assert this request using two snippets, ”Status code is 200" and “Response body: JSON value check”.
Click those snippets. Now we will have two code blocks. The first block is good enough, so we will work on the second block. String “Your test name” can be changed into any string you desire, so I will change it into “Product id is 101”. Because returned Json key is “id” and the value is 101, so we will change “pm.expect(jsonData.value).to.eql(100);” into “pm.expect(jsonData.id).to.eql(101);”
I think it is good enough now. Click “Send” button again.
In the response click “Test Results” and we will get two results ”Status code is 200" and “Product id is 101”. And both of them are PASS. Those results are from previous test block.
That’s how we create basic API test using Postman. This test is simulating positive scenario. Maybe I will write about how to create negative scenario in the next article.
In this tutorial I will share how to assert jwt token in the response body. To simulate API behavior, I will use dummy API server from dummyjson.com. You can access the website using the link below:
[embed]https://dummyjson.com/docs/auth[/embed]
In this simulation, I will use endpoint “Login user and get token”. This endpoint is using POST method. For how to test http method using postman you can follow the instruction from the article below:
[embed]https://dummyjson.com/docs/auth[/embed]
The figure below is the response body for “Login and get token” endpoint. We want to assert the jwt content from “token” field.
Login and get token response body
To do that we can use atob(). To use it you can write down the following script in the “Tests” tab.
After we hit send button, postman will return log that contains the jwt content. Then we can assert tho content values.
Postman log
To assert jwt token we can add following test script:
pm.test(“Jwt should include username”, function () { pm.expect(parsed).to.include(“\”username\”:\”kminchelle\””) });
We can assert another field by adding pm.expect script within the pm.test block, for example jwt token should contain field “firstname” with value “Jeanne“. We can add test script as following:
pm.test(“Jwt should include username”, function () { pm.expect(parsed).to.include(“\”username\”:\”kminchelle\””) pm.expect(parsed).to.include(“\”firstName\”:\”Jeanne\””) });
In this tutorial I will show you what HTTP methods are and how to test them. The methods used in this article are: POST, PUT, GET, DELETE.
POST is used to send data to a server to create a resource.
PUT is used to send data to a server to update a resource.
GET is used to fetch data from a specified resource.
DELETE method deletes the specified resource.
Dummy API
This article is using dummy API server provided by DummyJSON.
[embed]https://dummyjson.com/docs[/embed]
API Request
POST
This method will send data to the resource and create a new product called “BMW Pencil”. To do that in Postman, just create new request, ensure the method is POST, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/add”. In the Body tab, choose “raw” button and choose JSON, and then type:
{ "title": "BMW Pencil" }
POST Request
Request
To make request using Curl you can see the following code. Just import the curl to Postman.
After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.
{ "id": 101, "title": "BMW Pencil" }
PUT
This method will send data to the resource and update a product “1” and change the title into new value “iPhone Galaxy +1”. To do that in Postman, just create new request, ensure the method is PUT, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/1”. In the Body tab, choose “raw” button and choose JSON, and then type:
{ “title”: “iPhone Galaxy +1” }
PUT Request
Request
To make request using Curl you can see the following code. Just import the curl to Postman.
After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.
{ “id”: “1”, “title”: “iPhone Galaxy +1”, “price”: 549, “stock”: 94, “rating”: 4.69, “images”: [ “https://dummyjson.com/image/i/products/1/1.jpg", “https://dummyjson.com/image/i/products/1/2.jpg", “https://dummyjson.com/image/i/products/1/3.jpg", “https://dummyjson.com/image/i/products/1/4.jpg", “https://dummyjson.com/image/i/products/1/thumbnail.jpg" ], “thumbnail”: “https://dummyjson.com/image/i/products/1/thumbnail.jpg", “description”: “An apple mobile which is nothing like apple”, “brand”: “Apple”, “category”: “smartphones” }
GET
This method will fetch phone data from the resource. To do that in Postman, just create new request, ensure the method is GET, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/search?q=phone”.
GET Request
Request
To make request using Curl you can see the following code. Just import the curl to Postman.
curl --location --request GET 'https://dummyjson.com/products/search?q=phone'
Response
After all necessary parameter is fulfilled, click “Send” button, then we’ll get following response body.
This method will DELETE data with product id “1” from the resource. To do that in Postman, just create new request, ensure the method is DELETE, Insert the URL of the endpoint. In this simulation, the URL is “https://dummyjson.com/products/1”.
DELETE Request
Request
To make request using Curl you can see the following code. Just import the curl to Postman.
Software Testing Life Cycle In this article I will write about Software Testing Life Cycle or STLC model.
What is it?
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:
Requirement Analysis
Test Planning
Test Case Development
Test Environment Setup
Test Execution
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.
STLC Phases
Requirement Analysis: Requirement Analysis is the very first step in Software Testing Life Cycle (STLC). At this stage, the quality assurance (QA) team understands the requirements, like acceptance criteria or what to test. If something is missing or unclear, the quality assurance team meets with stakeholders to gain a better understanding of the requirements in detail. QA can decide whether software require manual or automation testing.
Activity: Identify types of tests to be performed, Gather details about testing priorities and focus, Automation feasibility analysis (if required).
Deliverable: List of all testable requirements, Automation feasibility report (if applicable).
Exit Criteria: Signed off RTM, Signed off Automation feasibility report.
Test Planning: Test planning is the stage where QA manager/QA lead define testing strategy and make an estimation on effort and cost needed for the entire life cycle.
The team will decide on the required tools, roles, and training (if needed) for the project, etc.
Entry Criteria: Requirements Documents.
Activity: Preparation of test plan/strategy document for various types of testing, Test tool selection, Test effort estimation, Resource planning and determining roles and responsibilities, Training requirement.
Deliverable: Test Strategy, Test Plan, and Test Effort estimation document.
Exit Criteria: Approved Test plan document, Approved Test strategy document, Signed off effort estimation document.
Test Case Development: The test case development phase is started soon after the test planning phase is finished. In this phase, QA Team will create a test case. They also identify, create, review, and rework Test data based on the preconditions. If the test require automation test, QA team also create test scripts for the automation test.
Entry Criteria: Requirements Documents (Updated version of unclear or missing requirement).
Activity: Create test cases, automation scripts (if applicable), Review and baseline test cases and scripts, Create test data.
Deliverable: Test cases, Test Scripts (if automation), Test data.
Exit Criteria: Reviewed and approved test cases, test scripts, test data.
Test Environment Setup: Test environment setup is the critical part of the STLC. This phase aims to ensure readiness of the environment on which software is tested. QA team is responsible for the testing environment, sometime they work together with Dev team, SysOps or DevOps team. To check the readiness, QA team can use smoke test.
Entry Criteria: Test Plan, Smoke Test cases, Test Data.
Activity: Understand and prepare the required environment set-up, Perform smoke test on the build.
Deliverable: Test Environment. Smoke Test Results.
Exit Criteria: Working test environment setup, Valid test data setup, Successful smoke test.
Test Execution: After all those preparation, the QA team finally do the actual test. In this phase QA team start executing test cases based on test cases and test plans from the earlier phases.
Entry Criteria: Test Plan document, Test cases, Test data, Test Environment.
Activity: Execute tests as per plan, Document test results, and log defects for failed cases, Track the defects to closure.
Deliverable: Test case execution report, Defect report.
Exit Criteria: Execute all planned test cases, Log all defects found.
Test Closure: This is the end of the life cycle. The test is completed, test report is collected. QA team will analyze defect distribution by type and severity.
Entry Criteria: Test Case Execution report (make sure there are no high severity defects opened), Defect report.
Activity: Evaluate cycle completion criteria, Document the learning out of the project, Prepare Test closure report, Test result analysis to find out the defect distribution by type and severity.
In this tutorial I want to share my method to iterate a request in postman collection, so it will run several times.
To simulate API response body I create an API mock using mocky. To see my mock API you can click here.
Without a further ado I will demonstrate how to loop a postman request.
In collection level click Triple dot >> Edit >> Variables
Edit variables
2. In tab Variables tab, type in type in count with current value 5, then click Update. This step will create new variable in collection level.
Collection variables value
3. Create new request. For this simulation I will use request from this story. But I will modify the test script. In the test script add script as follows.
var currentCount = pm.collectionVariables.get("count")
