Experience types

Describe you experience within the following fields:

(We are not looking for a particular profile. There is no correct or inherently more desired
experience type. Please answer truthfully)
Products
These are the kinds of products where you
feel you would do a good job testing them.
Either because you have tested them
professionally or worked extensively with
them.
Feel free to list specific software products
and/or types of software products.
Domains
These are fields or areas which you have
experience or knowledge about where this
knowledge makes you better equipped to test
from the perspective of the user. This is often
tied to specific products but not necessarily.
E.g. you might have military experience
(domain) without ever having worked with
military software (product).
Other examples of domains could be banking
and finance, games/game development,
insurance, healthcare etc.
Technical
This is you experience with computers,
computer science or tools. This does not have
to be directly related to testing.
Examples could be programming experience
(languages), system administration,
databases, virtualization, tools etc.
Testing
This is your experience directly related to the
field of testing. Examples could be knowledge
of specific testing techniques or processes.
You could also list any
certifications/credentials you might have

Tester profile
Which of the following descriptions do think best applies to you? One does not exclude the others
feel free to associate with multiple.
(Again, we are not looking for a particular profile. One type of tester is not inherently better than
another. Please answer truthfully)

I associate with this type of test professional profile

(put one X in each row)

Administrative Tester. The administrative tester wants to move things along. Do the task,
clear the obstacles, get to done. High level administrative testers want to be in the
meetings, track the agreements, get the resources, update the dashboards. They are
coordinators; managers.
Technical Tester. The technical tester builds tools, uses tools, and in general thinks in terms
of code. They are great as advocates for testability because they speak the language of
developers. The people called SDETs are technical testers.
Analytical Tester. The analytical tester loves models and typically enjoys mathematics
(although not necessarily). Analytical testers create diagrams, matrices, and outlines. They
read long specs. They gravitate to combination testing.
Social Tester. The social tester wants you! Social testers discover all the people who can help
them and prefer working in teams to being alone. Social testers understand that other
people often have already done the work that needs to be done, and that no one person
needs to have the whole solution. A social tester knows that you dont have to be a coder to
test but it sure helps to know one. A good social tester cultivates social capital: credibility
and services to offer others.
Empathic Tester. Empathic testers immerse themselves in the product. Their primary
method is to empathize with the users. This is not quite the same as being a user expert,
since theres an important difference between being a tester who advocates for users and a
user who happens to test. People with a non-technical background often adopt this pattern,
and sometimes also the administrative or social tester pattern, too.
User/domain Expert. Not the same as user tester. User experts may be called domain
experts or subject matter experts. They often do not see themselves as testers, but as
potential users who are helping out in a testing role. An expert tester can make tremendous
use of user experts.
Developer. Developers often test. They are ideally situated for unit testing, and they create
testability in the products they design. A technical tester can benefit by spending time as a
developer, and when a developer comes into testing, he is usually a technical tester.

Not at all

A little bit

Very much

To some extent

Profile

Desktop Calendar Settings

The attached .htm file contains a feature that can be found in many digital calendars. The
feature allows the user to specify the time range that the calendar page should display. Defining
the time range for example only business hours - allows for more focused display of calendar
page.
The html file contains only the functionality of assigning the earliest and latest appointment
time. The specifications are as follow:

Earliest time and latest times start on any of 48 half-hour intervals ranging from 12am to
11:30pm.
The time range cannot span midnight therefore the earliest time must always precede
the latest time.
The client-side validation code must complain if the earliest time is the same or later
than the latest time.

Your task is to:

Test the validation code. Does the error message work properly?
Design a number of test cases that you find appropriate - use Table 1 for listing your test
cases.
Report any bugs you may find.
Briefly summarize your test results.

Earliest time
9:00 AM
9:00 PM
9:00 AM
1:30 AM
2:00 AM
2:30 AM
3:00 AM
3:30 AM
4:00 AM
4:30 AM
9:00 AM

Ending time
5:00 PM
5:00 AM
9:00 AM
7:00 PM
7:00 PM
7:00 PM
7:00 PM
7:00 PM
7:00 PM
7:00 PM

Justification

business hours
time range cannot span midnight
Earliest time equal to end time
Earliest time greater than end time
Earliest time greater than end time
Earliest time greater than end time
Earliest time greater than end time
Earliest time greater than end time
Earliest time greater than end time
Earliest time greater than end time
Earliest time later than the end
7:00 AM time.

Expected result

Final result

Success
Error
Error
Success
Success
Success
Success
Success
Success
Success

Passed
Passed
Passed
Failed
Failed
Failed
Failed
Failed
Failed
Failed

Error

Passed

bug
bug
bug
bug
bug
bug
bug

Note: The given code is failing during below mentioned time durations.
Earliest time ranging from 1:30 AM to 4:30 AM
Ending time ranging from 4:30 AM to 7:00 PM.
Few test cases are shown in the above table for reference.

Suggestion:
When User start time is selected, the latest time dropdown should auto update with all the possible
times value and rest should be hidden. This would downsize the possibility of user committing
mistake.