Earlier this year, I had a chance to work on a proposal for a remodel of the mobile website for Sinclair Community College. I reviewed their current mobile website and developed wireframes (using JustInMind) for both phone and tablet to show an updated and more streamlined mobile website.
I presented this idea to a small group from Sinclair and they had very favorable comments about this new look. Although I did not have the opportunity to actually work on this project, I really appreciated the challenge and learned a lot in a short time.
SELECT table_name = OBJECT_NAME(parent_object_id) ,
trigger_name = name ,
trigger_owner = USER_NAME(schema_id) ,
OBJECTPROPERTY(object_id, 'ExecIsUpdateTrigger') AS isupdate ,
OBJECTPROPERTY(object_id, 'ExecIsDeleteTrigger') AS isdelete ,
OBJECTPROPERTY(object_id, 'ExecIsInsertTrigger') AS isinsert ,
OBJECTPROPERTY(object_id, 'ExecIsAfterTrigger') AS isafter ,
OBJECTPROPERTY(object_id, 'ExecIsInsteadOfTrigger') AS isinsteadof ,
CASE OBJECTPROPERTY(object_id, 'ExecIsTriggerDisabled')
WHEN 1 THEN 'Disabled'
END AS status
WHERE type = 'TR'
ORDER BY OBJECT_NAME(parent_object_id)
This works great – very handy to have when you need to see what triggers are on what tables in your database!
PS – I used the
tag in the HTML view to ‘force’ the single quotes to behave correctly in the code snippet above. Thank you to HTML Goodies
for a great article on this!
PSS – I should also add that I great information with these 2 articles regarding triggers – UBER-helpful!!
Software testing tools – just the bare-bones basics…
- Test plan – this is a test specification. Knowing that a car will be tested to drive at a speed of 60 miles per hour helps the developers of the car to design it in such a way that it does indeed drive at a speed of 60 miles per hour.
- Test script – this is a piece of programming code that replicates user actions.
- Traceability matrix – this is a table that is used to change tests when source documents are changed
- Test case – this is a defined input with an expected result.
- Test suite – this is a term used for the collection of test cases, often including more detailed instructions or goals.
- Test harness – software, tools, samples of data input and output, and configurations are collectively known as a test harness.
There are many (a lot!) different types of software testing. I won’t go into any of them in detail, but just wanted to familiarize myself with some of the terms and the basics.
- Installation testing – this ensures that the system is installed correctly and working properly at the user’s hardware location.
- Compatibility testing – this checks for correct operation between application software when systems or environments are upgraded from the original, possibly causing other pieces to not work correctly.
- Smoke testing – this is a minimal attempt to operate the software and is used to determine if there are any basic problems.
- Sanity testing – this determines if it is reasonable to go ahead with further (more in-depth) testing.
- Regression testing – this focuses on finding defects after a major code change has happened.
- Acceptance testing – this may be performed by the customer and is part of the hand-off process between phases of development.
- Alpha testing – this is a simulated or actual operational test by potential users
- Beta testing – this comes after alpha testing and may be a form of external user acceptance testing.
- Functional vs. non-functional testing – this is an activity to verify a specific action or function of the code (does this particular feature work?).
- Destructive testing – this attempts to force the software to fail and verifies that the software functions properly even when receiving unexpected inputs.
- Performance testing – this is used to determine how a system performs under specific workloads (responsiveness, large quantities of data, large number of users, etc), and there’s a whole set of sub-tests (load, volume, stress, stability – and sometimes these terms are used interchangeably).
- Usability testing – this looks at the user interface to see if it is easy to use and understand.
- Accessibility testing – this relates to standards associated with the Americans with Disabilities Act of 1990, Section 508 Amendment to the Rehabilitation Act of 1973, and the Web Accessibility Initiative (WAI)
- Security testing – checking for security!
- Internationalization and localization – this looks at translating software into different languages, keyboards, fonts, bi-directional text, and date/time formats.
- Development testing – this supports QA testing and is executed to eliminate construction errors prior to code going to QA.
- A/B testing – this is a comparison of two outputs, usually when only one variable has changed, typically used in small-scale situations.
- Concurrent testing – this focuses on the performance when running continuously with normal inputs.
- Conformance testing – this verifies that a product performs according to its standards.
Whew – what a list! I really didn’t realize all of the different types of testing. I think I intuitively have done some of these things before, but didn’t know that it had a specific name.