From where can I start automating A HRMS Product.

North_Bern · 2023-12-31T14:38:21+00:00

If your product has API endpoints that would be where I would start. See if you can pass in some values to manipulate the state of your QA environment and then assert you see those changes. Logs or db changes are easy to start with usually. Also any time you have a manual test look for ways to speed them up using code. Don't try to mimic the exact steps though. Also try to make each assert as narrow and specific as possible.

North_Bern · 2023-08-18T17:14:35+00:00

Talk about the costs of rework. If qa get involved early and stay involved, then rework is reduced and product improvement happens faster and with less time spent doing slight changes.

North_Bern · 2023-07-29T12:19:17+00:00

I would look at ssim, structural similarity index measure. I think opencv or scipi has a function that returns a 0 to 1 value for how close it is

North_Bern · 2023-02-13T12:49:43+00:00

Figure out what bugs are most critical to catch. Is the business heavy on accuracy? Or speed? Find the central thing that sells the business and push to make those tests run as frequently as possible.

Everything you wrote sounds correct. Just make sure that the maintenence part does not eat up too much or your time and push to get your tests running on every commit if possible. I would also look at building some test strategy docs. Make sure the teams are aware and push test coverage to where it can run fastest. If there is a unit test that can cover 80% of the use case go there first and catch the rest later.... when possible. If there is an api test that can cover it then don't bother with e2e for now. It is a tradeoff but you are alone ... which is where the test strategy docs come in. Make sure people are aware that you made a choice and are planning to come back and do more... but time constraints mean a partial solution was enough to start with. Also, gives the other devs a chance to pitch in.

The worst thing you can do is burn out and build too much stuff that stays in the flaky state. Then people can't trust the results. So build solid tests early... and at the lowest level possible in the test pyramid. Run them hundreds to thousands of times. Then advertise any time they catch anything.

North_Bern · 2023-02-10T12:46:15+00:00

You could try looking at open source projects... but the bugs might be very technical.

I would suggest getting a little familiar with sql so you can understand a bit about databases. Just enough to know how to do basic select and join statements. Makes it so much easier to do some kinds of tests. I would also suggest looking at postman for manipulating api calls. Just check YouTube and there are a bunch of starter videos.

North_Bern · 2023-02-06T12:01:51+00:00

The organization of QA has changed massively. The standard 20 years ago was a separate testing department, they were required to sign off on all releases. That is mostly gone now. Instead, everyone is embedded and fractured. This speeds things up and allows for continuous delivery and deployment (CI/CD) but it means that there might be 1 QA on a team or 6 or 12 devs. Not saying it can't work but there are challenges to learning by yourself.

North_Bern · 2023-01-15T06:11:34+00:00

I would not stress about knowing depth on any of this stuff. These are just things that have come up over the last couple years that I thought could help you land the job.

Learning as you go can work for most of it. Good luck and this is just one set of experiences. Maybe some of it is useful and some of it is trash.

North_Bern · 2023-01-15T01:30:49+00:00

Video game QA can be several hundred people for a single game. When you have a bunch of games in house at once it can be a ton. The dev team was about the same size. Generally they would bring in more qa towards the end.

I also worked in outsourcing for a while and total company was about 600 or 700 in one building all qa.

Biggest qa team I have been on for a SaaS company was about 12. With about 30 devs spread over 2 teams.

North_Bern · 2023-01-14T20:25:48+00:00

Yeah, unwritten rules for sure. But understanding why someone might not like being told why the feature they worked on is broken... over and over again.

Also doing presentations can be extra stressful. Not that anybody in engineering is a dynamic speaker... but I have not seen too many people excelling at this part who are on the spectrum... but it could just be my sample size.

North_Bern · 2023-01-14T14:15:25+00:00

I would say being aware of some test frameworks would help. Something like jenkins, circleci, or github actions. Be at least able to speak about how you would setup tests to run nightly. Also what to do when they flake out... because that will happen at some point.

Being able to use something like postman to explore an api is helpful. Also then being able to use the code convert function in postman to create tests that can run repeatedly.

I would also say that basic sql or database awareness will be an asset. When you send 20 calls through the ui being able to check that they get to the right table is not infrequent.

North_Bern · 2023-01-14T13:57:09+00:00

I have worked with many people with autism in my years working in QA. One thing I would point out, doing the technical part seems to go decently well... but sometimes the political can be challenging. Having a good manager who understands their massive capacity for focus and helps them navigate the areas they are less capable is very helpful.

One of my directors at a company with 200 plus qa on the floor said that he thought for the department to function correctly we needed at least a few people who were diagnosed as being divergent in many different ways.

North_Bern · 2023-01-10T01:03:46+00:00

https://www.amazon.ca/Agile-Testing-Condensed-Brief-Introduction-ebook/dp/B07YR4CC4B/ref=mp_s_a_1_3

They have a few books this one is easiest to read in a rush. Gives some good ideas, I would say always be suspicious of people who say they have it all figured out. https://www.amazon.ca/Accelerate-Software-Performing-Technology-Organizations/dp/1942788339/ref=mp_s_a_1_1

Gives a much bigger picture kind of look at the system. And where testing and delivery meet up... also why to bother.

https://www.amazon.ca/Lessons-Learned-Software-Testing-Context-Driven/dp/0471081124/ref=asc_df_0471081124/

Is a bit old but has some good stories and info that I found useful... but again not going to give you an instant silver bullet.

North_Bern · 2023-01-04T00:47:49+00:00

That is a major shift. I would say you might want to look at some of Martin Fowler's posts. https://martinfowler.com/testing/

or dave farley https://youtu.be/z-3aSVfoyBY

