Manual Testing

• F

  Difference between Smoke Testing and Sanity Testing
  manual testing smoke testing • • fbio  

  3
  0
  Votes
  3
  Posts
  14
  Views

  

  Smoke Testing Smoke testing is performed to ascertain that the acute functionalities of the program are operating properly. The major goal of this testing is to ensure that the newly generated build is stable enough to withstand further rigorous testing. It is done by both developers and testers. It is a subset of acceptance testing. Sanity Testing Sanity testing is done to check that bugs have been fixed after the build. The major goal of this testing is to determine the system’s rationality and correctness to ensure that the proposed functionality performs as intended. It is done by testers. It is a subset of regression testing.
• Z

  Zephyr vs Xray vs TestRail
  manual testing test management • • zymir  

  3
  0
  Votes
  3
  Posts
  16
  Views

  

  @zymir l'm not sure if you're adopting Jira cloud or Jira datacenter, as the options you have will depend on that. Anyway, let me give you some food for thought I work at Xray, but I'll do my best to provide some useful information (non-sales related). I will answer inline, below. integration with JIRA Both Xray and Zephyr (squad and scale) work inside Jira, so therefore their integration is native => the most complete you can have. However, some teams may need just to have a way to upload test results to Jira and see their impacts on the related stories. If that's the case, then TestRail is a viable option. Here, you'll have to think if you want people (devs/testers) to use one tool, or several tools. ability to import existing test cases from Excel sheets In the case of Xray, it provides a built-in Test Case Importer that you can use to import test cases in bulk. cost effective I won't answer this one on purpose; that's something you have to evaluate. ability to integrate automated tests Xray supports a bunch of test automation tools/frameworks/libraries, including Junit, TestNG, xUnit, Nunit, Cucumber, Cypress, Playwright, Postman, etc. You may find around dozens of test automation tutorials and integrations with CI/CD tools in Xray docs. quality of the JIRA plugin I would recommend you to look at: reviews on Atlassian Marketplace, for example for Xray cloud frequency of releases, and how frequent are bugfixes and new releases. You can see it also on Atlassian Marketplace, on the Versions tab>pick datacenter>then see all versions under Resources section, which shows info both for the product on Jira cloud and on Jira server/datacenter; example for Xray in case of Zephyr and Testrail, is it advisable to use the JIRA plugin only without using their enterprise service? Please check what each vendor provides exactly with their enterprise offering and see if it matches your needs; also check the SLAs. Some organizations demand priority support, customer representative, 24x7 support, etc.. check exactly your needs and what is offered by the the enterprise offering. I would also consider the frequency of releases and the policy of bugfixes as something to consider.. because you can have a "enterprise kinda of service" but bugfixes could take a while to be released. It would be good if someone could provide a Matrix Comparison for these tools based on these features. Xray has this comparison page, which is not complete. I'll give you some few things that you can use to help you pick tools in this space. Please don't consider this an exhaustive list what testing approaches (manual test cases, test automation, exploratory testing) are we following? does it support all of those? are our teams working in siloed environments? Or are they part of the scrum / agile team, or even embed as skills within the team? Siloed teams may prefer to have separate tools (even though I don't think it promotes collaboration, transparency, agility) do we need to track coverage? and full, bi-directional traceability between epics<=>stories<=>tests<=>runs<=>defects? do we need to track the status of our product on multiple versions/devices/environments at the same time? is the product flexible to enought so we can adapt processes and tooling, including test automation frameworks and CI/CD tools, at any time? Hope this helps, anything please let me know
