We do testing because some of our colleagues will have made mistakes before us. This is actually expected and is a consequence of us being imperfect human beings. Part of our job as testers is to identify, without rancour, other's mistakes so they can be fixed. Organisations have to accept (or be taught) that testers won't find everything that's wrong with ...
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?":
It's not entirely clear to me whether you are looking to test the login system and/or application functionality. At a high level I would look to have:
happy cases - stuff works
sad cases - stuff fails as expected
You also need to set up testing throughout the process so code can be changed in the future, so you should have automation for
Text files and Excel sheets are fine, as long as you have an agreement with all the members of your team on the format. Definitely not the notebook - it’s extremely inconvenient when someone needs to replace you in this task for any reason and has no access to steps you’ve done beforehand, especially in exploratory testing.
Do you use a QA management tool ...
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 ...
Welcome to Humanity
Admit the failure, feel bad briefly, move on.
It's hard being human with all the biological reasons behind many of our behaviors.
You will be ok if you start practicing the following beliefs:
We are all human and we all make mistakes
We often learn more from mistakes than successes
The scientific method for improvement relies on being ...
Every software testing company uses both test automation and functional testing to handle these kinds of situations to cover 100% of the feature coverage.
However, if we don't have automated scripts then for those cases we can perform smoke, sanity and regression testing:
Smoke testing: In this, we decide if the QA build is stable and all critical areas of ...
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-...
We actually have a great solution for this case in PractiTest:
1. Create a test case with the sequence of steps that are going to be repeated;
2. Now you can use this sequence in any other test cases: for example, if you need to enter this sequence after the step “Switch from Payment Method 1 to Payment Method 2”, you just use “Call Steps from another Test” ...
CRUD operations are the root of Database testing qa services and we need to understand the meaning of the same with a common example.
Create – INSERT an entry into Database.
Read or Retrieve – SELECT the entry from the Database and then View it.
Update – UPDATE the entry completely or partially into Database.
Delete or Destroy – DROP/DELETE the entry into ...
This is a common question in a software testing company. However you can easily cover and manage 300 test cases of the application. Below are some of the points which will help you out:
1.1 Identify the critical modules of the application.
1.2 Prioritize the TestCases.(Like P1,P2....)
1.3 Re-factor the testcases.
1.4 Create Sanity and Regression test cases.
Every software testing company performs accessibility and usability testing.
Following is the main difference between both:
Accessibility testing: It is performed to ensure that the application being tested is usable by people with disabilities. Accessibility testing is a subset of usability testing wherein the users under consideration are people with all ...
It is not the requirement that the engineer should have the knowledge of manual testing before entering into automation in a software testing company. But it would always be beneficial if you have basic idea about manual testing things like:
1. Defect reporting
2. Test case creation
3. Regression Testing
So before entering the automation part if ...
Writing testcases has its benefits, but you may not have time to write a really verbose test plan. I sometimes just had my scenario in the testname only and be done with it.
If you leave the project midway, the written testcases will help the new member filling in your shoes, while he does regression on the overall project.
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.
Prioritize the critical test cases and time consuming test cases. Share those test cases to the testing persons who executes fast and correct.
Then give the medium test cases to other persons who have good knowledge of the project/ product.
Then aggregate the low priority test cases and give to the remaining testing persons to execute.
For most test cases depend upon your choice to which one you have to execute first and later on. For large test cases, mostly it needs to be prioritized.
First: prioritize the test cases.
Second: Check which cases/issue affects most of the module.
Third: Go for newly fixed issues for modules.
I think service availability shouldn't be addressed with traditional testing. When would the corresponding tests run? Per hour, per minute, … ?
Instead, monitoring is the way to go. You can use tools such as Uptime Robot to receive alerts whenever a service is down. In addition, use something like Sentry to be notified when internal exceptions occur.
As for format, again, it really comes down to what is most helpful for you and your consumers
That is true! For us we had some struggle with our customers. Because the customer was complaining that testing was not "visible" within the department. Hence we decided also to add exporatory testing but with Kanban Board (at the same time it was also our bug ...
What worked for me was actually reversing the process. I first started doing testing and then I slowly started building up my knowledge of concepts and technologies. I don't think this works universally (what you test makes a difference, e.g. testing an airplane system vs. testing an ecommerce platform are two very different products and you need different ...
As per my experience in the qa services, the practice 'Repeat steps 1 to X' can be followed while creating test-cases with repetitive steps.
The only thing we need to make sure is to provide the test-credentials separately for each test method.
The other approach that can be followed, is to segregate those common steps in one section and that section can be ...
I've been testing embedded devices since 1999, and I started from scratch as a manual tester and I'm now a full-time automated test software engineer developing both tests and systems / frameworks, so I hope I can offer a little perspective from my own viewpoint.
I started out testing credit card machines (entirely manually), moved to mobile phones (mainly ...
Usability testing is to understand if your product is actually usable by the target audience of the product (whether it is web site, app, hammer or stairs). Note that it may mean that you may largely ignore groups of users that are not in your target - i.e. testing an app for "drivers with paralyzed left hand" you may not need to include legally blind person ...
No, it is not necessary but, I would say it is beneficial.
Knowing the basics in testing is mandatory because, with the experience of test processes, test scenarios, test cases, test steps, and execution, you will be sturdy to write automated test scripts more efficiently. The transition will get smoothened if you start your career with manual testing and ...
From my perception, usability and accessibility are terms usually misused and confused. These two plays an essential role in enhancing UX and performance of a product, so these two are a critical quality indicator for interactive products/systems.
I believe that you have learned the difference between these two. The principal benefit of conducting ...
Corner Case Testing:
When the system breaks only for a specific valid input
Imagine a function getcar() that that takes a number and all numbers from 1-5 are valid inputs:
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.
As others have said, usability refers to the ability for people to successfully use your product. Accessibility refers to the ability for people with disabilities to successfully use your product.
Do you notice something about these two things? Yes... One is a subset of the other. Unless you define "people" as excluding those with disabilities, then ...
First, you have to understand the difference between UX and UI
In simple words
UX: Focuses on designing a UI that enhances the user experience. Means it ensures that the UI design is designed with ease of use, easiness in Accessibility and feel in looks.
UI: On the other hand, ensures endpoints for a user to interact with the product.
So a simple UI ...
Below is the difference:
Accessibility refers to the website is available and can be easily accessed by a normal person or even disabled person. Accessibility testing focuses on testing if the website is accessible to disabled people and can be used by various tools used by them.
Usability means to deal with how easy and intuitive a website is to use. If ...
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 ...
You might argue they are the same - if you cannot access something you cannot use it and if you cannot use something (in a meaningful way) you cannot really say it is accessible. It is a thin line between those terms, at least linguistically.
However, those terms usually mean something specific. So, accessibility in the context of software development and ...
Learn and practice.
You can start learning from various books and blogs. Here are some post suggestions for those:
Parallel with that, start actually practicing your testing skills. See these posts.
After that, you might invest some time in tools and automation, if that is what you are after.
This answer does not provide the exact definitions, just the
1. Accessibility Testing
Testing carried out to verify whether the application is user-friendly to the physically disabled user.
For example, we can consider the Kindle e-book application. For this application, we check whether the application has the feature to read the e-book ...
Large number of test cases generally means some of them are ignorable or plenty of them depends on your test case making and extent of the effect of feature on the system you are testing.
Firstly, you will look for the major cases in regression if they pass or not, you will try to check things are not exploding when running major things. That may compile to ...