My daily breakdown -
Title: Lead QA Engineer
Workstyle: Agile-light
QA team size: Just me
Engineering size: 7 engineers split between front end and back end
Company products: Mobile App, Web App
When i get in in the morning I lead the standup and ask about any open pull requests for code waiting to be on QA and attempt to get those PR’s reviewed and on QA. I speak about any P0 bugs I have found on production and setup a hotfix list that needs to take priority over the sprints development plans.
I then pull down the latest development app build and test any new tickets that concern the app, ensuring new functionality is working as expected and old functionality have no regressions.
I check my testing queue for any webapp work that needs to be verified and verify it.
If i do not have any mobile or webapp work to complete I move onto UI automation and requirements documentation for any upcoming work.
I am also a release manager for my company, so I check the current code base and attempt to understand if there are any risks to our release timeline, any special requirements for the release of the code (what order services have to be released, database work that is post or pre-release, and any migrations that may need to be done to ensure new code will work as expected. I check the app versioning to ensure that all apps are on the same version and that when released they will work seamlessly.
About half my day is facilitating conversations between bizdev, design, and the founders of the company and attempting to understand what each person is expecting from a release and to help get the release into a place where all stakeholders expectations are met. If this is not possible I relay that to the stakeholder that this will affect new timelines for implementations and data analysis to say why and how.
I host test swarming projects where i get a memeber from each team to help me test new features for half an hour. The point of the testing is not to give me feedback on how they wish the apps worked, but what their user experience is with it to relate that to design and to fix any assumptions we may have had during the design phase of the projects.
I create release notes for our product, and I help the company think about the customer and create documentation that can be used internally and externally for features.
I do smoke tests and regression tests, documentation and implementation, and I attempt to increase the velocity of the engineers work by suggestion tooling, systems, and communication practices that expedite our work.
Note:
Testing code usually follows a functional test of the code, to ensure I’m meeting the tickets requirements, then exploratory testing to see if I can get into state that may break the app, load testing to ensure new features or services can handle our user base, combinatorial testing to ensure that our software integration with its internal repos and external API’s are working well, and finally discussions with the backend team to ensrue that if any contracts between the front end and backend have changes or if any changes have happened with our endpoints to undertstand the touchpoints that may be affected.