Interesting question! Make sure to answer it yourself also
So my current challenge on a project isnāt much about testing itself but the way of working around it. We are currently growing super fast (really fast) and have 0 time to automate, we are all aware and know itās beneficial, our team is super mature but we just donāt have enough time to automate. We are hiring new testers but testers are hard to find in Belgium
I guess this is our testing challenge, since we are growing so fast and hiring more and more developers ā¦
So we have to hire testers also but we canāt find them :X
My biggest challenge is to convince the stakeholders, but also many testers, that testing is more than just automating the test execution (the checks in the SUT). My experience is that many testers immediately start writing code, but pay little attention to the question of what needs to be tested. So the big question is, what should be tested and how? And what is the desired test coverage of the related test? Once this is all clear, the execution of the test can be automated where possible and desired. I therefore believe that testing starts with studying and testing the requirements (test preparation) and then preparing the tests in a structured manner.
Happy New Year to you too! My main testing challenge is getting up to speed with automating especially coming from a non-tech background. I have been taking various courses to get an understanding but my issue is finding websites or places to practice this new knowledge. Another challenge is information overload for me where it seems like there is a new tool to learn every other day, how can I get through this?
Same issues here, have 2 new team members coming on board this week, have some broken automation that needs a reboot and have so many feature changes that automated testing is struggling to keep pace.
We were lucky in finding people, lots of applicants once you take the effort to reach them, turns out itās a lot of work to find applicants and then a lot to do all the interviews. Company policy of a 3 month notice period does not help anyone in the UK, it takes far longer to train someone up on average, and the 3 months hunting for a candidate actually hurts the next company. Mostly your company is not the only company in the world hiring right now, means the 3 month rule is dumb. But now we have some great onboarding resources ready. So I hope our new joiners will do very well.
Tech debt. Loads of the task in this job just take a long time and possibly due to lack of clarity about what things we aim to continue to support and what we aim to retire, sometimes we create debt. I for one welcome the SAAS model of billing, because you only have to support stuff people are paying for now, not stuff people paid for 10 years ago. I mean metrics helps, but this year we have carved out some time for tech debt. About to knock off task #1 on that list next week actually.
But look forward to doing some automation refreshing work this year, so, āChallenge!ā, I say, bring them on!
Welcome to the most awesome testing Club @ms-damola , the Ministry of test club. I wish you all the best in your challenge for the year, and I really hope that by publicly sharing your challenge you are using us all as a witness to your challenge.
I really do hope that you can feel free to ask questions and get great answers, as usual, that will encourage you to level up this year.
Yes, weāre currently working on a new app to replace our heritage product, which has a forty-year evolution history: but perhaps our biggest power user of the heritage product has been using it for almost that long and they keep on finding ābugsā which mysteriously turn into enhancements even when we say āIt was never designed to do thatā¦ā
Our main testing challenge is suprise suprise test automation! We have a lot of tech debt in this respect and we are doing multiple things like, investing in training for our test engineers or thereās a working group looking to come up with some ideas to solve this.
It feels hard sometimes because we are trying our best and making small steps forward, yet not enough progress as we would like.
Personally I feel deleting all the tests and starting again would be much easier focusing on value added from this test etc.
Welcome to the MoT club! It can be overwhelming. Iād suggest focusing on one thing at a time. There is a lot of noise and you need to prioritise and focus on what adds most value to you and your current role.
Iām sure there must be websites you can practice on for test automation. I remember asking on Google awhile ago and it came up with a blog with lots of suggestions. Iāll see if I can find it.
Yeah, if you Google āwebsites to practice test automation onā then thereās lots of ideas. Hereās one link - hope this helps with your challenge! 7 Websites to Practice Selenium Webdriver Online
This is a great question !
My current challenge is about ādealing with changesā.
More details, in my transversal role after proposing my status and finding (such as an audit as they call it), I suggested some actions to improve testing in different feature teams and transversal roles, now the most difficult part how to make those actions into practice and how to build a quality culture within the organization.
Iām at the same time motivated and at the same time afraid to coach people things that myself I donāt have a deep experience about or things I know theorically but rarely in practice. so lot of new learnings.
Another challenge is that there are a lot of products, a lot of teams. I focused more on teams and testing at the beginning without having hands-on testing to understand everything about all the products. I feel confused that I canāt memorize all those informations in this short period of time.
For me itās the typical stuff, regression bugs - they just keep returning, the developers have started writing unit tests pretty late, the UI automation is unstable as there are changes in requirements all the time - making the increase of automation coverage very slow, and expensive. A lot of the developers are very junior and are not taking the process very seriously, which translates into stories with incomplete acceptance criteria and bug reports without clear reproduction steps, or relevant details. The usual
We have quite a lot of UI Automated tests but they are not maintained. The plan was to maintain them regularly a few years ago but its not happened. Weāve had an automation tester/QA lead started recently so it looks like it will be thrown on him (not great I know)
With our team structure (5-6 devs to 1 QA) itās not been an easy ride for QAās to get into Automation testing learning C# and this has been the problem for a few years. The plan has always been to recruit an experienced Automation tester/Lead who will automated as well mentor. Weāve had a couple in the last year or so but it hasnāt really worked.
The biggest challenge for me this year is whether to continue picking up C#/Selenium/Specflow slowly in my own time knowing that itās been a hard ride in the last few years or to pack my bags and move on. Having been in the company for over 8 years doesnāt help
Microservices and cloud based services testing at scale. i.e. testing to evaluate scale for production load on non-production environment, considering load of Google/FB/Amazon scale.
Since changing teams and working processes for the umpteenth time in the past few years (now doing LeSS), lately it is managing workload. Either I have no work to do or Iām completely flat out.
I really like being embedded within the team and definitely think it is a better way of working but given that Iām not meant to do work that isnāt part of the sprint and we have larger stories then previous teams/processes, there isnāt a particularly smooth flow of work.
However the wider problem within our team is that our automated test coverage is very poor. Thereās nothing at the UI level and unit test coverage is often quite poor. When thereās a large codebase that hasnāt been designed for testability and involves things like rendering, it isnāt an easy fix. I found it quite bizarre as my time as a developer was in a team that would have quite thorough unit testing.