• J

  Should bugs found by exploratory test methods be taken against QA?
  manual testing development process qa process • • jonetta  

  2
  0
  Votes
  2
  Posts
  7
  Views

  

  I think the first big problem here is the attempt to assign blame. In accident reports, the FAA doesn't start with who to blame, they start with what went wrong and what were the causal factors. Assigning blame causes all types of unintended consequences. In the worst case, if you blame/penalize QA for finding bugs that were not foreseen during the design phase, you will encourage QA to not find them during testing. NOTE: this means that it is the customer that will find those bugs. The idea of counting unplanned bugs is worse than penalizing developers for KLOC drops. To explain KLOC drops, understand that IBM tracked developer stats by counting lines of code written (a KLOC is a thousand lines of code). The numbers only really have meaning for new, greenfield projects. Once code is in place, changing existing code to be better doesn't show in the metric. Changing the code to be simpler/easier to understand can actually reduce your numbers. It is one of the problems that Microsoft had with IBM on OS/2 (Microsoft didn't measure KLOC, IBM did). So Microsoft would want to fix/improve the code and IBM employees would resist because changes that didn't increase the KLOC count were not valued. In this blame game are the developers penalized for each bug that QA finds? If not, then you have an inconsistent view of blame and responsibility. Another thing to remember about metrics is to count what matters, not what you can measure. Too much of what people do with metrics is to count what they can measure. Not all metrics are valuable (some even reduce value).
• Y

  White Box testing - Condition and Branch
  manual testing test design whitebox testing • • yajahira  

  2
  0
  Votes
  2
  Posts
  5
  Views

  R

  What you need to do is to do a boundary analysis: Identify which values of your variables have different meanings/effects in the context of your program (in terms of branch execution - since the paths to states 6 and 7 result in the same code to be executed). In this case, X may mean different things when: It's lower than zero; It's between zero and one (not including); It's between one and four (not including); It's between four and seven (not including); It's bigger than seven;
• F

  What is a good test review process for sporadic failures
  defect tracking qa process testing team review • • fbio  

  2
  0
  Votes
  2
  Posts
  7
  Views

  G

  From what you have written, I'm not certain if you mean bugs in the test code, or bugs in the product. I think it's important to distinguish between the two. Every QA team has different processes. Not a problem to me. If something works in one team, why force them to change? due to various reasons there are cases where a test fails, and a regular restart make it pass (which for some it just fine as there is not a product bug) If it's a problem with a check, go fix it. If it's a problem with the product, share the observation with the team (e.g. by adding a new bug in a bug tracking system, or by bringing it up on a daily stand-up). However, be wary of such intermittent problems that go away with the next execution. They might point to something you are not aware of now, e.g. problems with web performance - maybe the application causes many long tasks in the browser, thus the browser has no resources to keep parsing, rendering, and painting. Or too much data goes over the network, so there is a delay because the browser is waiting for some resources. Such problems might cause such intermittent problems in functional automated checks. My approach usually is to file a ticket for tracking and go on with the next test. Even if i know that it is insignificant i would rather track it down. When I finish with the review I can go back and investigate or fix or whatever. Investigation of problems should happen before you raise a new bug. It's part of your job as a tester to try to be more specific as to what's wrong with the product. That investigation might reveal it's not a bug in the product, but rather with the automated check, then you should do something about it (fix it, not run the check, ...) - either way, you will be the one working on the fix, therefore, it might not be necessary to add this bug in any bug tracking system. Creating tickets for ANY single failure could not be efficient... Yes, it might not be. Sometimes it's enough to tell the developer who sits next to you, he can fix it immediately. Or you can share your observations in a meeting, in a stand up meeting, on a Slack call. ... as some of them could be really sporadic and might not be even reproducible But not for these reasons! Intermittent or sporadic bugs can still have severe consequences, so you should investigate. It's a good idea to share your observations as well, tickets are one way to do it. most likely that ticket will be hanging there forever and no one will care about that ticket That's a speculation. Don't rely on such assumptions as a tester. I would like to know what do you think about the handling of sporadic failures and advice for good QA process in such cases. I investigate every bug. If it's a bug in the product, I share my feedback. If it's a bug in my testing code, I fix it and many times don't share this information with anyone. How do you deal with sporadic failures and test stability? These are two questions to me. Sporadic failures - I investigate, I share my observations with the team. Test stability - I care about my test code, I try to improve test stability, it's my personal responsibility as a coder of automated checks.
• K

  The testing time for software cannot be too long, yet software needs to be thoroughly tested before it can be commercialised
  manual testing whitebox testing • • kalyn  

  2
  0
  Votes
  2
  Posts
  3
  Views

  Z

  Before you start the testing processes , you should understand the main principles of testing . https://www.guru99.com/software-testing-seven-principles.html Testing shows presence of defects Exhaustive testing is not possible Early testing Defect clustering Pesticide paradox Testing is context dependent Absence of errors fallacy In this most importance once are the : Exhaustive testing is not possible and Absence of errors fallacy: you cannot test under percentage of the code flows. You should concentrate on the business needs than functionality when testing a product, this ensures that most important workflows are covered and tested . This ensures "Absence of error fallacy", meaning you dont release a product that have no required functionality. Early Testing: you need to ensure a "Testing pyramid" , shift left approach where you have early testing like unit tests , integration tests , system ect Having proper unit tests , integration test etc shows what failed and that to quickly. So it facilitates faster feedback . if there was just system tests then developer should waste time debugging , and retesting whether it was a UI bug or backend bug , which component failed etc. If you had proper unit test, then it fails suddenly and shows where the failure is so you can save the feedback and retesting time (time is money in business) Testing is context dependent: Each test strategy and approach depends on the budget , team, product , team size skills etc. Now getting back to your question: I know black box testing can be faster, but how do we reduce time for white box ?testing? "white box" testing is about having knowledge about the internal structure of your application , this is just a added information that you get which you can use to write more interesting test use cases . It isn't slow or faster than black box, as its not testing process but about the understanding about the product. White box testing is usually covered with "unit tests", here we don't see the entire code base but just code base of each component. A component may be a class , or function . Here we just verifies that we achieve around 100% of branch and statement coverage. We fail the build if we don't achieve the required coverage. This ensures that all worst case, average and best case scenarios are tested for each component. How do we reduce time for white box testing? Write more unit tests Have proper "SOLID" principle in your system architecture and implement unit test and coverage metrics. Automate Shift left , have early testing like static code analysis, unit tests etc So The testing time for software cannot be too long,yet software needs to be to be thoroughly tested before it can be commercialized by achieving Automate testing activities Have coverage threshold for code and branch Have static code analye Early testing Cover all business requirements DevSecOps approach where you integrate security , performance etc to the left of your build pipeline "knowing" exhaustive testing is not possible but can create confidence on the product by having proper automation coverage for all business flows, regression phase ,security and performance
• J

  Net new design visual QA methods? (not regression)
  qa process • • jonetta  

  2
  0
  Votes
  2
  Posts
  1
  Views

  N

  I've never tried this before, but this (slightly old) Applitools help doc suggests converting the mockup to an image (if it isn't one already), sticking that in a shell web page, and then using their tools to make a comparison with the developed version. It seems like the reverse could also be done with their offering, taking a screenshot of the developed version and comparing that with the mockup. Both seem kind of less than ideal processes imo. It might be worth reaching out to some of these vendors directly about if there are better options (I just tweeted at Applitools about this fwiw)
