Software Technical Review

In class we did a group activity which had us work together in teams of five and conduct a software technical review. In a software technical review you have a specific role in which you must fulfill specific duties. There are four roles. The producer, review leader, recorder, and reviewers.

Producer–  The producer is the person who created the work that is being reviewed.

Review Leader–  The review leader schedules the review meetings, prepares materials for meetings, conducts meetings, and writes the review report.

Recorder- The recorder’s job is to take notes of what is being said. They also document anomalies, decisions and recommendations.

Reviewer– The reviewer(s) job is to prepare an individual reviewer issue sheet that is given to the review leader before the meeting. The sheet contains all of the issues that the reviewer found with the code.

There are three different types of software technical reviews. The walk through, technical inspection and an audit.

Walkthrough- A walkthrough is an informal meeting with the producer and the colleagues. There is little preparation and little documentation.

Technical Inspection- A technical inspection is a formal process and includes training.  There is sufficient and budgeted preparation time and the team ic very carefully selected.

Audit– An audit is a review that is held by an external group. The purpose of audits are to ensure that you are conforming to standards.

Why would we waste our time with such a complicated process when we could just look for faults individually? Well, there are many good reasons why we hold reviews and why the process is so important.

Reviews push developers to communicate with one another, it gives an opportunity to train new employees, it helps management report progress in the business, you find defects, it builds team morale and it gives the customer reassurance that the product comes out the way it should.

Going into your first review is probably nerve wracking. If you can remember the proper review etiquette, you should be golden!

Be prepared– There is nothing worse than an unprepared team member

Be respectful- it is the golden rule after all. Review the product not the producer.

Avoid discussions of style- Not everyone likes the same thing you do, as long as it is not wrong leave it be.

Provide minor comments to producer at the end of meeting 

Be Constructive- help others, don’t bring them down.

Remain focused- identify issues and don’t try to solve them yet.

Participate- Do not try to get the spotlight, it can be annoying.

Be open- the results of the review should be available to the entire organization.

 

My source of information was our class slides, but you can learn more about software technical reviews here:

http://www.softwaretestinggenius.com/understanding-software-technical-reviews-strs

From the blog CS@Worcester – Rookey Mistake by Shane Rookey and used with permission of the author. All other rights reserved by the author.

Ministry of Testing Podcast

The Philosopher and the tester

In this episode of the ministry of testing, Israel Alvarez talks about his transition from a philosopher background to becoming a QA tester. He believes there is a lot of positives from his philosophy background that has helped his career as a software context driven tester. Philosopher raises topics and concepts that forces you to think and so does testing so it was fairly relatable and easy to apply his acquired skills from philosophy. Being able to critically think is key to becoming a great QA tester. Knowing what to test for and how to test for makes this arguably one of the hardest things to do. Often as a tester, you have to analyze your own thinking, many times risking the analysis paralysis syndrome. As a math and philosophy major, Israel was always faced with problems that often didn’t have plan cut simple solution so he always had to try and apply what he had learned to get the job done with thinking outside the box. That’s what makes testing so hard. Its easy to come up with some things to test in a code or program but finding out things that need to be tested requires a thorough understanding of the product or software that is being developed. You often need to understand it even more than the creators of the product. They only way you can adequately test a product is to find its boundaries, applications and purposes and see what you can do to challenge these thing or break them. In a start up for instance, there are deadlines, scope changes and many challenges’ that testers have to endure. Proving your value as a tester is very important in the early stages of testing. Learning to articulate and defend ones view, as a tester is an essential skill that every tester needs to have to grow. This is a major challenge because developers often have to prove their point and findings to the programmers. Programmers often have strong views and passion for their work and in order to properly nit pick and criticize defect or bug that is in their work, you need to be able to establish yourself and emphasize overall product quality in your defending’s. As a tester, developers often have stressed feelings towards your work. It’s just the nature of the job as a QA manager or tester. It’s your job to ensure that the developers have put out the best possible product or software they can produce.

 

Source

https://soundcloud.com/ministryoftesting/the-philosopher-and-the-tester-israel-alvarez

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

