Trade Me - Senior Software Test Analyst: Difference between revisions

Jump to navigation Jump to search
m
Line 33: Line 33:


==Testing at Trade Me==
==Testing at Trade Me==
:* The test guild at Trade Me is a strong advocate for [http://context-driven-testing.com/ Context Driven Testing]
* Followed [http://context-driven-testing.com/ Context Driven Testing] principles. Considering a wide scope for testing, looking for ''anything that might surprise someone that mattered''.
:* Testers are expected to consider a wide scope of testing, looking for anything that might surprise someone that mattered. We would contribute to discussions about UX and UI designs, system architecture, database and code structure. As well as verifying that the solution behaved as intended by the various designs.  
* Shifted Left. Contributing early to discussions about UX, system architecture, and testability.  
:* At all times testing needs to be efficient and provide value for the resources spent, focussing on high risks, and leaving acceptable risks.  
* Efficient, focussed on high risks, leaving acceptable risks.  
:* Testing discussions usually start at project inception, and testing requirements are discussed as part of grooming, planning and estimation.  
* Used [https://www.agilealliance.org/glossary/three-amigos/ "Three Amigos"] to share and understand the problem, the solution, and the testing.  
:* A story's implementation journey starts with the "Three Amigos" meeting of BA, Dev & Test. This helps us understand the problem we're trying to solve.
* Peer reviewed test plans (session based exploratory test charters) in Jira
:* A "Test Notes" discussion would usually follow. Here we'd discuss the proposed solution and the kind of testing we'd like to do. This helps align Dev and Test efforts, and reduces rework.  
* Test early for early feedback. ie. before dev work was completed. Aiding alignment, informing what is left to complete story, avoids re-work.
:* Now the tester can scope out a rough session/thread based test plan, perform risk assessments, and investigate the tools that might be needed to perform the testing.
* Dev walk through - UI and code - review test plan
:* Test plans are put into Jira as a subtask, and if required, a mindmap created and attached.
* Demo to PO
:* Dev's are encouraged to share builds as early as possible, so the tester can start exploring the implementation, filling in details on the test sessions/map,  and start giving early test feedback.  
* Testers deployed to production during twice daily release windows
:* Once initial dev is complete, I would ask for a demo and code walk through on my PC. This confirms it runs on my PC, shows what modules were changed, and I ask what else might be affected. I would also show and discus the test plan & map.  
:* By this stage the test plan should be reasonably well formed, the highest risks tested and we are checking each of the test ideas in the sessions/threads.
:* The test plan always requires a peer review. The level of the review is determined by the squad, and the risks identified.
:* Story bugs found during testing are communicated to the dev, usually verbally, and tracked simply in the Jira case to ensure they are addressed prior to deployment.
:* Once a story's implementation & testing are completed to a satisfactory level it is ready to start the deploy process.
:I performed all of the above routinely as part of my senior test analyst role.


==Deploy Process at Trade Me==
==Deploy Process at Trade Me==

Navigation menu