• 

  Should I ensure if integrated services are called correctly?
  integration testing • • Marcee  

  2
  0
  Votes
  2
  Posts
  3
  Views

  O

  If your test framework is completely black-box and only has access to the API like a consumer would, could you repeatedly hit the endpoint that adds a participant to build up the DB state like you expect, before hitting/testing the other endpoints that retrieve data (and then cleaning those up with different endpoints)? I assume this would be rather slow and inefficient, and so if your test framework does have direct DB access doing the setup/cleanup directly there would more than likely be preferable. But if not, that may be the only option. Also I'm assuming there's already some automated way of monitoring/reporting the performance of these requests. If not, that's probably the first step, just getting some way to do/automate the measurements, whether in the production app and/or in the tests. That way it can hopefully evolve into a feedback tool for the developers too as they write new queries.
• J

  Automatic network condition change for MacOS app manual testing
  manual testing tools desktop application • • jonetta  

  2
  0
  Votes
  2
  Posts
  4
  Views

  R

  You can simply create a stubbed version of your clients objects that simulate some behavior. Then in the tests you inject this stubbed client. interface Client { callTheNetwork(); } class RealClient { callTheNetwork() { return http.call(); } } class SlowClient { callTheNetwork() { waitSeconds(3); return stubbedResponse; } }
