from The Learning Revolution
The system should have the intelligence to know how to make itself secured based on the information available.
When we ask for integrated security from one system, we are asking the system to honor the setup already done in another system.
From a software designer's perspective, we need to think of why one system is a more appropriate place to maintaining the security grant related information. Typically, this answer to this question is somehow relating to the business flow.
It is not uncommon today that a single directory service is available for the whole enterprise.
A very basic integrated security requirement is to honor the directory services to not require having separate maintenance of the directory in every system. The directory should provide very basic information:
- A person record that can identify the person
- Some information can authenticate the person, ex. password
- Some information can contact the person, ex. email, phone, mailing address, etc.
- The role the person plays in the enterprise, ex. organization unit, job title, etc.
- How the person is related to the enterprise, who the person is working for. ex. manager hierarchy, etc.
By having these information available and maintained in a central place and honored by various systems, we have integrated security.
- Publish the contact information
- Ownership information
- Collect the basic deployment information
- Software version
- Patching level
- Monitor the status of each instance
- Schedule the maintenance
- Link to the service request system
- Link to the change management system
- Collect the past historical information
- Provide the Reporting tool
- Perform various checks
For software that are delivered as both cloud service and the independent software, there are two layers of testing. The software is first tested by the software QA and then tested by the team who test the software for cloud.
When the software is tested for being deployed in an on prem env, we need to consider much more deploying environments. The hardware could be different. The size could be different.
When the software is tested for being deployed as a cloud service, the hardware is standardized.
The 1st run of the testing by software QA does not have to be complete before dropping the software for cloud deployment. The reason is that cloud env is a closed env. Only the particular configuration that is being used in the cloud env needs to be tested first.
It is given for updating the progress. The information is mainly for the consumer or for the people who are in charge of the downstream process.
What is the ETA? This question is asking when the task will complete?
In the project management technique, for progress update and for forecasting, we use ETC or EAC.
ETC = estimated to complete
EAC = estimated at completion
The EAC is similar to ETA if we are talking about time or schedule.
ETC or EAC can be represented as costs or efforts.
ETC is the remaining work
EAC is how much we will need at the end of the project
Heart beat report
Not just for human.
These are critical for ensuring the system up and running. Provide a cron job to monitor the system.
Before running the ETL process, check if the source data is correct. Asking the users to fix or prepare the data before running ETL.
Checking if required setup is there, if the system is configured, before letting people use the system.
Before upgrading or applying patches, check if the system is healthy.
After upgrade or patching, check if the system is still healthy.
Some of my first impressions:
1. It makes SQL Developer look like an ETL tool, such as Informatica or ODI, or a data quality tool like EDQ.
EDQ allows you to review the data step by step. You can also view the data as the results of given step in SQL Developer.
Informatica allows you to view data row by row via debugger. A tool like ODI, EDQ, or Data Miner, supports the Set process.
2. It also support the diagram tools.
Viewing a histogram is so easy.
It reminds me when I first learned Minitab in college.
The Introduction to Statistics course can use SQL Developer to teach some basic concepts and statistics, I think.
This is kind of like a project is still in the initial phase. The bucket is identified but the work has not been elaborated. The final product may not be known in a detailed way to start identifying the work. However, for tracking purpose, you would like to enter somewhere and recognize it.
All bug should be reviewed and the regressions should be identified.
Identifying and fixing regression issues is important as it involves the creditability of the company and the products and it generates frustration to the users of the software.
A development team that generates the software regression may have process or quality issues.
Development managers should monitor the trend of the regressions reported.
Developers should analyze the root cause of the regression. Which product feature changes or which bug fixes caused the software regression.
If a software is shipped with software regression, it means that there may be a test case missing is the regression testing.
Regression Analysis and Resolution Lifecycle
- Customer file a service request
- Customer support files a bug
- While the developer is analyzing the issue, if the defect is confirmed and the developer suspects that there is a software regression, flag the bug with the regression status as 'Candidate'
- If the problem exists before in the GA version and the current version, it is not a regression, the regression status should be set as 'Not a regression' It is a problem not previous caught.
- After further analysis, and the bug or code change that causes the regression is identified, the regression status should be set to 'Confirmed'. The original bug number(s) should be recorded. A comment should be given to describe why a regression happens. "Lack of training', 'Missing in the design', 'Process Improvement', etc.
Regression test related lifecycle
- The regression test status should be recorded to indicate whether a test should be created.
- After the regression test is created, the regression test can be closed from the QA perspective.
This is the close loop analysis from QA perspective.
Initially when I first become a software engineer, there is no such function. Sustain engineering is part of the duties of the regular software development groups. Sustain Engineering gradually become a separate function.
The sustain engineering team is handling the products that have moved into production. The sustain engineering team monitors the product throughout the rest of the lifecycle until the product terminated and becomes obsolete.
Sometime people refer the sustain engineering team as the maintenance team.
The nature of the work could be different. The work tends to be more ad hoc and more issue-oriented. In other word, the every day life of the members in the sustain engineering team is dissimilar to the core development team which is more project based, with the scheduled activities. It could be rewarding too. The sustain engineering may see different challenges and may have a bigger coverage comparing to the software engineers that are assigned in the core development team. Within a year, the member of the sustain engineering team may touch different part of the products while the members in the core development team only work on one or two projects within a specialized functional area or technologies.
A typical reason why a bug is deferred since fixing it does not give us significant returns than the investment (ROI). The deferral decision is a business decision and should not be made by the developers themselves.
Deferring a bug means that we leave a known issue to the product and we do not fix it.
Typically we have the following justifications:
- It is a corner case.
- The particular usage scenario is not common.
- There is a workaround available.
- We will provide a patch to fix this problem immediately after the release.
The following are excuses but cannot justify unless we can one of the above reasons:
- It is too late to be fixed in the development cycle of a release.
- It will introduce significant delay of the release.
One of the important considerations other than just the delay of the release is the risk to the release.
Fixing a bug may introduce other bugs.
Fixing a bug is not just a development effort. The test may need to be executed again.
The risk may not be just a schedule risk, but a quality risk.
This is similar to the phase gate in the project lifecycle.
Some people also define the "Entry Criteria" to indicate when a phase can start.
Here are some samples:
- Functional Design and Technical Design Specifications have been reviewed and signed off by stake holders.
- User Experience Review and Signed off
- Coding Complete
- Testing Complete
- Translation (i18n)
- Documentation is ready
The coding work can be categorized as follows:
- The coding for the new key features as described in the release content.
- UI - Front End
- Back End Process
- Model / Database
- Batch Process
- Forward Porting of the bugs fixed in the prior release by the sustaining engineering team
- Platform Porting (if supporting multiple platforms)
- Upgrade / Data Migration
During the course of the project, the work can be measured by percent complete.
Sometime the percent complete method is too subjective. A alternate way is to break the work into smaller units and measure three status : started? work in process? completed? and assigned, 0%, 50%, and 100%. The total percentage can be a rolled up based on the weighted average.
Testing (coverage) are complete
Here are some of the typically testing categories:
- Installation (for new customers)
- Functional Test (For new features)
- Integration / Interops
- Regression Test (for existing, old features)
- Performance Test
- Stress Test
- Platform Certifications
- Upgrade (for existing customers)
- Security Test
- Accessibility Test
The overall progress of the QA testing cycle can be measured by the backlog of the bugs to be fixed in the queue. Which can be further converted # of days of the backlog based on the fixing rate. For examples, typically 2 bugs fixed per person each day and five resource in total. The 100 bugs can be fixed in 50 person days. It means that we have 10 days of backlog.
The incoming rates can also be a good leading indicator. Initially the bugs logged per day may be high. After the testing has been done for a while, the number of bugs logged per day may be reduced.
Deferral rate is a good measurement. A exit criteria can be the deferral rate is less than 10%. The deferral rate can be further broken down by priories (P1, P2, P3, etc). Deferral means that the bugs found is the testing cycle is not being fixed. Deferral rate is too high means that the issues are passed to the future releases. It also means that the list of known issues are high.
A release is more than just engineering and testing. Other than the above typical development work. Here are some of the release exit criteria
- Export Compliance
- Security Compliance
- Third Party software license
- Product's bill of materials
We may need to consider other activities as part of the release readiness:
- Demo Env and build the demo scenarios
- Field Readiness - Sales and Marketing
- Analyst Briefing
- Press Release
- Partner training
- Support training
- Hand Over to Sustain Engineering
- Please describe what you did
- If you are blocked, explain and get the team to help
Bi-Weekly SPRING meeting
- Close the tasks for the prior SPRING cycle
- Retroactive: What are the lessons learned and what can be improved
- Add and Edit tasks for the upcoming SPRING cycle
- Assign Tasks to owners
The mainframe apps were running as hosted apps. At that time, hardware business is also software business. The users were using terminals to access their apps.
We later moved to the client/server model. The desktop computing ago come. Two key technologies enabled this client/server computing: Wintel PC and LAN. The benefit is to empower the end users.
Later, we found that client / server is a maintenance nightmare. It is when the client / server model was modified to the "thin client" or to the three tie model.
Web based computing come about the same time. We then moved the thin client part to web. The degree of using browser varies. Gradually people found out putting logic into browser is not a bad idea. That's where Web2.0 kicked in.
Now, we are in another paradigm swift. The key driving technology is the network bandwidth is reaching a point to let us to run the apps over Internet. At least, we now know better about mastering it. Of course, there are computing technologies as well, such as virturalization.
Unit testing is part of coding. I learned from day one when my mentor told me at that time when I start my career in software development.
Coding is not done if unit testing is not done.
Unit testing may involve writing codes. We write codes for testing our codes.
In the modern software development tool, unit testing codes can be generated and we can simply run it after coding work is done. It is not always the case, however.
Unit testing cannot replace system testing. Unit testing is to test a small unit of the software. While the unit A and the unit B both pass unit testing, unit A and B may not work together.
Unit testing is important since when we test features or test the integration, the unit testing error may becomes the bottleneck. It introduces higher costs and the delay to the system testing schedule. A developer should feel shame if an issue is found in the system testing when it can be found in unit testing.
The challenge of unit testing typically comes from the the lack of the testing env. The unit may rely on other units.
Developers do not do proper unit testing are typically not because they do not like to, it is typically due to the overhead on setting up the env.
A unit testing env should be provided to ease the unit test work.
Since we continue making the changes to software for introducing new features or fixing bugs, the changes may accidentally introduce bugs which cause the other existing features that were working become not working.
Regression testing is the way to detect this type of issues.
Regression testing should be automated if possible.
Ideally it should be executed every day.
The problem needs to be uncovered as early as possible.
The test cases used in regression testing are typically not new test cases. They are the test cases used in feature testing.
Obviously the test case can become invalid since the product feature may change. The test case should be associated with the product feature somehow so when the product functionality changes, we remember to up date the regression test.
Here is a good article. - Regression Testing with Regression Testing Tools and Best Practices. I agree every single word described.
Some people are good at solving issues.
Sometimes those people who are good at finding issues cannot show their values as the issues they found are ignored or overlooked by the organization.
Sometimes they are afraid of raising issues and telling others.
Some people good at finding issues but do not know how to express themselves or do not know how to properly express themselves at the right time and in a right way. They may get some recognitions but won't get the credits.
Sometimes those people who are capable to solve the issues are not solving issues for some reasons, such as lack of the motivation or wrongly assigned to different tasks.
There are people who are lacking self awareness or organization awareness.
There are good observers who can monitor organization and find the above mismatch.
There are action takers who know the above organizational issues and can act on it and fix the organizational issue.
We call those people managers.