Here comes a testing focused article after a series of technical blogs! It is based on experience with projects managed through waterfall processes and it continues the series about tackling test complexity.
It is about a luxury that we so often ask for and we often don’t have in testing: to be involved early in the product development process. What does it mean actually to be involved early in the process? Why is it so important? And how does it help tackling test complexity anyway?
Engine Yard is a platform as a service (PaaS) company that focuses on deployment and management of Ruby on Rails, PHP and Node.js servers in order to provide to customer a quick and simple way to deploy applications. They provide also a local version of Ruby on Rails server on Gentoo Linux so anyone can test how it works. I wanted to run the Engine Yard Local on CentOS 6.5 to test sample a Ruby application without the use of cloud services but I have faced some difficulties during deployment that I’ve been able to resolve and wanted to share it with you. This article shows all the steps to run Engine Yard Local on fresh install of CentOS 6.5 that I used for deployment. Read more…
I gave a short overview of OpenAM Session Upgrades in a previous article. This is a follow-up that intends to describe the process of configuring it and discussing some of its implications. This blog was sitting back half done as a Draft for several months. It was originally written based on ForgeRock OpenAM 10.x . OpenAM 11 has been released since then. I’m finally finding the time for finishing and publishing the article. It should apply for OpenAM 10.x as well as OpenAM 11.
profiq just announeced strategic partnership with ForgeRock for system integration of open-source and standard-based Access and Identity Management (IAM) products. This is a fundamental milestone in fulfilling profiq’s system integration and system testing strategy. We have spent the last 8+ years with deploying and testing ForgeRock products and their predecessors and looking forward to offering an extended service to customers in the Czech Republic, Slovakia and Hungary with ForgeRock.
SSO authentication introduces some technical challenges besides providing obvious benefits. Imagine for example that you need to assign different types or levels of authentication to different resources or different actions within a domain. E.g. you allow users to view information, if they successfully authenticate using user name and password, while you may require them to insert a special security code besides user name and password, if they want to start editing. Or you allow users to access general content using user name and password, while accessing specific content (e.g. admin content) needs a security certificate.
Now, what if the user is logged-in with one level or type of authentication, while she attempts to access a resource that requires a different level or type of authentication? Will she be asked to log-in again? What happens to the SSO session technically in such cases?
This article follows-up with the series of articles about tackling test complexity, adding a view on the importance of product knowledge, when coping with the complexity of testing. Let’s assume that you understand already, who your customers are;)
I managed testing of a large integrated suite of software products on one of my past projects. Each product had its years of individual history already, when the decision was made to release them as a suite. And each of them was quite complex on its own, even without considering integration with other products. The number of installation issues reported by customers started increasing to an unacceptable level after a couple of years of the products suite’s existence. The whole engineering organization became concerned about the issue. First hypotheses about the cause assumed that the released installer was defective or that the product documentation was unclear. These were not proven however. So, we decided to conduct a profound root-cause analysis.
Understanding customer needs for being able to do good testing sounds like commonplace that doesn’t need a special discussion. And testing projects often omit to discuss them indeed. Testing teams often start their project involvement with reading functional (or non-functional) specifications, skipping the customer view. I’m still mentioning it on the first place in the introduction of approaches to tackle testing complexity.