• J

  Test case preparation and execution time
  manual testing test design testcase test planning test estimation • • Jolied  

  2
  0
  Votes
  2
  Posts
  4
  Views

  Z

  Firstly, I would be careful when communicating this type of relationship between test cases and your testing, because, test cases are not testing. Promoting otherwise may cause issues both for the stakeholders who won't understand what is happening and for the tester who will have less leverage to promote deep testing. Testing is the process of evaluating a product by learning about it through experiencing, exploring, and experimenting, which includes to some degree: questioning, study, modeling, observation, inference, etc., not the process of making evaluations by applying algorithmic decision rules to specific observations of a product (aka pure scripting - test cases). If they know a bit about testing, stakeholders don't want to know about test cases, but about your discoveries about the status of the product. Thus what you need to track is what makes the time you spend trying to discover important facts about the status of the product. One framework to do so is the Session-Based Testing Management. You can summarize your testing session using a sheet as below. In it, you can register how much time you spent exploring the product, applying sensemaking of the behavior of the product. how much time you spent preparing your environment and product for testing, and how much time you were focused on the charter versus exploring areas that seemed more interesting. This information can then be aggregated to uncover if some of these activities are usually a bottleneck for testing (Setup and sensemaking are usually bottlenecks in environments with low testability). Having this summary can help you to forecast the testing time for future similar activities (investigation on same code base area, same time of refactoring, same downstream dependencies, etc).
• B

  No tests in the legacy project - what to start with as tester?
  manual testing test management test design regression testing test strategy • • Burma  

  2
  0
  Votes
  2
  Posts
  4
  Views

  O

  In addition to reading Working Effectively with Legacy Code, I have a few recommendations from experience: Since there is little to no documentation, tour the software. Go through the software using it as if you were a user, noting what it does and what you can find about why it works the way it does. Talk to long-time users. Since this is internal software, you should be able to locate people who have been using it for a long time. They will be able to tell you more about what they expect from it. Talk to developers. Where you can, talk to the people who built the software. They will have information about why it's designed the way it is. Focus on functionality first. As internal software, there will be assumptions baked in: users will know what they are doing, so the UI does not have to be intuitive, there isn't a need for comprehensive help, appearance matters less than function, small bugs that don't interfere with function are acceptable, that kind of thing. This will help you to prioritize your testing. Create documentation as you work. This is something I've found immensely helpful when dealing with large, poorly documented applications. My documentation may never reach the standard expected for user-facing documentation, but it is generally enough to help developers and other testers deal with the complexities of the application. The format is up to you - choose whatever works best for the way you work, but make sure you tie it in to your test cases when you create them. Focus on learning the application. Test cases will come as you learn where the critical areas of the application are and how the modules fit together. If you focus on learning the application first, your test cases will be more focused on key functionality.
• J

  How to write user acceptance testing for web app?
  manual testing quality assurance user acceptance testing • • jonetta  

  2
  0
  Votes
  2
  Posts
  4
  Views

  E

  For starters, don't pass to your client the impression that you can document all your testing, because testing is a performance, not artifact generation. It is made of both explicit and tacit knowledge, including tacit oracles, which can't be described down. Now, changing the question to "how to communicate the information I've uncovered during testing?": Easiest and more complete way: Record your testing and express your thinking process along the way. This is known as Testopsy; You can fill out a charter of your testing sessions (possible template here), followed by debriefing session; You can pair with your client during your testing; You can describe specific actions and outcomes in sequential order, attempting to encode all the thought process you had during your testing. Speaking of the last point, unless your context really calls for this type of solution, I would suggest to not go this way. If the idea of encoding a human thought process doesn't seem absurd and misleading to you, I would suggest reading this blog post series.
