Blockchain Testing Tools

February 16, 2018 Leave a comment

If you are wondering what Blockchain is, I will give you a quick introduction. Blockchain is a data structure that is distributed at once in many different places and as you can’t ever delete from it, it is extremely difficult to make amendments. This makes the record more secure and more trustworthy.

So, what are the kinds of test that you can perform ? You can use the traditional testing, since it is just normal development work with normal testing criteria. So, boundary value analysis, decision tables, test driven development and behavior driven development techniques.

There is also a set of questions that can help you to build your test scenarios, for example:

  • How does it handles valid and invalid inputs?
  • How does it cope with a wide range of input data?
  • How does it handle missing state, or existing state?
  • How does it handle error cases?
  • How does it handle security and access control?

You don’t need to test the Blockchain because the algorithms are well-established, because it is a distributed system, but the transactions still require some kind of validation. For example, you may need to check if your transaction is valid before it can be approved. There are approval authorities for different blockchains, and they must test the integrity of the transactions.

 

What is Smart Contract ?

Smart Contract is an API and defines the rules for transactions in a Blockchain network. A Smart Contract is a set of rules in the form of programmable constructs that are capable of automatically enforcing themselves when pre-defined conditions are met.

It has public functions which might be called by anyone registered on the Blockchain network. However, unlike a traditional API, a Smart Contract cannot call external web APIs.

 

What do you need to know to test Ethereum Smart Contracts ?

Test automation requires that the platform being tested must have hooks so that external automated scripts can instruct the platform, observe the outcome, and verify that the outcome is what is expected. Legacy platforms in banking often do not have these hooks, and that makes automation much more difficult. When you compare smart contracts to older software used in banks, you can automate testing much earlier and much faster.

 

I will show some of the tools that you can use to perform tests on Blockchain applications:

 

Ethereum Tester

This github has a project for you to test Ethereum Blockchain Applications. You will need to clone Eth-Tester. The Eth-tester library strictly enforces some input formats and types.

 

Truffle

Truffle is one of the most popular Ethereum development frameworks and has testing functionality, it is a scaffolding framework for smart contracts used by UI builders. You have the ability to write automated tests for your contracts in both JavaScript and Solidity and get your contracts developed quickly.

Ganache

Ganache is the most-used library for testing Ethereum contracts locally. It mocks a blockchain that gives you access to accounts you can run tests, execute commands, etc.

 

Populus

By default tests run against an in-memory ethereum blockchain and as you can see here Populus supports writing contracts that are specifically for testing.

 

Manticore

Manticore is a symbolic execution tool for analysis of binaries and smart contracts. It is supported on Linux and requires Python 2.7. Ubuntu 16.04 is strongly recommended. It has a Python programming interface which can be used to implement custom analyses. You can see more about here on the wiki.

 

Hyperledger Composer

Hyperledger Composer supports three types of testing: interactive testing, automated unit testing and automated system testing. It’s a framework for rapidly building Blockchain business networks on top of a Blockchain platform, such as Hyperledger Fabric.

This framework allows you to automatically deploy the business network definition, and then interact with it by submitting queries and transactions in order to test how that business network really behaves.

 

Corda Testing Tools

Corda is a blockchain-inspired, open-source distributed ledger platform. There are several distinct test suites each with a different purpose: Unit tests, Integration tests, Smoke tests, Load tests and other. These tests are mostly written with JUnit and can run via Gradle.

 

BitcoinJ

This tool BitcoinJ allows you to interact with Bitcoin connecting directly to the bitcoin network. So, you can simulate send and receive transactions in real time, also you don’t need to have a local copy of the Bitcoin Core.

You can follow this guide to get start with this tool.

 

Resources:

https://www.joecolantonio.com/2018/02/01/blockchain-testing-tools/

https://joecolantonio.com/testtalks/175-blockchain-application-testing-rhian-lewis/

http://searchsoftwarequality.techtarget.com/answer/Heres-everything-you-need-to-know-about-testing-blockchain

https://www.capgemini.com/2017/01/testing-of-smart-contracts-in-the-blockchain-world/

http://www.bcs.org/content/conWebDoc/56020

https://medium.com/@mrsimonstone/test-your-blockchain-business-network-using-hyperledger-composer-c8e8f112da08

Advertisements

Quality Engineer Mindsets

February 7, 2018 4 comments