38. How to be a Programmer: Personal and Team Skills

 

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, the gang talks about what it takes for someone to become a good programmer for his company and his team. One thing that is known to be a problem of the technology world is the lack of people with adequate teamwork and collaboration skills. I picked this particular podcast episode because I felt this would help anyone who reads. They talk about personal skills and practices that just makes one a better programmer in the industry. The main problem that occurs during team tasks is estimating how long a coding task will take. You want to please your boss and he also wants to please his boss so understanding each other and establishing that mutual trust makes it easy to work coherently in the task at hand. One challenge that most programming teams experience with their leaders is scope creeping. Scope creeping is a project management term that refers to changes, continuous or uncontrolled growth in a project’s scope, at any point after the project begins. This can occur when the scope of a project is not properly defined, documented, or controlled. It is generally considered harmful. This is because it causes problems and situations that are often not accounted for. Usually with every programming project, specifications are laid out and a timeline estimate is created for people to adhere to but once the scopes begin to change, unaccounted scenarios begin to happen. As a programmer, great communication between team members and leaders brings success to the project. This is because everyone has different level of expertise and often tasks and timelines are drawn based on the programmer’s expertise. Another thing that needs to be accounted for is vacations and sick absences. It’s the task of the programmer and team members to show commitment during tasks. You cannot take a 2 weeks or 1 week vacation when you know that the team is waiting for you to build the baseline site for people to continue developing on. This strings back to the trust issue. Efficient communications has to be open between members of teams to properly resolve issues such as these. Again communication thrives in teams when everyone is on the same level. Usually in teams, everyone has different background and finding that middle ground to communicate effectively helps the team thrive.

 

 

Source

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net/38-how-to-be-a-programmer-personal-and-team-skills

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Clean Architecture – Components and Component Cohesion

Episode 71

Coding blocks podcast is presented by Joe Zack, Michael outlaw and Allen Underwood. In this podcast episode, they squad begin by talking about components cohesions in architectural designs. Cohesion in software designing refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves. Cohesion is an ordinal type of measurement and is usually classified under two categories, “high cohesion” or “low cohesion”. According to the team, there was a principal known as the fish bowl principal, this was employed in system building and architectural design for so many years. It was believed that the fish would eventually grow to fit the bowl it was placed in. But that has changed over time, with services like AWS and other cloud functionality, developing software of any size is easily manageable. Scalability is often handled by high performance systems that allocate resources to where is it needed most and vise versa when it’s not in demand. A big part of this new trend of software reuse is propelled by the open source project that currently runs the software industry. Building components or software in components also propels this new trend of code reuse. This is because in components, code is built to be self-dependent and sufficient to run on its own. It is viewed as a module that fits a part of the big puzzle. Testing for modules and components do not break the original code as it is tested as a single entity that interacts with the overall project. Another topic that gets discussed by the group is the common closure principal. The common closure principle consists of classes that change for the same reason and at the same time. This is similar to the single responsibility principle. This simply means that if the character of the class is changing, then the component is also gonna change. We need to make sure that the component is only changing for one reason only and if there is more than one reason, then there should be more than one component. Overall, this episode went very in-depth to technical practices and techniques that are used to develop components and architecture in software creation. This level of in-depth was a little too much for what we are studying but I felt it was necessary as it gets us thinking about how to build software in components and parts and start learning how to allocate functionalities to individual components.

 

Link – Episode 71

https://player.fm/series/coding-blocks-software-and-web-programming-security-best-practices-microsoft-net

https://en.wikipedia.org/wiki/Cohesion_(computer_science)#frb-inline

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

Episode 33 —Testing in Data Science

In this week’s testing podcast episode, Brian explores testing in data science with the famous Katharine Jarmul. Katharine is a expert in data science and machine learning. She mainly uses python to write unite tests for her projects. I picked this podcast because after listening to this, I learned more about how to put together testing teams, how to manage and direct traffic in a testing team and how to be the driving force for success in the team. According to her, no matter how much we know as a team, with each testing project, we need to bring together all our resources and ideas. Testing often goes out of the scope of what is considered the norm. This is because in testing, we normally try to find the boundaries and limits if products and software. As a teacher and owner of a consulting company, Katharine often spends her days developing testing strategies that requires the implementation of new and modern testing technologies such as Integrating QA through agility and TCoE , Higher Automation Levels with a focus on security and Context driven testing.

 

