There are many ways to expend the knowledge as a QA:
Read QA blogs.
Read Testing books.
Hone your QA skills by teaching others.
Go to Meet-Up & grow your network.
Search & Read the Research Papers.
Go to the Conference & Company Seminar.
One of the best ways to learn Ask Q/A on Stack Exchange sites.
Work on Open Source /Crowd Testing Projects. (...
User acceptance test (UAT) criteria (in agile software development)
are usually created by business customers and expressed in a business
I don't think Field Length Validation has anything to do with User acceptance testing. Maybe the business should write their own tests.
Never the ...
You should consider time-boxed exploratory testing and risk-based testing - both approaches have their benefits and compliment each other if you're able to execute them both.
Exploratory testing is an approach to software testing that is concisely described as simultaneous learning, test design and test execution.
Risk-based testing functions as an ...
It depends. If you're doing the same testing, over and over again, some people will get bored with that. Others like that sort of stability, but are likely to see little career growth, because they aren't increasing their value to the product/company.
I think you need to look at things in a different way, though. Your job isn't to test the ERP, RMS, and ...
Test open source software and report defects on Github. Maybe start with the top open source applications, you might already be using some.
Try to answers questions here on SQA.SE. If you cannot answer them do research (and create a proof of concept) until you can. This helped me greatly.
Read testing blogs
Read testing books
My personal opinion is that ...
The cynic in me feels that if developers could be relied on to detect & fix their bugs as they go along then separate testing teams would never have been invented in the first place.
Much zealotry in this thread...
How can QA honestly identify their own strengths and weaknesses?
Education and comparison
Go to meetups
Go to conferences
Work at different companies
Ask and Answer on Stack Exchange sites
Do enough of the above and you should have a pretty good idea where you compare to others in those books you'll have read and in ...
Many testers before have asked this question already. Here are few links (blogs & video):
Katrina Clokie - How do you become a great tester?
Christin Wiedermann - SMARTER TESTING THROUGH SMARTER TESTERS
Zeger Van Hese - The Power of Doubt – Becoming a Software Skeptic
Helena Jeret-Mäe - How to Start Learning about Testing
I cannot find the link of ...
If character lengths are changing I would suggest boundary testing
For example I would consider testing:
I would retain the following as regression tests going forward:
It can be tested in any of the below two ways:
You can do API Testing of Student Marks and Student Results Module.
The developers must have used some kind of dummy Student Marks Data to develop Student Results Module.
You can use the same or similar dummy data of Student Marks so that you can test Student Results module.
Yes, it is possible to use test design techniques to test edge and corner cases.
Boundary Value Analysis (BVA) and Equivalence Partitioning (EP) are useful for testing input data to verify the output results. For these to be valuable, you need to understand what the boundaries are and how the data is partitioned between the boundaries.
For more thorough ...
I would like to prefer the Equivalence and Boundary Value for each field.
Just above the minimum,
A nominal value,
Just below the maximum,
While providing the input, I hope application should consider spaces between the words should be a character
If it is non -required field check with NULL/EMPTY values and try to update some charters ...
There are a few practices and concepts that are very important to iterative design.
First, there should be a refactoring step in every iteration. This allows space for improvements to be implemented so you are not stuck with design decisions that the team has outgrown.
Second, the team should be building with an architecture that is as decoupled as ...
Most Agile approaches suggest Test-Driven-Development, but at least you should practice some form of technical excellence to satisfy the following Agile principles:
Continuous attention to technical excellence and good design enhances
Personally, I like the LeSS approach to technical excellence. ...
if in the beginning a bad design is chosen and the subsequent steps are always based on it, in my opinion it can also run very badly.
The whole point of iterative design is to be able to observe those bad decisions and be able to act upon them sooner then later. The team evaluate their design and implementation in each iteration,
when the design is "by ...
The must read book for Agile Software Testing is Agile Testing by Lisa Crispin and Janet Gregory. It is generally recognized in the modern Agile Software Quality Assurance field as 'the bible' on what to know and what to do.
As for the 2011 syllabus you 'came across'. It might be relevant but why not study the current syllabus. In a profession where we ...
I would consider documenting these in a TDD/BDD language/tool
For example in Cucumber (which now works in something like 50+, languages)
$ sudo apt-get install cucumber #(ubuntu)
$ mkdir some_test
$ cd some_test
$ cucumber init
Now create the file features/some_thing.feature
Feature: weekend check
Everybody wants to know when it's the weekend
I don't think there is a standard way to do this. I don't know about a best way, but some ways i can think of the top of my head:
excel sheets/text files/tldr email with detailed instructions what and how to test, basically writing test cases for everything to manually reproduce.
userstories: just add in your stories what was actually implemented and pass ...
Every person is having some weakness and strengths. But in professional world every person want to be less prone to mistakes. For achieving this QA tester have to keep in mind below mentioned points and should try to implement in qa services:
If a mistake is repeated then QA should make a checklist of that areas and should run the same whenever testing a ...
First, to know whether you are a good tester or not (or you have tested a product well or not), the scale to check is the number of bug slips. If the number of bugs from the client / user end is more, and you had missed them in QA, SQA, UAT, Mock Live envs, then the number of bugs speak something isn't it?
And to understand the strength and weaknesses, both ...
Try to proactively look for potential problems ahead of the actual testing. Several sources: Any errors which pop up in products you tested - and find out how you could have avoided it. Errors which others in your company or field missed before. Errors associated with any changes in how your company does things (new approaches in management, development...). ...
I was faced this situation, At that I was escalated to my management team and I took the decision to stop the delivery but management is not willing to stop the delivery because they have committed the date with the client Then the decision is happened in quite some time and finally they decided to release the build with the known defect. I was not happy ...
How about making one member of the programming team work as tester (or quality improver) for a month or two, and then rotate them out for another member of the team (as mentioned in another comment already)? Unlike 'normal' testers, they will not only understand better what to look for (on a code level, for instance), but also be able to help automate the ...
If you cannot have your way, try to go for a compromise that satisfies both stakeholders, you (and perhaps your team*) and the corporation management.
I actually often find a mix rather helpful, where the team has some internal QA people that do in-development testing, but that also coordinate with external testers for final release testing or production ...
If you cannot finish a PBI in one sprint, it is too big and needs to be split up into smaller parts.
Finishing a PBI means it has to be shippable and conform to your DoD, which normally means it has to be tested.
There is absolutely no reason why a team couldn't build and test in the same sprint. If you have a good DoR, a tester can start preparing tests ...