Hello guys, today I am going to post about the different types of QA mindsets that exists and how you can identify them. As a QA Engineer your aim is to improve the quality of the product from the very beginning. If this is the main objective why we have so many different titles for a professional that works in the QA area ?

This is because you can find QAs that focus more on the business and product side of the project. Others are more technical and focus on the automation and improving the quality and the release speed of the product, and some others that like to do both, the business and the automation part.

What is the future of the QA professionals ?

We can notice that some QA pros are instead of running the tests and handling the hands-on work, they are transitioning into a more consultative and distributed role to help developers learn how to write better tests and improve their approach to screening for quality. Because, at the end of the day, developers are still developers and while they’ve not been trained to look for quality issues, they’re going to miss things.

QAs pros just need to adapt to a rewritten organizational hierarchy—and a completely different mindset about testing objectives.

You can spread this mindset to your entire team, not only QAs. Uncaught bugs and untested features could easily gradually destroy confidence in the new product and lead to a loss in traction. Knowing your development team can not only ship features quickly but avoid these costly mistakes may be the edge your app needs.

With the latest trends toward faster and more efficient software teams having developers doing their own quality assurance is more important than ever. It takes dedication and practice to build a QA mindset but the benefits of how it can help your team and product make it worth.

I am going to separate the QA mindset profiles following the market trends.

Traditional QE

  • Perform Manual tests only
  • Focus more on the business part of the project
  • Able to perform Functional tests
  • Create a lot of documentation, like Test Plan and Test Suite
  • No contact with the feature until is Ready to Test
  • Don’t have integration with development team

 

Agile QE

  • Perform Automation and Manual tests
  • Focus on the business and the technical part of the project
  • Able to perform Functional tests
  • Create Test Scenarios for automation and for the feature
  • Help the Developers and PO to write the scenarios upfront
  • Have some kind of integration with development team

 

Pos Agile QE

  • Perform Automation tests only
  • Responsible for configuring CI/CD
  • Focus on the business and the technical part of the project
  • Create Test Scenarios for automation and for the feature
  • Able to perform Functional and Non-Functional tests
  • Help the Developers and PO to write the scenarios upfront
  • Share the automation knowledge with the developers

 

Developer QE

  • Developer with interested in QA
  • Implement the code and the automation code
  • Focus on the implementation, but also on the quality
  • Tend to over complicate the Automation project
  • Has a QA curious and critical thinking when implementing
  • Able to perform Functional and Non-Functional tests
  • Test his own implementation thinking on the end user

 

There is also a misconception about QE:

Wannabe QE

  • Doesn’t have a QA background
  • Worked only on one type of industry or only on crowd tests
  • Usually doesn’t know anything about type of tests (Functional or Non-functional)
  • It only knows about the business related to the background they have
  • Doesn’t know the importance of trivial tests like boundary tests
  • Doesn’t really have interest about QA best practices

What I suggest for this last one is to study. If you want to work in this area, don’t undervalue the professionals that have studied and continue studying everyday to be here.

In general QEs are extremely curious and go always for the simple and cleanest solution. They are skeptical and nitpicker which are the most annoying character of a normal human hates to posses. But when it comes to a testing profession, these becomes a must have characteristics for a tester.

 

Resources:

https://haughtcodeworks.com/blog/software-development/qa-mindset/

http://randsinrepose.com/archives/the-qa-mindset/

https://techbeacon.com/qa-devops-reinventing-testers-role-face-automation

http://blog.qmetry.com/quality-engineering-mindset-devops/

https://dzone.com/articles/dev-vs-qa-should-there-be

https://qa.siliconindia.com/news/How-an-Ideal-Software-Testing-Mindset-should-be-nid-105831.html

https://www.slideshare.net/juliodelimas/mindset-do-qa-em-diferentes-contextos?trk=v-feed

State of Testing Survey 2018

January 31, 2018 Leave a comment

Hey guys, the #StateofTesting survey is closing today. It doesn’t take too long to complete and will help the QA community around the globe to see what are the trends and challenges in our area.

The link to vote is http://qablog.practitest.com/state-of-testing/

Starting with security testing

January 17, 2018 Leave a comment

Security test is a group of measures to secure an application against unforeseen actions that can cause the application to stop or to expose data. These actions can be intentional (caused by hackers) or unintentional. So apart from the obvious reasons why you should be sure your application is not vulnerable, you have at organization level:

  • Responsibility
  • Corporate responsibility
  • Regulatory bodies
  • Compliance
  • Legal
  • Financial

