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?
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.
Working patiently and passionately on implementing the strategy to deliver best-in-class Software Testing and Software Quality Assurance services to our customers and partners we see it paying off over the time. To be able to satisfy the increased demand from our clients for specialists in Software Testing, we are looking for Read more…
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.
In my previous article “How to deploy OpenAM with DAUI” I wrote down steps how to install complete architecture where DAUI is configured with OpenAM. To keep it simple, I used only plain non-encrypted communication between individual components, however in the real world, many deployments require some more security and encrypted cryptography is a basic requirement. This article is based on previous one and it adds steps to install full architecture with SSL encryption.
Internet is full of tutorials and steps how to install and configure individual tools, but sometimes there are required steps to connect these tutorials together. Sure, there are some deployment guides for complex architectures, but they are typically very complex. The goal of this article is to provide complete, but simple steps how to install and configure ForgeRock’s OpenAM access manager and DAUI (Distributed Authentication User Interface) for authentication. This solution uses also ForgeRock’s OpenDJ directory server as configuration and user data store.