One in the field is a warrior or not a warrior? When you are one tester for 9 developers. Part 1

The calm before the storm

Week 1: I joined the team at a time when iteration planning was being conducted in the company. I had no tasks for 4 working days, I only listened to the organization of project sprints by team members and the flow as a whole in Zoom (SAFe methodology). I went through the onboarding for the project in absentia and studied the future scope of work.

Outside of working hours, I tried to automate existing test cases in order to immediately reduce regression testing (it was not successful due to frequent changes in layout).

Tsunami is coming!

Still week 1: Friday 7:00 I wake up to the sound of notifications on my phone (I work remotely). An analyst writes to me asking for help testing the team's development in a mobile application. I was not familiar with the functionality of the project on mobile devices and therefore studied it on the go (and in general I had no experience in testing a mobile application). They gave me a list of tasks (there were about 44 of them without a description, just titles), which need to be covered with test cases, because on Monday a release candidate build was being prepared for installation on the pre-production environment.

Task analysis, search and study of requirements, writing test cases, attaching tests to these tasks – took me all weekend. Testing itself on the mobile application test stand, of course, took the night.

A tsunami of tasks has arrived. There is nowhere to hide!

Beginning of the 2nd week: On the same Monday, other analysts approached me with tasks of testing a web application and functionality developed according to the ISO20022 standard, then developers wrote to me to test a microservice. Did they know that I was testing a mobile application with urgent tasks? Yes! (There were simply no full-time testers on this team, only a tester came for regression testing on the old, still working functionality. And the team was happy to see a full-time tester). She naively answered her colleagues, “I’ll take it on,” trying to help the team sort out a pile, and overwhelmed herself with overtime (of course, night work again).

Tuesday of the 2nd week: successfully completed the run of the created test cases of the mobile application for iOS and Android. No critical bugs were found. The task list went to the release for landing. With relief from the work completed on time, I decided to go to lunch. 5 minutes later, I get a question from the hub leader: “Have you conducted regression testing for the web application?”STOP! WHAT? I just finished testing the functionality of the mobile app!!! What other regression on the site?).

I would hardly have been able to test the web part in those 5 minutes, so the tasks that business analysts sent for landing were rejected.

Later I found out the release schedule:

1. The release candidate of the web application is collected every week by the entire ART;

2. Release build for mobile applications – every 2 weeks – also for the entire flow of teams.

Thus, every other week falls on the parallel landing of the build of release candidates of two platforms. And the second week of my participation in the team fell into the schedule of two builds (web and mobile) of the bank's product release (Nervous breakdowns? Ha-ha-ha-ha-ha! What are you talking about?» *cries quietly*).

Flood. Save yourself if you can!

I admit, I didn't know the priorities for our team's product releases, and it was difficult to distribute the testing flow. In addition, the priorities have completely changed from the original version (and are still changing).

As a result, I clarified the preferred set of Jira tasks with the product owner and distributed the assigned tasks in the correct sequence.

One platform had to be sacrificed (the mobile app) because the web was more important (according to business analysts). iOS and Android developers waited patiently for the functionality to be tested.

The rescue team arrived

Due to the arrangement of tasks by their importance, 40+ tasks of iOS and Android functionality accumulated. Therefore, I asked the hub leader for help in the person of another tester. They gave a tester, but a temporary one for two weeks (who subsequently blew the web release (just like I did when I started participating in the team. Read above), and then the temporary QA got sick (it happens), but that's another story), while we were waiting for a permanent one. The temporary QA helped a lot to close some web tasks in one week of work, taking responsibility. Due to which I was able to work on the components of the mobile application (patient iOS and Android developers were happy about this). And then I started my vacation, which fell on the week of an important web release of the new interface of the site module (“Gee-gee-gee” *laughs slyly*). By the way, during the vacation, the team wrote with a request to help test the functionality (Do you remember that the temporary tester was on sick leave?).

What happened to the two web functionality releases?

1. List of web tasks that were almost rejected (let's not point fingers) were nevertheless installed on the production environment. Thanks to the developers, joint regression testing was completed in 50 minutes;

2. The web build that fell on my vacation did not go into production, not only because of the lack of QA on the project, but also because the software product was very raw, and there was no full coverage of the functionality with tests (+ I asked business analysts not to send the new functionality to production, because it contains many bugs that the developers would hardly have time to fix on Friday evening).

How is testing going with the new (permanent!) QA engineer and did he, as usual, screw up his release? I'll tell you in the second part of the article. To be continued…

P.S. If you have experience and can give advice on how to cope with the load and not go crazy, then I will be happy to read your comments. 🙂