Iām doing a course on software testing and will graduate in a couple of weeks. Iām writing a master thesis (Maybe itās just called a thesis not sure). So the question iām trying to answer on my thesis is: What does a software tester do while there is no code?(Ex. Testplan, Teststrategy, Testcases, Risk-analysis and such written)
And how do i use this time in a āBest practiceā kind of thinking. Pros and cons?
How does ādowntimeā differ from Juniors - Seniors?
You can do a lot of things, mostly related to preparation. Go through the requirements, if on your projects you are writing test cases you can prepare them before the feature is developed (same goes for Gherkin scenarios if youāre using BDD as part of your overall development process), and work on other testing-related documentation, related to strategy and planing of your testing, plan how to automate the upcoming features, etc.
Congratulations on nearing your graduation @vilith and working on your thesis!!
When thereās no code to test, a tester engages in crucial activities like crafting test plans etc, ā¦This time is an opportunity to fortify the testing foundation, ensuring that when code is ready, the testing process is well-prepared and efficient.
Best Practices:
Thorough Documentation
Skill enhancement
Collaboration
Pros - Improved test coverage, better risk mitigation and continous skill improvement.
Cons- Potential time constraits may lead to pressure during testing phases.
Downtime Juniors vs Seniors-
-Juniors : Focus on foundational skills, learning tools and methodologies.
-Seniors : Mentorship, strategic planning, and deeper involvement in refining testing process.
Itās a blend of creativity, preparation, and continous improvement to deliver a robust testing framework.
Or improving automated test coverage if appropriate - this could be looking into new technologies, tools, methods that could fit into existing or new frameworks.
That is an awesome question and one that can be delved into very deeply.
there is a lot to test before code is written and Its a major complaint of mine that startups and greenfield product development almost always ignores QA resourcing āBecause there isnt anything to testā
Design is testable
Documentation is testable
Architecture is testable
Planned production implementation is testable.
UI mocks/wireframes are testable
All of this benefits from the biggest luxury we have as QA resources: We get to be the ādumbestā person in the room. That is, as a part of our discipline it is a requirement that we ask questions that seem obvious.
āHow does the service behave if this underlying technology requires an update that interrupts the service?ā (I have an actual experience with this)
āWhat is the observability story? No its not too soon. knowing what we want to observe ahead of time makes it easier to implementā
āThe UI mock indicates a 30 character password limit but the database spec shows a varchar(25). failing to set the password would be bad in that case. truncating it would be worseā
Yeah Im being pretty obvious in order to illustrate. But yāall know what I mean.
Additionally, QA is the one resource that is thinking through all of the input from the other disciplines. Product Owners/Managers think about the business rules and presentation that will solve the customerās problems. Architects, developers, UI engineers are all solving their parts of the PMās vision. QA is crawling around in the gaps understanding how the systems will serve the customers needs and gaming out what happens when they dont. We also, through defects and documentation, track and raise awareness of gaps and TODO items.
And ALL that is before we start considering that QA needs to do its own planning and implementations. As we all know, shoehorning that stuff in later is a Herculean and expensive task. One innovation my team did in my last gig was to develop a set of deployment pipelines that were imporoved on as the project progressed. the sole purpose of those pipelines were to build silo-ed environments on demand. When realized, every developer or test engineer could indicate a branch and launch the pipeline to build out an environment just for them and labeled with their loginID. We all but eliminated the headaches of sharing environments, local environment āvariabilityā and troubleshooting faulty local environments. We also didnt have to pay for those cloud based environments all the time as the resources were all set to be deallocated automatically at the end of the day.
@msh may have just written your dissertation foreword for you @vilith . 100% agree with the inputs, and a great question which has probably been asked in other contexts before.
So as both a welcome to the MOT community, and a thank you for the question, I hope you will spend more time with us. And update us as you finish your formal studies. Do a bit of a search around for older threads on the same topic of ādowntimeā too.
To add to what Michael H has mentioned:
Assumptions and opinions about the product are also testable.
It can be done during meetings or casual chats with clients, customers, and representatives of other internal departments;
Or having internal development team meetings on any topic, or during conversations about technical or business aspects;
Some things that could happen before testing of a finished product :
I could do market research on comparable products, products from within the company, or the previous version of the product that is being rebuilt. This way you have some models in mind and potential oracles to test with.
I could check git repositories of known bugs for libraries or test external services that will be used.
I could research opinions, questions, reviews, or troubles of similar products - this can help identify whatās important for users.
I could try to learn some technical things about the development tools used to build the product.
Start testing even pieces of the software, you donāt need a whole product for that. Support the developer to know early about potential shortcomings, risks, or problems.
Pair with developers while figuring out the solution design, help them bounce ideas and think critically about what could go wrong;
Do some business domain training, or study on your own. Or get a colleague to teach you some stuff informally or formally. Itās amazing how many testers and developers understand very little about the domain they are in.
Look forward to what could help you in testing early and efficiently. Advocate for testability constantly: be it code-based interfaces, configurations to add to yaml files, pipelines to build and deploy quickly, custom scripts to mock part of the applicationā¦etc
Do code walkthroughs. Even if I donāt understand much, I could deduct or learn a few basic things from searching on Google. Some code or configurations can be an obvious source of issues.
Socialize a lot, as testing is a social discipline. Do it with as many different people involved in the product as possible. Depending on the size of the company you can have plenty of options: support, c-level, operations, administrator, business analyst, finance/accounting, marketing, sales, commerce, project management, and development. Know their desires, the problems they expect to be fixed by the product, and the problems they encounter developing it.
Itās nonstop learning about anything and everything that one can get a hold of with generally a single scope in mind: identify potential threats to the quality of the product(as soon as possible).
Being the SME of a product is one of the greatest strengths of a QA resource. Knowing the product better than anyone elseā¦or as I call it āknowing where the bodies are buriedā¦ā
Even though many developers do the unit testing of their work, a QA resource can glean much fron those tests and even suggest refinements - a QA Manager I worked with had a rule that all tests of any stripe had to cover positive, negative and null as a minimum. It isnt comprehensive at all, but that rule did seem to spur even developers to think in terms of āam I doing the right testing?ā instead of just as another thing to be checked off before a pull request or merge
Read the specification and look if you can find problems (e.g. ambiguity) there.
Will developers develop the thing the product manager wants?
Do you understand good enough what the product manager wants? Ask them after reading if your understanding is correct.
Documents are artifacts of communication and are likely to be faulty. They are not the actual people, their desires and needs.
Talk with different people what they understood and try to get a shared vision. Every difference in mind models is a source of bugs and failure.
No code available no problem!
Easiest thing to do is open a brain storming tool (or grab a pen & paper) and just let your test ideas out.
Obviously youād be having an oracle with you!
My preference is to help out on another project that has something available to test, its the highest value activity in my experience.
There is also a lot of things that others have covered that are also high value when no code is available.
My own list includes early testing of ideas, research, building risk lists, establishing some hypothesis around those risks and designing ways to investigate those, setting up tools and environments. Most of these you would need to do regardless of whether code is available or not so I would not push them as a āno codeā motivation for doing them.
What Iām not going to do just because no code is available is start writing test cases, I for the most part find them very low value, its worse still when a manager suggests to someone that thatās what they should be doing while they wait for code. *Edit just because I do not see a lot of value in test cases, many others do, I used them in this example purely for the point of donāt turn to low value activities just because there is no code available.
There are plenty of things of value that can be done, so much to learn out there so not an excuse to do low value activities. Helping out on another project is much preferred at this point.
I forgot about that one: external support.
Helping other projects and products, departments, in regards to the quality at various levels is a good activity to do as well.
Iāve gone through testing sessions with other departments in various internal/external services, ideas for new features,
Also, the support team could use testersā help to:
advocate for changes, fixes, and improvements; they can provide the data and frustration of clients or time wasted by call-center when dealing with such problems.
identify problems with the clients, have calls, emails, remote sessions to reproduce or fix problems on their devices;
take support-created IT tickets(some companies have hundreds of tickets that are barely processed) and start reproducing problems, find causes, externalize the issue, globalize it, find the worst it can happen; facilitate advocacy to fix or add features to the product within the product development team;
make statistics and data analysis on areas clients have issues with, or patterns of problems related to specific events, or ā¦ - this helps with major issues identification;
Similar can be done with marketing, sales, finance, accounting, operations. Interesting opportunities to learn and use your skills for the benefit of the company and business.
And iām pleased to see that what you should be doing in case of āno codeā isnāt carved in stone.
The hunger and willingness to learn more in not just one area of expertise seems to be a mainstay to lean on. And the more experience you get the ācorrectā course to take is more obvious. (Pretty sure it will differ from project to project).
Could one be so bold as to say that a Software tester could be sort of like a āJack of all tradesā? Some bits in my gathered information seems to point that way at least. (I could be biased in that matter though. Iāve personally always preferred to know a little bit about everything , rather than much about little)
as a person or a team devoted to understanding and communicating the Quality or Health of a feature or application, we have to understand every other role in the process; product management, product design, users, devops, development, all of it. This doesnt mean we are so expert at any of these roles that we can replace them; but it does mean we understand these roles well enough to identify where gaps and defects can occur. By doing all of that, we help those other roles focus on the areas they are expert at.
