Setting the test process on Rail

Anastasia Sergienko, QA Engineer at SPD Ukraine

Transcript

1. on Rail Setting the test process For the Women Techmakers By A. Sergienko (me)
2. Kinda agenda: 1. Change 2. Don’t be afraid (too much) 3. Find the allies 4. Try baby steps 5. Just keep digging 6. Review (mistakes we made are lessons we learned) 7. Breathe out and then change again
3. 1. Changing is hard OTHERS ER
4. obsolete test-cases spreadsheets as a TMS non-trackable dependencies no test-docs creation in the workflow druidic knowledge sharing dev-managers HOT HOT deadlines OMG 10-year old project recent demographic boom
5. 2. ‘I want a TestRail acc’, — she said. ‘Great!’ — they answered.
6. ‘You just need to...’ Put in order all the test docs Develop the appropriate workflow Prove it’s worth the money Estimate the implementation time Present the idea - to the managers - to the customer - to your colleagues - to the managers AGAIN
7. ‘I’ve just wanted it for myself.’ 1. I’m not ready 2. I don’t have the knowledge 3. I’m not sure it can be useful for everybody 4. I’m afraid 5. I don’t want to be hated
8. 3. A test group of testers
9. We try a trial a few people every sub- project volunteers only a month trial acap: as comfy as possible Jira integration massive research several workflow patterns getting super-ready for a final presentation to the customer one for every sub-project, to choose the best afterwards effectiveness estimates implementation examples best practices
10. 4. ‘Never, never, never give up.’ Winston Churchill
11. There was: 1. A qualified team eager to use the TestRail 2. Prepared workflow for the new test processes 3. Some of the managers ready to help 4. Technically, the customer has never said ‘No’ He said: ‘We’re not ready… yet.’
12. It was no longer about the TestRail. It was about all the test processes improvement. So we (the trial team) started from everything but the TestRail. We had several months till the major release would be done. So... we started using the developed workflow (analysis before testing, docs before cases) used the test docs for mentorship created test reports after small pushes and collected statistics
13. 5. A blessing in disguise The Release Failed
14. the release was bad. Like, really bad. 1. the worst release ever 2. lots of bugs in prod 3. hot-hot fixes 4. panic It was bad, but it was also a chance.
15. After the chaos ended, the customer was ready to listen us again. He was ready to change something. As well as the PM’s, who were in doubt before. The TestRail was bought, but the most important part was that the QA improvements were approved (all that workflow and analysis stuff).
17. 6. Luck, hard work and mistakes
18. Luck: 1. The Customer was ready to listen us 2. There were managers to help 3. Some of my colleagues were ready to help
19. Work: 1. Massive research 2. Lots of persuasion 3. Extra responsibilities 4. Self-organized team work 5. Lots of brainstorm
20. Mistakes: 1. Alone 2. Customer first 3. Just an idea 4. Everything at once 5. Fear 6. Doubts Gather a team Show results Be ready to persuade Think big, do small Find support & keep digging Find proofs & best practices
21. If nobody supports you, it’s not a problem, it’s a symptom.
22. 7. Test Analysis
23. Now we have something BEFORE testing... ...what about something AFTER it? 1. testing quality evaluation 2. retrospectives 3. more exquisit docs 4. combinatoric techniques for test cases
24. That is my next stair to the perfect everyday. What’s yours?
25. «Я раньше поражался тому, как уродливы изнутри «взлетевшие» проекты. Сейчас я знаю: красивые проекты не взлетают, потому что они не успевают взлететь. Пока инженеры в белых халатах прикручивают красивый двигатель к идеальному крылу, бригада взлохмаченных придурков во главе с безумным авантюристом пролетает над ними на конструкции из микроавтобуса, забора и двух промышленных фенов, навстречу второму туру инвестиций. Авантюрист любезно раздаёт восторженным пассажирам талоны и бумажные пакетики». из комментов Хабрахабра
26. Ask me something OR smile.