And at the technical point of view:

  • Integrity
  • Authorisation
  • Confidentiality
  • No repudiation
  • Availability
  • Authentication

 

So, what should you do when creating some security tests ?

You need to seek permission before you start, then try to learn on sandbox applications or virtual machine, not real environments. Keep focused when doing the tests and prepare in advance threat modelling/survey sessions.

The web security vulnerabilities are prioritized depending on exploitability, detectability and impact on software.

  • What is needed to exploit the security vulnerability? 

Highest exploitability when the attack needs only web browser and lowest being advanced programming and tools.

  • How easy is it to detect the threat? 

Highest being the information displayed on URL, Cookies, Form or Error message and lowest being source code.

  • How much damage will be done if the security vulnerability is exposed or attacked?

Highest being complete system crash and lowest being nothing at all

 

Threat modelling

A range of techniques for analyzing the security of an application, examples:

  • Data flow diagrams
  • Threat categorization
  • Trust levels

 

You need to understand how the data is manipulated in all levels:

  • Entered
  • Stored
  • Transported
  • Presented

 

What are the assets you want to protect, which can be physical or abstract:

  • Reputation
  • Customer data/client
  • Corporate data

 

Threat Modelling – STRIDE

  • Spoofing
  • Tampering
  • Repudiation
  • Information Disclosure
  • Denial of service
  • Elevation of privilege

 

There are so many ways to check if your application is vulnerable, like:

  • User Inputs
  • Error messages
  • URLs
  • Files and attachments
  • Request/Response headers
  • Insecure User Credentials
  • APIs
  • Cookies

 

If you want to test injection flaws for example, you can exploit by submitting untrusted data, also it is very common and easy to exploit causing extremely damaging problems if not fixed. This type of issue can affect UI elements, URLs, parameters in requests and cookies. Examples of Injection are SQL Injection and Cross Site Scripting,

 

Broken Authentication and Session Management

The causes of a insecure session management may lead to session hijacking, spoofing or fixation and to escalation of privilege. Fairly common, simple to exploit, but can have wide ranging and damaging impact. It can affect session tokens, user credentials, request parameters.

 

Tools

 

Resources:

https://google-gruyere.appspot.com/

https://www.pluralsight.com/courses/hack-yourself-first

https://www.owasp.org/index.php/Main_Page

https://www.ministryoftesting.com/

https://www.guru99.com/web-security-vulnerabilities.html

How to integrate Guice + Cucumber + WebDriver

December 18, 2017 Leave a comment

Hello guys,

Today I am going to post about something that I have been studying. So, in this project you can have an idea of how to implement Dependency Injection using Guice, a Google framework which helps you to reduce the need of new in your Java code. I found only projects that have only the Guice + Cucumber integration or only the Guice + Page Objects, so I think this one might be a good example of how to integrate everything.

Also, the project contains Page Objects and a Driver Factory, so you will be able to include other browsers and implement each one’s singularity when creating the browser, and also you still have the good practices of the POM.

I’ve added comments along the code, but feel free to ask anything or even suggest improvements.

https://github.com/rafaelaazevedo/dog-lightning

Filling a ticket – Best practices

December 3, 2017 1 comment

Search for duplicates

Before reporting a bug it is necessary to make sure that the bug does not already exist.

Pick a good summary

When we’re looking through lists of lots of issues, the summaries are essential in helping us to understand what an issue is about. This means that you should err in favour of putting too much information in the summary, rather than too little.

Some examples:

Bad: Space export doesn’t work
Good: Space export fails with NullPointerException when performed by the anonymous user

Bad: Administrator attachment control
Good: Allow configuration of maximum attachment sizes per space or per page

Set the Priority, Severity and Impact

You need to select the priority, severity and impact of this bug.

Set the “Fix version”, release version

Set the fix version once you know the test has passed and this is going in the next release, unless the release is based on what needs to go and not in what is ready.

Choose appropriate components

You need to select all the components that are related to the ticket. So, if you need to make changes on different components, this is the field that you need to specify them. It will be useful for the QA engineer to know what are the components affected and all the components that need to be tested.

Attach images/logs/videos/files