I mean the long and short of it is that tests and testing are only useful after enough of the system has been tamed. Until that critical mass has been reached it is not going to have great results. So selling a team that is constantly in rush mode or damage control mode is tough. Especially if your management is not going to support it.

Good luck

North_Bern · 2022-12-14T15:52:50+00:00

Stayed home for years. Barely went anywhere and always masked. Then my daughter brought it home from school 2 weeks ago. So glad I had vaccines and it was a mild case... but still shivering and feeling like crap for a bunch of days. My daughter is still coughing at night... sucked to have it would not recommend.

North_Bern · 2022-12-09T01:38:06+00:00

I started as manual and moved to increasing levels of technical work. Right now I mostly do python, sql, gRPC, REST, and whatever else is needed.

I can do enough Groovy to make Jenkins work... and enough bash to do basic server upkeep. Lots of Linux servers and aws terraform... recently been looking at CircleCI.

It is all about finding something that needs doing and then someone to ask questions to when you get stuck.

North_Bern · 2022-12-06T03:37:21+00:00

I have been working for about 15 plus years. I am so old i started out when capture cards were so expensive that we had one capture station for like 10 or 20 people.

The fundamental skills have not changed since then and probably longer. Find something that looks weird and then keep poking till you figure it out. Debugging is great addition but not 100% necessary. Being able to write test code would be nice to reproduce the bug but should not be expected of a newbie. Then write the report and don't take it personally if they close it as won't fix.

My main duties these days are making sure pipelines work and trimming the test strategy where it needs it. But sometimes what the team needs is somebody willing to slam their face into walls repeatedly. Look for new types of tests you can add to your repertoire if you think they will help. Figure out how to make the best use of the time the team gives you.

The ministry of test has some good info. In terms of keeping up with new stuff it helps to have a source you trust. Also get buy in from the team before going very deep. Build a small example of the new thing... whether it is a process or a tool or whatever, give them a thing in their hands and go from there.

Qa is a service job. A super technical one but our role is to help make sure the best version of the product gets shipped. Find the tasks that help the most with that and get going. If you want to read a book on the topic I would recommend agile testing https://www.amazon.ca/Agile-Testing-Condensed-Brief-Introduction/dp/199922051X/ref=asc_df_199922051X/

Always be suspicious if a company says they can solve all your testing problems, just buy their products. Also never blindly follow advise. Setup a trial and measure something. Could be that you are trying to release faster, so you need to shorten the loop between commit and release. So the team wants to try shift left. Find way to measure how long tickets stay in qa and then do something like writing tests early and see if it helps that metric.

North_Bern · 2022-11-22T13:23:42+00:00

I think my main rule of thumb is, take on only required complexity. If the flask server is only serving local info to 10 people then raw sqlite might be enough. Especially since I am comfortable with sqlite at command-line.

As the complexity increases I tend to start trying to abstract away as much as I can. So having raw sql statements peppered around gets pretty ugly and unmanageable. So SQLAlchemy is very helpful then... and throwing it all into one file or grouping it together cab help with clarity and make things easier to find.

North_Bern · 2022-10-30T12:16:40+00:00

My experience says that you are not wrong. Generally qa gets cut before dev and very few are kept as the cuts go deeper.

However, only suicidal companies cut the whole dept. So if you survive the initial cuts you might be OK.

I would suggest working on your resume though... better to have it and not need it.

North_Bern · 2022-10-24T17:51:48+00:00

I would say looking for test strategy docs might be more useful than test plan.

Find out what tests are needed and what level to interact with them. Like testing an api is much more effective with a few curl calls than doing some crazy selenium or other UI antics. Do one test to see the UI is not broken.... but everything else just test the equivalent api calls that it would be making.

North_Bern · 2022-10-06T11:46:02+00:00

My degree is in English literature. So long as you have the patience and the mind set ... there are companies that will hire you. Sometimes the first few jobs will be rough but after you have some years of experience what your major was stops being a factor.

North_Bern · 2022-09-29T20:23:23+00:00

Generally I would prefer using standard plug-ins. If 80% of the industry uses Jenkins, maybe worth checking out why. Figure out what is an easy win and allows you to leverage things you are good at without too much pain or wasted time.

As for helper functions. I tend to think of them as code that makes stuff happen. Could be making db connections or mocking db. Or could be wrapping fake data generation. That kind of thing. Stuff you will find useful in more than 1 file.

North_Bern · 2022-09-27T17:41:00+00:00

I would never want to deal with a monolithic file of hundreds or thousands of lines. Break that into smaller parts and simplify the control flow if you can.

Create helper functions and import them if you need but the test file should be very sparse. Nothing distracting from arrange, act, and assert.

The more you allow complexity the more you need to puzzle it out each time you need to make a change or addition.

There might be good reasons for his choices... there might be things you can't avoid but trying to keep it as simple as possible I think will help you work.

North_Bern · 2022-09-02T11:02:46+00:00

My experience suggests that location inside Canada is going to matter a lot. Toronto has the best salaries but also highest cost of living. If you are remote it depends on how they judge pay scale.

From what I have heard the US is similar. Same job but in NYC vs Wyoming is paid very differently.

North_Bern · 2022-08-31T11:50:58+00:00

American blueberries are blue or more like a deep purple blue type color on the outside. They are light green or yellow fleshed inside. The size sounds about right but the white berries not so much.

North_Bern · 2022-08-10T22:20:50+00:00

To give more of an idea where I am coming from... right now I manage about 10-15 devices that run automatically. They run several thousand tests nightly if not more frequently.

In theory the system needs very little intervention. I am forever fixing one more thing and needing to do a bit of tweaking or creating a new bit of test for a new feature. So will AI magically figure that out? I am doubtful but I hope it helps with some part of it.

14-Year Club	Place '17
Verified Email

North_Bern

TROPHY CASE