• 

  So I have missed a BUG and passed a test case
  manual testing qa process • • briley  

  2
  0
  Votes
  2
  Posts
  1
  Views

  R

  Just to add on to Michael's answer, The thought that 'I' messed up something helps you in realising what went wrong and the realisation that Glad I made the mistake so that I can make sure I won't make the same mistake again helps you grow as a professional. A good IT professional is not just a person who can code, but can debug So, that goes for debugging issues in the, process, design, and literally everything. So making mistakes will help you in identify such mistakes and finding solutions In future and thereby helps in your professional career. Now about the situation, this is a chance to learn many things, few of them could be: Realise that, no one talks about this on Monday, they will be busy with fixing the issue and The entire team will have moved on by then. It's great that you are in a mindset to take up the responsibility, but this situation is not entirely your mistake It shows bad work culture, having a single QA to test a critical customer application that to manually with limited deadline shows lack of planning. Try to realise that you are doing more than what you could by pushing your work across weekend, working extra hours to finish the tasks. You won't be recognised for your hard work but have self-realization that you did the best but mistake still happens. We are not robots, so don't need to feel bad and blame yourself. Learn to prioritise test tasks: Whenever you have such time constraints, always start with the critical use cases (Business cases). Then, try to cover all the other business cases or test cases that are already being identified. Once all test case execution is done just do a rough exploratory test. Talk to your team discuss an action plan, tell them that you are a human too and will have mental blocks when doing so many tasks. Ask them to split the work, and ask BA, Dev and others to pitch in to execute manual test cases when the deadlines are tight.
• O

  Is there a tool to mirror input events on one device to multiple devices?
  web application manual testing browser automation cross browser testing • • Oba22  

  2
  0
  Votes
  2
  Posts
  1
  Views

  

  I'm not sure you can update sensor inputs in all other mobiles at same time by using one device, because each and every mobile has different sensors and you can invoke that sensors only from that mobile device. try to connect multiple android devices with appium join this chat it will help you https://discuss.appium.io/t/using-appium-to-run-tests-on-multiple-physical-devices-at-once/908/6
• Z

  How to write high quality code in javascript without a pair?
  code quality • • zymir  

  2
  0
  Votes
  2
  Posts
  2
  Views

  

  Achieve quality code through modern tools and automation Note: All of these practices also apply to pair and mob programming, code reviews & pull requests. Try to get all of the steps below working before you submit a pull request and your fellow developers will be very grateful. Don't think of automation as just 'tests and testing'.. Automation in this context means also getting feedback from tools and technologies that can help. Four key methods for getting that 'over your shoulder feedback' for Javascript, when you don't have a pair/mob are shown below. I also use them somewhat in order, e.g. linting (for errors at least) must pass before tests even run, etc. 'use strict'; Automatically gives helpful advice. Linting. With strong rules. This alone will give you constant feedback about poor practices. Tests. Lets never forget them. They provide constant feedback and advice. Code Coverage. Let these tools keep you honest and aim for 100% coverage at all times. A fifth approach is to use a 'prettier' but personally the js one doesn't work for me (long discussion avoided). It might work for you however. That's OK too. Sometimes I forget to add linting for a piece of code I am working on. And then I add it. Wow. I am usually amazed and humbled at all the things I cannot remember to do right. And each time I learn a little more about doing it right in the beginning next time Today for example, code coverage showed that a default parameter was untested and when I actually added a test the functionality turned out to be broken! Which I fixed. Thank you code coverage! My linting rules as an example. I've been helped by most at one time or another. rules: indent: - error - 2 max-len: - warn - code: 120 no-dupe-else-if: error no-dupe-keys: error no-duplicate-case: error no-unreachable: error prefer-const: error eqeqeq: error semi: error no-var: error no-fallthrough: error no-new: error no-redeclare: error vars-on-top: error default-param-last: error no-mixed-spaces-and-tabs: error no-tabs: error no-trailing-spaces: error no-irregular-whitespace: error no-unused-vars: error no-nested-ternary: error no-multiple-empty-lines: error no-extra-boolean-cast: warn no-extra-parens: warn default-case: warn no-else-return: warn no-eq-null: warn no-eval: warn no-loop-func: warn no-native-reassign: warn no-param-reassign: warn no-self-compare: warn accessor-pairs: warn block-scoped-var: warn no-throw-literal: warn prefer-regex-literals: warn camelcase: warn no-useless-rename: warn prefer-rest-params: warn prefer-template: warn plugins: - "mocha"
