Documenting the process of building of QA Monk - A test automation and coverage software.
QA Monk
We first started with an excel sheet for test cases(version 1) Version 2 was the tracker + element IDs + Excel sheet output + Claude. So this is version 3. Problem: New features break old features. Old features are too complex to test off the top of my head. (complex meaning some
QA Monk
Not a bad week. I thought I scheduled too less. Apparently that was not the case, and I just about finished the task. What was your Primary KPI - Actual vs Goal? Goal was 15$. Actual was 0$. What a surprise. Biggest Obstacle to growth? Umm. Not having a good enough
QA Monk
Extracted the events. There still seems to be an issue. Some of the events are missing their values. I generated the flows file below. arkhitect-observed-flows_1arkhitect-observed-flows_1.csv19 KBdownload-circle It seems to have covered all the events. Even though the chat with the agent was
QA Monk
One of the biggest benefit that I cant wait to have is to run regression tests during development. While using no code tools like bubble.io, we are majorly deprived of this. Ive heard that in TDD(test-driven development) you write out the cases first. Then as you experiment
QA Monk
Today Claudius Maximus told me that there were some issues with the tracker. Issues with session management. Who even asked for session management, mate? I am realising the easiest way to solve problems is to first look at why we are doing it in the first place. Most complexity will
QA Monk
This is where we are. The image below shows the entire map of all the flows, which is a large mess. That's why we have the frequency thing to filter out the noise. However, when the noise is filtered, it looks like this. We do get the main
QA Monk
This is the first time I am hearing of it. Apparently, it does pretty much the path we are going down. Which is to establish all possible user paths by tracking actions using loggers. Then figure out the cumulative occurrence of these actions. Filter out the low priority ones. Then
QA Monk
The flows are in, and we seem to be getting somewhere. However, I've been here before(multiple iterations in the past) and learnt that it all seems good, but never good enough. I finally finished setting all the IDs on the elements using buildprint So luckily there is
QA Monk
Did some "research". By that, I mean 1 prompt. Essentially, there are 2 main problems with creating coverage for user flows. Problem 1. How do we automatically get all the user paths? For linear flows, it seems simple enough. Here is the trouble: dependent flows. Owner flips toggle
QA Monk
Today I tried running the coverage mapper using the markdown guide that I created along with AI. From the start, it wasn't clicking and I wasn't sure why. Towards the end of the day I decided to look at QA wolf. A test automation software that
QA Monk
Current version main hypothesis: If you map all the actions(workflows), You should be able to map all test cases using permutations of the actions. Use case: Large, complicated applications with a lot of settings. Apps that have a lot of traffic, so regression testing is important and main scenarios