Closed dialex closed 1 year ago
Rapid Software Testing definition:
βTesting is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.β
Itβs important to remember, as testers, that these boundaries are put into examples because they are core to what the business wants to deliver. They are not there as boundary value tests.
on BDD
Even if I run the most simple and shallow of tests, if it reveals a bug, helps me come up with a new test idea, or reveals some information that is new or useful to me, then itβs a good test. This doesnβt mean that I can solely rely on simple or shallow tests. -- Mark W.
Accessibility (a11y):
Black box testing
This is a βboxβ that takes some input and gives you some output. You donβt know whatβs going on inside. Because we donβt have a direct knowledge or control over whatβs inside we can only try to interact with it and observe the behavior.
As we gather our observations, we also need some evaluation rule(s) to make a judgment β is there a potential problem? ORACLES
Note that a perception of a problem will be different for different people. Therefore testing, being a service, must not rely solely on the testersβ perception of the problem. QUALITY DEF
-- http://automation-beyond.com/2016/08/30/on-white-box-and-black-box-testing/ β
White box testing
We see the code. We can read it. We can infer what itβs supposed to do. We can mentally execute it and identify possible issues. The code is in a transparent βboxβ. Or a βglassβ box. Which, eventually, to contrast it with Black Box testing, became a White Box testing term, albeit slightly misleading in this form.
-- http://automation-beyond.com/2016/08/30/on-white-box-and-black-box-testing/ β
Acceptance test
Acceptance Criteria are conditions which a software application should satisfy to be accepted by a user or customer. Often these can also be used to guide the testing for a testing team. If the acceptance criteria are met, then the story has passed. The thing is - acceptance criteria has its limitations.
-- https://nickytests.blogspot.com/2017/05/the-limitations-of-acceptance-criteria.html
QA and Business analysts should take the stories chosen during the planning meeting, and turn them into automated acceptance tests. Programmers use the acceptance tests as requirements. They read those tests to find out what their stories are really supposed to do.
-- https://sites.google.com/site/unclebobconsultingllc/tdd-with-acceptance-tests-and-unit-tests
In our world, we need to come up with ways to convey our intentions and ideas clearly so we are not misunderstood by our colleagues. In software development, acceptance criteria aid the development team in knowing the expectations for a certain feature.
Why?
Who?
These are normally written by the product owner and reviewed by a member of the development team to ensure that there are no technical constraints and/or inconsistencies from a development perspective. In my team, it is first written by the product owner, then reviewed by a developer for the technical constraints, and finally a QA specialist for their knowledge of how the new feature should interact with the current system.
How?
There are multiple ways to write acceptance criteria. Our team prefers the scenario-oriented format as the team gets a better understanding of the requirements compared to one sentence scenarios. Given/When/Then format
-- https://thelifeofoneman.com/how-to-write-acceptance-criteria
User Story 1
Acceptance Criteria
Limitations
You are expecting someone to know in advance, before seeing the software, exactly how the software application should be. So if you are testing strictly against the Acceptance Criteria - you are in essence trusting that, that person (or group of people) who wrote the acceptance criteria knows everything about what is needed before the software is built.
Types