• 

  ORM validation and testing
  validation test design data validation • • Laycee  

  2
  0
  Votes
  2
  Posts
  1
  Views

  C

  When it comes to ORMs or really anything I am using to model behavior, I aim to create models that are going to protect the system I am writing tests for the most. This usually means I am modeling whatever backend database or document storage system the software is using. Why? Regardless of what a user can do or an API is written to do most backend systems have hard restraints that are determined by the datatype they are storing. These column restraints should be respected and modeled by your ORM objects. This ensures that even if something were to make it through your JSON validation it would surface an error before attempting to perform an action on your database. The drawbacks of this is having to be more attentive to scheme changes. @PDHide Take a look at SQLAlchemy for Python or ActiveRecord for Ruby.
• M

  Should testers estimate effort only for themselves
  metrics agile testing test planning test estimation • • meriah  

  2
  0
  Votes
  2
  Posts
  1
  Views

  P

  I think the effort depends on the definition of "done". If QA is included in the definition of done, meaning a user story is marked as done only if QA is completed then the effort should include both development and testing efforts If the definition of Done is "Qualified for QA testing" then only development and integration/unit test is considered If, you are working on a separate test user story, independent from the development process eg in TDD. Then the only testing effort is considered
• F

  Need ideas/suggestions for validating test cases for a large web application
  web application manual testing • • fbio  

  2
  0
  Votes
  2
  Posts
  1
  Views

  

  First of all, you can't cover 100%. Now, the answer to your question is that prioritize your test case according to your web application. I.e. check the highest priority test case. Secondly, check with issues that occur mostly in the application. Thirdly, check the cases which can impact to other processes.
• D

  Difference between Corner Case Testing, Boundary Case Testing and Edge Case Testing
  terminology manual testing quality assurance • • derk  

  2
  0
  Votes
  2
  Posts
  2
  Views

  N

  Corner Case Testing: When the system breaks only for a specific valid input eg: Imagine a function getcar() that that takes a number and all numbers from 1-5 are valid inputs: But, getcar(wheel=?) function works with all numbers but fails for getcar(wheel=3) Edge Case Testing: Here we check that the system handles extreme values of valid limits. For the above example, the valid edge case scenarios are getcar(wheel=1) and getcar(wheel=5) Boundary Case Testing: Here we check that the system handles boundary values around the edge case values. so in the above example, edge case values are 1 and 5. So, the boundary cases would be 0,2,4,6
• T

  I started working as a Manual Tester in an IT firm. What practices should Iapply to be a good tester?
  manual testing quality assessment • • tahishae  

  2
  0
  Votes
  2
  Posts
  2
  Views

  B

  Start with mindset of below: Creative test approach. How I can break the code. Cover maximum functionality with Minimum scenarios. Learn Product and Functionality. (Be a functional expert). Document your product experience and Share with people around you. Adopt Devops Agile (You can google about them. Last but not lease. 7. Be Proactive in approach and neutral in communication