Integrating QA through agility and TCoE

Though agile development teams have been around for a long time, agility in testing is still nascent. With the continuous pressure to quickly deliver software, businesses are investing time and money into setting up a TCoE with the objective of reducing CoQ, increasing test effectiveness and generating more ROI out of testing. From 2011 to 2014, the number of operational TCoEs has increased from 4% to 19% and is expected to increase further in the future.

 

Higher Automation Levels with a focus on security

System robustness and security has always been a top priority but with growth in social media and mobility and need for software that can be integrated to multiple platforms, systems are becoming more vulnerable. There is a pressing need to ensure enhanced security, particularly in applications handling sensitive data. This is causing QA to focus more on security testing.

 

Context driven testing

The challenge for businesses to maintain central hubs of hardware, middleware and test environments necessary to comprehensively test them has caused context driven testing to become more popular as it ensures more testing coverage from diverse angles. It is expected that this will impact skill development among testers, as there will be more demand for testers with exposure to different contexts.

 

Sources

https://testingpodcast.com/33-katharine-jarmul-testing-in-data-science/

http://www.cigniti.com/blog/top-7-trends-in-software-testing/

 

From the blog CS@Worcester – Le Blog Spot by Abranti3 Dada Kay and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-12-11 23:50:09

The blog post this is written about can be found here.

This week I decided to look into software frameworks, and I picked this blog post because of its concise explanation and because it included advantages and disadvantages to using them.

Software frameworks provide developers with ways to create applications without starting from scratch. Instead of writing every piece of functionality, you only have to write the pieces that are unique to your application. Like a framework for a building under construction, they’re bare-bone essentials for the type of project you want to create. Using a framework allows software to be developed more quickly and with higher quality, as software frameworks are pre-tested. With less to worry about coding and testing themselves, developers can focus on fulfilling their specific requirements instead of reinventing the wheel.

Software frameworks adhere to the inversion of control design principle, in which the general framework instantiates and invokes the objects and methods specific to your application. This contrasts with using a software library, in which a custom application instantiates and invokes the objects and methods that belong to the library.

Some other advantages to using software frameworks, as the blogger writes, are that they can encourage better programming practices and appropriate use of design patterns. Upgrades to the framework can also provide benefits to the framework users without them having to do additional coding of their own. Lastly, software frameworks are by definition extensible.

Among the downsides are that if you wish to create your own software framework, it’s more difficult and time-consuming to create the first application that utilizes it than it would be without the framework. However, if well-made, the development and testing effort will be reduced in all future projects that utilize it.

Another disadvantage is that frameworks can be difficult to learn. This can negate the advantages of the framework for the first project a developer uses it for similarly to how they’re negated for the first project that utilizes a brand new framework. Finally, frameworks can grow increasingly complex over time with updates and additions.

Though they certainly have their disadvantages, software frameworks seem like an intuitive solution to me. If I’m tasked with doing something a hundred times with slight variations, after a while, it only makes sense to find the commonality between all the instances and use that as a base to add the variations to. Additionally, in the future, I will keep an eye out for whether software frameworks are available for the type of project I’m trying to create and use them if the benefits outweigh the effort needed to learn them.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

CS@Worcester – Fun in Function 2017-12-11 23:14:26

The article this blog post is written about can be found here.

This article gives an overview of web application testing, which has several aspects unique to it compared with other software testing. I chose the article from a few sources on web testing because it was easily understandable while providing enough detail to get a feel for what’s involved.

One of the forms of testing highlighted in this article is usability testing. This includes verifying that there’s a consistent look and feel throughout the site, the application is easy to navigate, and it’s clear to users what options they have available to them. The article also makes note of the 1998 amendment to section 508 of the Rehabilitation Act, which outlines accessibility requirements for people with disabilities on information technology systems belonging to the US federal government. Section 508 compliance isn’t necessary for any non-federal website, but making sure to include accessibility features opens your web application up to a wider audience. The article gives the example of what your application should do if a user fails to enter a required field: simply changing the field title’s color to something noticeable like red, as is commonplace, wouldn’t be useful for someone who has trouble distinguishing colors. Another visual cue like an asterisk would be useful in this situation.

