By Christine Paras
Continuous Testing and Continuous Monitoring
By Sanjeev Sharma
What is the goal of Continuous Integration?
Is it to enable Continuous Delivery of the code developers’ produce out to users? Yes, eventually. But first and foremost it is to enable ongoing test and verification of the code. It is to validate that the code produced and integrated with that from other developers and with other components of the application, functions and performs as designed. Once the application has been deployed to a production system, it is also a goal to monitor that application to ensure that it functions and performs as designed in a production environment, as it is being used by end-users.
This brings us to the two practices of DevOps that are enabled by Continuous Integration and Continuous Delivery.
Fitting QA into a modern DevOps group
By Tim Hinds
In a traditional software engineering organization, the QA group is often seen as separate from the Development group. Developers and testers have different roles, different responsibilities, different job descriptions, and different management. They are two distinct entities.
However, for folks outside the engineering team – say in Operations – they generally consider Development and QA to be in the same group. From this perspective those teams are working together to do a single job, with a single responsibility: deliver a product that works.
So what happens with QA in a DevOps organization? When Development and Operations merge together, where does that leave QA? How does the testing team fit into a modern DevOps group? This article will take a look at exactly that question.
The Reason Behind DevOps: Automated Deployment
How to ensure a successful test-driven environment
By Sanjay Zalavadia
In order to ensure a higher quality product is released in the end, many teams have turned to test-driven development. Under this scenario, quality assurance metrics professionals first create various QA tests, and then software engineers code based on these tests, typically while using a robust enterprise test management tool.
It’s easy to see the benefits of such an approach, as it ensures that QA metrics are kept front and center throughout the entire process. However, it can also introduce problems even for teams following agile development best practices and using free agile test management tools. In particular, test-driven development requires quality assurance metrics professionals to have a very clear understanding of what the final product is supposed to do and all of the steps they need to take to get there.
By LogiGear Staff
It is a fundamental role for testing teams to align their test design, test automation, and test case development with DevOps–not only to verify that code changes work but that the changes do not break the product. A key differentiator of DevOps is testing maturity. An organization can automate their integration, testing, delivery, and monitor, but still have issues with the intelligence of test orchestration and automation, which can lead to a bottleneck if this is not resolved beforehand.
In most projects, TestArchitect can be used in a general DevOps process. Following the Action Based Testing method, TestArchitect offers capabilities to develop and automate test cases quickly in the same sprint as the application under test, thus allowing team members to become actively involved in the testing and automation process, each from their own skill perspective. Apart from QA other team skills/roles will typically be development, operations and product ownership.
There are four continuous processes in DevOps as below.
The ownership of quality has evolved, don’t get left behind
By Michael Hackett
Welcome to our new feature in LogiGear Magazine! We will be doing a column in each issue on current topics and how to manage, deal with, and support your team through them.
This first installment of Leader’s Pulse is about making the move to DevOps. This is a large topic and will be covered over a few magazine issues. What I would like to cover in this article are two topics: high-level mindset topic: the growing and evolving ownership of quality, and a low-level details topic of DevOps and its impact on test environments and data.
The No-Nonsense Guide for How to Write Smarter and Low Maintenance Test Cases
By Michael Hacket
Test design is a phrase that is often used when planning testing and test efforts, but I do not believe it is well understood. Also, opinions vary widely about the importance of test design ranging from irrelevant to the crucial ingredient for success.
Recently, I was at a company where they are throwing out their entire test automation suite and starting over. The regression suite they had been building for a few years was bloated and verbose. To make matters worse, the pass-rate (percentage of automated tests passing each run) kept dropping, and the team had long ago lost confidence that the regression suite even gave much assurance.
Their idea two years ago was to invest a bunch of money in a new tool and hire more technical staff. Next, take the manual test cases and automate them since they seem to work, and automating is better than manual. Good idea? Eighteen months later they had a large number of automated scripts, but the tests were poorly designed in the first place.
An Overview of Four Methods for Systematic Test Design Strategy
By Hans Schaefer
Many people test, but few people use the well-known black-box and white-box test design techniques. The technique most used, however, seems to be testing randomly chosen valid values, followed by error guessing, exploratory testing and the like. Could it be that the more systematic test design techniques are not worth using?
I do not think so. When safety-critical software is produced, it is tested very systematically using tried and true techniques: standards recommend or require doing so. Therefore there must be some value. What kind of value?
By Randy Rice
There are many ways to approach test design. These approaches range from checklists to very precise algorithms in which test conditions are combined to achieve the most efficiency in testing.
There are situations, such as in testing mobile applications, complex systems and cyber security, where tests need to be creative, cover a lot of functionality, and go beyond what may be described in a requirements document, use case or user story.
Over the last thirty years or more, a variety of test design techniques have been described in books and training courses. These techniques include boundary-value analysis, decision tables, requirements-based testing and so on. Each of these approaches has upsides and downsides which require the test analyst to fully understand the limitations and requirements of the techniques used in a particular situation.
By Julian Harty
One of my current responsibilities is to find ways to automate, as much as practical, the ‘testing’ of the user experience (UX) for complex web-based applications. In my view, full test automation of UX is impractical and probably unwise; however, we can use automation to find potential UX problems, or undesirable effects, even in rich, complex applications. I, and others, am working to find ways to use automation to discover these various types of potential problems. Here’s an overview of some of the points I have made. I intend to extend and expand on my work in future posts.
In my experience, heuristic techniques are useful in helping identify potential issues. Various people have managed to create test automation that essentially automates different types of heuristics.