This post is about Outlook broken business feature, carbon copy recipients.
In e-mail, the abbreviation CC indicates those who are to receive a copy of a message addressed primarily to another (CC is the abbreviation of carbon copy). The list of recipients in copy is visible to all other recipients of the message. In common usage, the To field recipients are the primary audience of the message, CC field recipients are others to whom the author wishes to send the message publicly, and BCC field recipients are the others to whom the message is sent.[source]
Carbon copy feature in email is de facto a standard business rule. If you are implementing email client, you should implement cc feature in that way.
And here is Microsoft 2016 cc feature:
And here is received email:
You can not distinguish to: recipients from cc: recipients.
I received such an email, and replied to project manager to explain who is responsible for subject of his email. He replied (not very pleasantly, but that is the different issue) with highlighted to: in message conversation automatically attached in message reply, and that I should know the cc: rule. So in message reply, you can distinguish between to: and cc: fields. But not in original mail.
Can I move to other email client? Answer is no, because Outlook is mandatory tool in clients organization and I am obligated to use it.
Update after Facebook feedback (Thanks Vanja and Igor!)
This issue is not consistent with Outlook history, because in previous Outlook versions that worked. Also, Gmail is not adequate alternative email client for this feature, because gmail also does not show cc field.
After series of posts about How to kill UI regression testing, maybe you got impression that I am against UI browser automation test scripts. In this post, I will put my thoughts about the value of UI automation tests.
First some context. Here are requirements for excellent UI automation tests:
Language that enables you to write less code. Something like Ruby.
selenium web driver implementation in that language
framework just above selenium webdriver. For example watir-webdriver.
Page object pattern implementation
test framework, something like rspec. For writing awesome asserts.
gherkin implementation. Something like cucumber. No, I have not changed my mind stated here. But we have different context here.
continuous integration tool. Something like jenkins
headless browser. Something like xvfb or sauce labs.
What is the value of UI automation test scripts? They represent executable documentation for your product. They help you to answer questions about complicated business scenarios. For example facebook setting who can contact me.
Your testers will need to have a skill of writing DRY tests using those requirements. So when you have new tester on board, by reading those tests script, he can quickly learn application features.
Those tests would be run on jenkins and run should be triggered manually. Tests will provide you information is some automated feature changed. It is not wise to use those results for you regression testing strategy.
Because those checks, or asserts only check what is coded. Nothing else. And UI is for human users, not for test scripts. So human should always do smart regression testing , using its brain, eyes, ears and fingers.
In this post I will provide an example how we should be very careful during the root cause analysis. Because sometimes you need to dig deeper to find the root.
During the CAST 2016, I visited Dr. Sun Yat-Sen Classical Chinese Garden. It consists of part where entrance is free, and close part with admission and included park guidance. TripAdvisor said that you can spent there 2 hours. As this was rather small park, my thought was I am done in 30 minutes. But guided tour proved me wrong.
My first impression was with water that was muddy. I was rather disappointed. Despite that, kai fish were happily swimming.
Before the tour I got free garden tour flyer. I skimmed it and found this about garden water:
The cloudy, jade green pond-water creates a tranquil atmosphere and reflects buildings, rocks and plants. A special clay pond liner intentionally creates the opaque colour. Jade is the favorite Chinese gemstone which symbolizes wealth and purity.
How about that, water was muddy on purpose so all the garden artifacts could be better reflected in it!
Every garden item has a story and symbolic meaning, rocks, buildings, window shapes. Two hours passed very fast, and I spend observing objects in water for some time.
Continuous integration (CI) is last element that successfully kills your UI regression testing. In this post I will explain how CI system should fit in software development process.
There is always lively debate what should be automated in software development process. Pipeline elements of continuous integration should definitely be automated.
What are elements of pipeline continuous integration? Every command of operating system that you run as software tester is that element. And software tester usually run several of those commands in a pipeline as their daily task. Those os commands should be put in a script, and that script should become running element of your continuous integration tool (e.g. Jenkins).
Script can be Dockerfile or bash shell script. It depends on the technology that you use. The goal is to have one click button in your CI tool that will do following:
get the latest code from git branch (e.g. integration)
run development framework tests. Whole suite must run in less than 10 minutes. Otherwise, these are not development framework tests
deploy the application
run database migration and fixture files (hopefully, your development framework offers those features out of the box. Otherwise, find appropriate tool.)
Whole process must be done in less that 10 minutes.
Now you are ready to do you regression test strategy that includes:
observing changed files from last deploy using git pull requests and commits
investigating development framework test results, including test coverage report (be sure to know what that coverage means)
decide which end to end tests should be executed.
That concludes How to kill UI regression testing series. You will probably say, but I can not implement that in my project. That is ok, but now you know where should your project streamline in order to have better quality.
You have measure points for your project that can you use when you are asked:
Why we missed that critical bug?
How can we improve quality of our project?
On the other side, you can use this information in your interview for testing position or you can get information about the quality of a project that you are starting with.