Skip to main content

Posts

Showing posts from December, 2016

Software release should not be a 'drama'

... after 6 month of development, 3 weeks of hardening, 1 week of migration & upgrade QA we finally have release candidate #8 which is suitable for customers ... fingers crossed ... candles lighted ... next weeks will be a real hell for product support This does not sound like something you would like to do again, or every month/sprint/week/day .... And it puts stress on customers and delivery teams, if something goes wrong it is a big issue ... I traveled to high school every day by public bus. It was usually very full, but if I was not able to get in, the next one went 3 hours later. Therefore I preferred to get it in any price - e.g. standing on one foot 45 minutes without chance to breath. When I am waiting on elevator and it is full, I do not mind, in few seconds there will be another one.  I believe that releasing as often as possible could 'un-drama' whole process. To achieve this, it is necessary to heavy invest into Continuous Integration & Delivery c

Agile QA

What should QA guys do in Agile team first days of the sprint? This is an usual question. Assumption is as follows: all planned stories in previous sprint should by done-done. In others words: tested well and therefore QA have to wait few days till developers will finish some stories to test. Above assumption is completely wrong and there is a lot of work to do, these are just few suggestions: Prepare test environments for stories in current sprint Automate test cases just manually test last sprint Do grooming of stories for next sprint - challenge developers with non-happy paths Work on test strategy improvements to reflect last retrospectives Identify non-reversible changes and plan to be more rigor there