Over the last few years, I’ve been trying to iteratively improve our own processes at nonlinear to deliver better Sitecore solutions and set our clients up for maintainable and sustainable ALM processes. Some of my posts on automated Sitecore deployments with TFS or TeamCity outlined some of the initial steps we took in automated deployments. Recently, we posted a brief series to help folks getting into Application Lifecycle Management:
The first new piece of content I put together on this was a slideshare introducing ALM concepts of tool and process improvements, just to get people thinking about where they are in the process and what they need to change. I also covered how to achieve this with continuous improvement model, instead of trying to do a big-bang delivery.
The second piece I wrote covers why ALM matters for Sitecore (and pretty much any web application). The post covers some of the primary benefits of ALM, as well as how to apply ALM processes during your Sitecore implementations.
The third piece, written by my colleague Mauro, highlights some tips for automated testing of Sitecore implementations, specifically with Selenium. He’s been doing some really awesome things with automated testing of Content Editor, Page Editor, and the end-user flows.
The recommended reads:
In many of the projects that I have worked on, the application we’re building needs to integrate with a back-end system or a web service layer that is maintained by a third party or by another team. In these cases, we shouldn’t assume we’ll have the ability to ensure that the other group has set up an automated test bed to verify regression. Especially if that other system is having changes made to it to support the project!
This is where integration testing comes into play. There are a few things that you should be doing with your unit tests to ensure your integrations continue working throughout the lifetime of your project, and also that your automated tests are running efficiently so that your team is not slowed down waiting on expensive integration unit tests that are running for long periods of time.
Continue reading “Integration Testing with Unit Tests and MSTest”
So you want to transition to agile, and have started reading about how there are only a few roles in an agile team: Scrum Master, Product Owner, or Team Member. In particular, you may be getting thrown off by this line from the Scrum Guide:
Development Teams do not contain sub-teams dedicated to particular domains like testing or business analysis.
If you’re a purist adhering to the letter of the law, this means you can’t have anybody in your team that is performing only one function, like a quality assurance analyst. However, “Being Agile” is about learning, changing, and improving, not being rigid. To succeed you need to take the framework, your team, and what works for you and adjust from there.
Continue reading “Firing Your QA Team is a Bad Idea”