Hi dear readers. Welcome to my next blog post. In this blog post I am going to talk about the next pattern called “Find Mentors”. I strongly believe this is a very important pattern and I will explain why below.

In the path of your career, you will always find yourself struggling learning about new stuff or not knowing what to learn . Don’t freak out though, this is normal. I know it sounds weird, but this is just the start of your journey and you are expected to not know everything. However, sometimes is very hard on to determine what to learn next or what is your next step in your career. So as the book suggests, a mentor is always a good help to have.

Finding the perfect mentor for you is not easy and you probably will never find him/her. It is true that there are a lot of people out there who  are professionals in what they do, but that doesn’t mean they are meant to be mentors. However, do not get discouraged because there are plenty of people who like to be mentors, you just got to be patient until you find him/her.

Another good point that the authors make in the book is that you might change mentors often or have multiple mentors as different people are specialized in different areas and have different knowledge. The hard part in all this process is finding and convincing this person to be your mentor. It might be awkward for you to ask and also weird for them. Unfortunately there might also be cases when they will refuse, but do not get discouraged. You will find other mentors. If you really really like a specific person to be your mentor, you got to win his/her ‘heart’.

While you grow you will be able to understand if you are in need of changing mentors and there is nothing wrong with that. Also as they teach you, you will understand what you really like and what you want your focus to be in. So start being part of communities and look for your mentors based on what you’re interested.

Hello dear reader. Another concept that I came across this semester in my Software Design and Construction class was UML diagrams and I wanted to write about UML diagrams in one of my posts.

For all of you that are new to UML, UML is not a programing language. UML stands for Unified Modeling Language. UML is a standard model language of an integrated set of diagrams. UML was developed to help system and software developers for specifying, constructing, visualizing, and documenting the code of software systems. It is a very important part of developing object-oriented software and the software development process. UML uses mostly graphical notations to express the design a software. Using UML helps teams communicate and validate the architectural design of the software. We use it to portray the behavior and the structure of a system/project.

A question that I asked myself when I started to learn about UML was: Do we really need UML? The more I learned about it the more I understood how important UML is. This for different reasons like: – there are a lot complex applications and systems that need planning from a lot of different teams, and clear explanation need to go to each and every team working on the same project; most of our users might not ever know what code is, but there are a very important part of our project and that’s where UML kicks in by translating this ‘foreign language’ called code.

UML can be classified in two types: Structural and Behavior Diagrams. Structural Diagrams get the static aspect or structure of a system. It includes Object Diagrams, Deployment Diagrams, Class Diagrams and Component Diagrams. Behavior Diagrams on the other hand get the dynamic aspect or behavior of the system and it includes Interaction Diagrams, State Diagrams, Use Case Diagrams and Activity Diagrams.

Except school I have come across UML Diagrams at my job too. The diagram I have seen and that we use a lot if the Deployment Diagram as each of us should be aware of the architecture of the system as deployment.

I like the way Noel explains UML diagrams and where/how to use them. He provides great graphic examples of the diagrams.
https://tallyfy.com/uml-diagram/

Hello dear readers. Thanks for coming back to my blog to learn about the Static Testing Technique.

The first technique of the Static Testing is Informal Review. This type of technique consist on  the presentation given by the creator of documents such as software requirements, business requirement document, technical design document,  test cases document, function requirement documents etc to the audience. The audience could be senior management, development team, business clients, internal audit team, etc. During these reviews and after, the audience can give their opinion and can share their experience in order to outline the review defects. This static testing type is very useful because it helps in the identification of the defect very early.

The second technique is called Walkthrough. This type of technique is done with the expert or a senior member. For example, Software Requirements Specification Document will be reviewed with the Business lead who have provided the requirements, test cases document will be reviewed by the testing team who is going to execute those test, Functional Requirements Document will be reviewed with the technical team who is going to write the solution etc. This walkthrough is useful because: the lead is aware of the quality of the documents and the target team comes to know about what exactly is going on.

Peer review it’s the review when the peer ensures maker and checker. To outline the common mistake such as workflow mistake, spelling mistake etc, a team of two or more is needed to review the work. The colleague is included as the peer who tests the work at the document level.

Last technique is Inspection. This technique validated the documentation work by the dedicated governance team. For example: the Business Requirement Document, change ticket, technical Design Document, etc are reviewed by compliance, tollgate team and change the governance respectively. If it found inappropriate, inspection can reject the execution of the document.

Having to know the techniques is important as are part of the testing process.

https://www.invensis.net/blog/it/software-test-design-techniques-static-and-dynamic-testing/