HTML verification is another form of testing for web applications. Testing for correct syntax is the obvious form, but it also includes testing the way your application displays across different internet browsers, OSes, screen resolutions, and device types. Your application may be usable and look great in one context, but break in another.

Load testing must also be done on applications that are intended to be accessed through the internet. They have to be able to function during times of high traffic, and testing of this sort can be used to find bottlenecks. In addition, performance tuning is prudent. All pages of your application should load quickly – the article suggests within 15 seconds.

User acceptance testing is used to determine whether your application does what it set out to do and makes something easier for the user instead of harder. One way this can be done is with a beta release.

Finally, of extreme importance in web applications is security testing, which should be done by qualified security specialists. The damage that can be done if this is neglected is immense.

This article gave me a good introduction to the additional testing required for web applications. Of all the details, I found adherence to section 508 especially interesting. It might not be a legal requirement for anything I design in the future, but if I ever do design a web application destined for the real internet, I will definitely want to make it accessible.

From the blog CS@Worcester – Fun in Function by funinfunction and used with permission of the author. All other rights reserved by the author.

Difference between Abstraction and Encapsulation

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Encapsulation

Encapsulation is a technique in programming where the programmer hides the internal behavior of the object from the user. Encapsulation hide the inside view of the object from the user such that it only implements the behavior of the object. Usually the client does not need to know the detail of the program and that is exactly what encapsulation does.

Encapsulation hide the data for object and makes the variables as private, and expose only the property to access the private data which would be public. So, when you access the property you can validate the data and set it.

For example, let take a Mobile Phone and Mobile Phone company. Suppose you are a Mobile Phone company and you designed and developed a Mobile Phone design(class), now by using machinery you are making a Mobile Phone(object) for selling, when you sell your Mobile Phone the user only learn how to use the Mobile Phone and not how the Mobile Phone works.

Again, let consider a TV operation for example, the manufacturers encapsulate it with cover and we can only operate it with the remote and have no need to open the TV and change the channel.

In this regard, everything is in private except remote; so anyone can access to operate and change channel and not the things in TV.

Reference:

https://en.wikipedia.org/wiki/Encapsulation_(computer_programming)

 

 

From the blog CS@Worcester – Computer Science Exploration by ioplay and used with permission of the author. All other rights reserved by the author.

Thoughts on “Hybrid Verification: Mixing Formal Methods and Testing”

This article, by Dr. Ben Brosgol, focuses on a mixture of formal methods and testing practices (together called “hybrid verification”) and the use of “contracts” that consist of preconditions and postconditions in order to formalize the assumptions made by critical code.

I chose to write about this article because it highlights some of the limits of testing, shows how to provide additional security for critical code, and introduces contact-based programming.

Brosgol defines a “contract” in programming as a set of preconditions and postconditions that wrap a subprogram (function, method, etc.) call.  The subprogram cannot begin unless its preconditions are met, and cannot return until its posconditions are true.  This provides a contract between a program and its subprograms that guarantees a certain state at critical times.  There are tools written for some languages (he uses SPARK as an example) that can do both static and dynamic contract testing and provide proof that the code will work as specified.

Brosgol then details ways to mix testing and formal verification.  If formally verified code calls subprograms that were tested rather than proven, the formal analysis tools will attempt to show that the preconditions are met, and assume that the tested code satisfies the postconditions.  This also requires that either the contracts are checked at runtime, or that sufficient testing was done such that the developer is confident the contracts will be fulfilled by the tested code.  If formally verified code is called from tested code, there need to be runtime checks for the preconditions (because the tested code does not guarantee those in the way the formal verification requires), but because the postconditions have been proven there is no need for checks at that point.

Next, Brosgol mentions the need for good choice of postconditions.  Strong, extensive postconditions make it easier to provide proof, but may have unacceptable overhead if they need to be checked dynamically.

He concludes that the relatively new combination of formal proof tools and contract verification on both a static and a dynamic basis opens up new avenues to create code that secures its critical sections.

This article helped me to understand that there’s a much wider world of testing beyond what we covered in class.  We didn’t talk about proof-based testing at all, and that’s a subject area that I believe I should learn more about.  It also highlights the way that our understanding of testing is ever-expanding.

 

From the blog CS@Worcester – orscsblog by orscsblog and used with permission of the author. All other rights reserved by the author.