Quality assurance with Blueriq [Editor]

The latest webinar can be found on this Blueriq community: Webinar Blueriq Quality Assurance

What is quality?

“Quality is not an act. It is a habit.” – Aristotle

Quality is about making organizations perform for their stakeholders from improving products, services, systems, and processes, to making sure that the whole organization is fit and effective. Managing quality means constantly pursuing excellence: making sure that what an organization does is fit for purpose, and not only stays that way but keeps improving. There's a lot more to quality than just manufacturing widgets without any defects or getting trains to run on time. Although those things are certainly part of the picture. What quality means for an organization is ultimately a question for the stakeholders. And by stakeholders, we mean anyone who has an interest in the success of what their organization does.

Customers will be the most important group of stakeholders for the majority of businesses, but investors, employees, suppliers, and members of our wider society are stakeholders too. Delivering quality in an organization means knowing who the stakeholders are, understanding what their needs are and meeting those needs (or even better, exceeding expectations), both now and in the future.

Testing Pyramid

“Quality is more important than quantity. One home run is much better than two doubles.” – Steve Jobs 

The testing pyramid is often used in agile environments. The content and video about the use of the pyramid give an indication about what to test on which level. This to benefit the most of the automated test on the correct level.

^{http://www.agilenutshell.com/episodes/41-testing-pyramid}

The testing pyramid and Blueriq

In most organization, the traditional testing pyramid is used, but it is used inverted (see picture below). This happens because most projects create a lot of tests on their user interface by using *Selenium for example (or any other automated framework). To make the feedback loop as short as possible it is advisable to change this inverted way of working so that the most tests are created as low as possible in the pyramid. This will result in:

• less scope change 
• less related code
• fewer people involved and
• bugs which are found are cheaper to solve than at the end of the lifecycle

Boehm's law

The graph of Boehm visually describes that the cost will exponential increase when testing further in the process. This supports the integration of early testing in the agile sprint teams and getting the most tests within development.

If we map the test pyramid on a standard Blueriq setup, it would give this picture:

    In this model most of the tests are on the lowest level, the resulting benefits are, as mentioned before:

• Cost to develop and maintain automated test is up-to-par
• Execution time on automated tests will be optimal
• Possibility of false negatives is decreased
• Increase in coverage closest to the team
  
  

Agile test quadrants

For customers, our advice is to use the agile testing quadrant to make a testing strategy of which type of tests you want to execute and which risks they mitigate. In this paragraph, we show how this can be implemented for Blueriq from a customer point of view. Keep in mind that every IT landscape has its own specific challenges. 

“The definition of insanity is doing the same thing over and over again and expecting different outcomes.” – Einstein

Agile Testing Quadrant in spreadsheet

In the previous chapter is a visual image of the testing strategy, In this chapter we want give an example on how the Agile testing quadrant can be implemented (Who, Why and How ?).

The Q3 quadrant (business facing) we don't have a proposal, because this is always customer specific. In the table we also described which test tooling we use at Blueriq.

Performance

“Just as athletes can’t win without a sophisticated mixture of strategy, form, attitude, tactics, and speed, performance engineering requires a good collection of metrics and tools to deliver the desired business results.” — Todd DeCapua

The flexibility in Blueriq gives the option to run the performance test on an environment where Blueriq is implemented. This can be used as an insight for the environment setup. By using the complete test project that Blueriq supplies, it is possible to test the landscape that the application will run in. If there are significant differences in the results between Blueriq and the specific installation, there is a big chance some hardware issues are involved (server / network / client etc.). After doing this initial check it is advised to create a performance test with, for example, JMeter. This way the performance can be monitored of the performance of the application and make sure it stays acceptable when introducing new features.

Performance information:

Performance tests are introduced from Blueriq 9.9: Performance reports 

Modeling and performance: Performance Tuning

For more information about these performance services please contact our support desk.

Security

“Testing is an infinite process of comparing the invisible to the ambiguous in order to avoid the unthinkable happening to the anonymous.”— James Bach

Developing secure software is critical to a company’s reputation and bottom line. Blueriq customers feel the legal and financial pressure to assure the security of their (mission-critical) applications and have strong regulatory and privacy requirements to protect private data. Therefore security at Everest is treated at highest priority in the development of Blueriq.

To introduce the security checks in an agile development process the following advice needs to be taken into consideration:

Penetration test

Keep in mind that it's advisable that penetration test should always be executed before going live on an environment.

OWASP Dependency Checker

Dependency-Check is a utility that identifies project dependencies and checks if there are any known, publicly disclosed, vulnerabilities in 3rd party components. This dependency checker is integrated in our Jenkins CI server. Currently Java and .NET are supported. The OWASP Dependency-check is used to scan our dependent libraries to identify any known vulnerable components. The core engine contains a series of analysers that inspect the dependencies, collect pieces of information about the dependencies (referred to as evidence within the tool). The evidence is then used to identify the Common Platform Enumeration (CPE) for the given dependency. If a CPE is identified, a listing of associated Common Vulnerability and Exposure (CVE) entries are listed in a report.

Dependency-Check updates using the NVD Data Feeds. For more information about the dependency checker see: OWASP dependency plugin (Jenkins). The standard libraries with Blueriq are checked this way. When using extra libraries or replacing libraries, it would be advisable to run this on the enviroment.

OWASP ZAP

The OWASP Zed Attack Proxy (ZAP) is one of the world’s most popular free security tools and is actively maintained by hundreds of international volunteers. It is used as a proxy to run selenium tests through and then ZAP can spider further throughout the complete application. ZAP will attack the application with the most popular (OWASP top10) attacks like injections, clickjacking, xss, csrf etc. ZAP should also run every night so you are sure that no important vulnerabilities are being introduced by the new code.

READY API

For more information, see: https://smartbear.com/

Why did we choose READY API as our test automation tool?

• Non technical interface
• JDBC connections
• Composite projects with GIT integration
• Dynamic environments
• Reusable test cases (Libraries)
• Data driven testing
• CI (Jenkins) integration

Ready API examples

Soon we will place here a SOAP UI Project and a studio project. 

This can be of assistance to start with test automation projects.