Often, especially when describing bugs, an image/log/video/file will help tremendously to explain the issue. If you are testing on mobile platform, try to attach tablet logs, videos and images. For web an image or a video should be fine and for the server platform you can attach the response and of course the steps to reproduce.

If you need to include a large piece of information in an issue, such as a stack trace, please do not put it in the Description field. Instead, add it as an attachment or a comment. (This makes it a lot easier to view and parse issues in most browsers.) I suggest you to use Jing to capture the images and video.

Link issues

If you know that a feature request or a bug is similar (but not identical) to an existing one, please link it using a link type of “relates to”. This will help to get a broader view of the problem, and may be able to solve not only one but two issues.

Write a detailed description

For all issues, please provide a description that can be understood by all in the community, not just yourself or other developers. Also, the description should allow the QA engineer to understand the implementation details of the story, down to the code level. This informs their decisions on risks, what testing needs to be added, and what testing is unnecessary. If you need to include some techno-babble, in addition to the plain language, for other developer types to understand the full details that’s fine.

First and foremost, put yourself in the place of someone else trying to solve the issue based on information in the Jira ticket alone. That means put as much information as you can into the ticket so that the next person can work the issue without having to follow up. Even if the ticket is for an issue you plan to work yourself, the more information provided, the better.

Every ticket must include:

  • Detailed steps to test
  • Given/When/Then following BDD
  • Impacts, any integration with other components/features/functions. So, the tester will be able to think about edge cases
  • Write which environment this needs to be tested (QA is the default if not specified). For mobile platform, we test directly from each component’s master branch, unless written in the ticket that the app was deployed on qa/dev environment.

Every bug must include:

  • Detailed steps to reproduce
  • Impacts, any integration with other components/features/functions. So, the tester will be able to think about edge cases
  • What you expected to happen
  • What happened instead
  • Don’t forget to mention the environment you are testing. Make sure to include any information which might be relevant to the bug (eg. your screen resolution, browser, etc)

 

Don’t reopen issues that have been resolved and shipped

Don’t reopen resolved/closed issues once they have been shipped. If an issue similar to yours is marked as resolved, but you’re still experiencing a problem with it, create a new issue and provide a link to the original one. In the case of resolved bug-fix-issues, this will help to evaluate whether it is in fact the same problem, or actually a new issue with some of the same symptoms.

Testing a new story/feature

If you find a bug while testing a new feature:

  • Create a Story bug and link it to the main ticket, remember to prioritize this bug. Also, put back the story ticket to in progress again
  • Once the related Story bugs are fixed, the developer should move the story containing the bugs to Ready for QA, so any QA will be able to check if all bugs have been fixed and close the main story if there was not introduced new bugs.

Resources:

https://confluence.sakaiproject.org/display/MGT/Sakai+Jira+Guidelines#SakaiJiraGuidelines-Community
https://wiki.collectionspace.org/display/collectionspace/Guidelines+for+Filing+a+JIRA+Bug+Report
https://confluence.atlassian.com/jirakb/using-jira-for-test-case-management-136872198.html
http://www.3pillarglobal.com/insights/manage-test-cases-bugs-using-jira
http://blogs.atlassian.com/2013/12/jira-qa-process/
https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=30746287
https://confluence.atlassian.com/display/DEV/JIRA+usage+guidelines

WebDriverIO framework first steps

November 26, 2017 1 comment

Hey guys, I have been studying a framework called WebdriverIO, it is a really good framework for Angular applications. It is compatible with BDD and TDD, so you can create your featuresimplement the step definition and it is also a synchronous command handling !!

Not only the hooks, but many useful parts are already in the config file, so you don’t need to create them separately, which is  always very handful.

I have pushed the project to github so you can have a look on my example, it is very simple for now.

https://github.com/rafaelaazevedo/webdriverio-study

 

– To run the project you need to run npm install and after ./node_modules/.bin/wdio wdio.conf.js

 

– In the login-spec.js you can add the scenario (describe) and the steps (it) directly like the step definitions, I don’t have the feature files for now.

– Look how you don’t need to add return for each step anymore. Since the steps are sync you don’t need to worry about it.

– The login-page.js groups all the common functions that will be used on the login scenarios.

– And the login-elements.js contains all the element getters that are on the login page, it works like a library for the elements and it will help you with the maintenance of the code.

If you want to give it a try as well you can add the webdriverio in the package of your project and follow these steps

%d bloggers like this: