Loading...
Answers
MenuWhat test case management systems are useful for both automated and manual test cases?
We're looking to ramp up our automated testing and use one interface to manage both automated and manual tests.
When either kind of test is performed, it needs to be done in different browsers. So, when a test passes in one browser, it could fail in another.
What tools are good for both of these requirements?
Answers
I've built this kind of system before for more than one company. What you want to build is a continuous integration system (and this is what my company specializes in). This allows you to trigger tests each time a developer submits code. The test you describe would fire up several environments in parallel (i.e. one for each browser) and you would get high level status reports about test coverage and success.
Don't hesitate to contact me and I'll do my best to walk you through the process via phone, email, and how we see fit.
In short, Continuous Integration (CI) is where you are heading. Remember that CI is a set of good practices that include automation, committing many times in a short period of time, running tests, communicating all parts involved in the project, using a source code management system, using a close of the production environment to execute your tests plus others.
Without much information about your team and the philosophy in which they develop its a bit more difficult to impose any sort of framework on you without stressing some part of your process.
Most automated testing can reach any sort of test case management system that has an API or integration.
You want to be able to adjust for when integrating a CI process with test management:
1. Detail > screen shots, log files, details on the environment and other data available
2. Direction > the build server can be used to trigger the execution, manual or automated, of tests.
3. Granularity > From one test case to executing all the builds related to a certain test case in your test management tool.
Without knowing the whole process from end-to-end the above might not help. The goal is to break your software and as early as possible. Once interface is possible as the automation is generally placed as early as possible in the development cycle.
If you are referring to automating the manual testing, there are a host of tools on that front with integrations into most of the leading tools.
My team can easily advise, put together a solution and/or framework with a bit more information. I'd prefer to have a chat in order to build a true quality assurance system that doesn't expose any risk and breaks your software sooner and faster under one roof.
Related Questions
-
Is mobile interruption testing important for mobile apps?
Just like most things, the answer is a bit of an "it depends" situation. Generally speaking the more your app functionality/features/experience is tied to calls and SMS then the more probabilistic it is you should need to test the interruptions. FWIW my firm has helped launch dozens of mobile apps and I cant think of a single instance where we tested this with any regularity. Generally speaking though if you were to want to test it regularly then I would just add it to the list of regression scenarios your team tests after making updates to the application and makes sure nothing changes/alters unintentionally.JG
-
How can I ensure my site will not have bugs before it gets hit with massive traffic?
I have been in this situation as well as almost every other web application developer and I learned my lesson along the way. You said you and 3 others tested, but I feel that 4 people may not be enough. I think at least 50 to 75 people is a much more sufficient number and here is how I do it with my own web apps: I think that is what alpha and beta versions are for. If an app is just released without it being in beta version, there will be problems, but putting something in beta tells the public that there will be bugs and that those bugs can be tested, so releasing a Beta version prior to your actual release date is one way to go. Also, when testing for bugs before releasing to massive traffic, all scenarios need to be tested and it is possible that 4 people will not test all of those scenarios or even contemplate them. I suggest to companies who release software and websites to test in all platforms including, but not limited to: 1. different web browsers including IE, Firefox, chrome, safari 2. different mobile devices including smart phones and tablets 3. operating systems 4. various times of the day where internet traffic may vary and even different days of the week 5. different screen sizes and resolutions Since every has a different version of all of these factors, testing is needed for more than 4 people. I said that 50 to 75 people is efficient testing and you may think that is overkill, but it really shows you bugs that you never would have thought of. For that many people, give away something for free as an incentive like a free product or ebook. You will get many people willing to help out for just the incentive.Works for me. BruceBC
the startups.com platform
Copyright © 2025 Startups.com. All rights reserved.