In my experience, true white box testing can evoke the "There's no way this can break" mentality and can blind an engineer to the vulnerable places in a product. Conversely, true black box testing may result in vulnerable pathways untested since there is no understanding of how the product works. I tend to agree with the grey box testing methodology. Additionally, while there is tremendous value in automation, automated test cases do not mimic the actions of a user in the wild. A combination of manual and automated testing provides the most test coverage to ensure quality.
Troubleshooting
This is the most fun and rewarding part of the job. I get to combine problem solving and logic with team collaboration. When I find an issue I run through the mental checklist of everything that could be causing it. Is this due to an environment change? Do I have connectivity? Has proxying my traffic caused problems? I try reproduce the issue. Then I try to reproduce the issue in a fresh state. I conduct a quick Jira search to determine if the issue is already documented, or if there are any related tickets that might give me some insight as to what might be causing the problem. If the issue is not already documented, I reach out to fellow QEs to ask if they've seen the behavior and simultaneously peruse the feature tickets that were merged into the release branch to determine as a first check to see if the issue is a true regression. Depending on the type of issue, I'll examine the request the client is making and the response we get back which will provide insight as to whose team is responsible for the change in expected behavior. Lastly in my investigation, I'll determine if the issue is a true regression. The next step is to find the correct source of truth for the intended behavior; the answers could be found in a wiki, in an Implementation ticket, by talking with Product, the Dev that implemented the feature, or the Data Standards Team. Lastly, I document the issue providing proper labels, details, prioritization status, preconditions, STR, A/C, and including any stack traces or screen captures/recordings that may be relevant. Then I babysit the bug until it's adopted, bumping if necessary, respond comments on tickets and provide additional context for the developer. Finally, I QA the ticket, if A/C is not met, I'll comment and send it back, if it is, I'll pass it along.
Languages
Bash | navigating the directory structure
HTML/CSS | personalizing this portfolio
Python | executing test scripts
JavaScript | sifting through our analytics, creating rewrites
Java | contributing to Android Automation via Espresso test cases and debugging the Android app
Swift | debugging the iOS app
Tools
Tools: Postman API, Charles Web Debugging Proxy, Docker Products, Virtual Machines, DbVisualizer, MySQL, Cyberduck, Firebase, Kibana, Google Docs, Google Sheets
Services: Jira/Atlassian Suite, GitHub, BuddyBuild, TeamCity, AWS
IDEs: Atom, IntelliJ, Android Studio, XCode
S.D.L.C.
I have acquired valuable knowledge of the AGILE Scrum Software Development Life Cycle. I have seen firsthand Release Planning and Grooming meetings, I have attended Regression Testing standups, I have observed Retros. I've moved tickets across the board. I have conducted Exploratory, Regression, and Smoke Testing on a mobile application for both the Android and iOS platforms as part of a two-week release cycle. I have conducted Cross Platform, Analytics, UI, and end-to-end Flow testing on the Native App. A beautiful consequence of testing mobile is the opportunity to test and debug both client and server as well as third party integration issues.
Git
I've utilized Git to checkout project branches, commit, push, and pull changes, rebase, and build applications locally in Android Studio, XCode, and Intellij. The importance of versioning becomes quite clear as you work on independent projects as I've found both in creating this portfolio and assisting in Android Espresso Automation.
