In today’s constantly changing market, continuous delivery is one of the most popular engineering approaches: most companies claim they work according to CD rules, or at least don’t say out loud they don’t. Popularization of this methodology comes from its main idea: an engineering process based on short, repetitive iterations, where every iteration ends with delivering user value and getting feedback from it.
Knowing the main rules of the continuous delivery approach, how do we deal with testing and quality assurance in such a fast and repetitive process?
Finally here! Another year’s over and this blog is here for almost 2 years now. Following best agile practices it’s time to do a little retrospective and make some planes for the future. Let’s summarise what was good during past year and what could went better. Brag alert: there’s a lot to be happy about!
If you work with distributed version control systems like Git, concept of pull requests should be clearly obvious to you. In simple words: if you want to have some code implemented in project maintained by others, you make yourself a branch, write code and create a pull request that will be merge to this project after code review. In big picture: it’s you who should make changes and the project owners are only doing code reviews.
So, what is this Agile Testing? It’s kind of fancy term and everybody use it in software development and QA world, but do we really understand it? What is different in agile approach to testing than in classic ones?
I will try to highlight core concepts, that stands for Agile Testing approach. Please don’t consider this as any kind of manifesto, rather that I want to summarize list of good practices for testers and QAs working in agile teams.