Intro To Interoperability Testing

As the Fall semester kicks off and I begin to dive into the curriculum of Software QA and Testing I quickly realized how little I actually know and how in depth testing really needs to be. That being said I want to use my blog posts as an opportunity to learn about different types of testing. That lead me to go with the article “A Simple Guide to Interoperability Testing” written by the team over at ThinkSys. I really had no idea what Interoperability Testing was before I read this so I decided to learn. I also liked that it was written in 2017. I know a lot of software topics have remained the same for decades but there’s something refreshing about reading something that has been published more recently.

First off, interoperability testing is a type of non-functional testing. This means it is testing the way a system operates and the readiness of the system. In the most general sense interoperability is how well a system interacts with other systems and applications. A great example provided is a banking application system (seen below) where a user is transferring money. There is data/info exchange on both sides of the transfer without an interruption of functioning to finish the transaction.

Banking Application Interoperability

The testing of the functionality that takes place to allow a fluent interaction between systems is what interoperability testing really is. It ensures end to end functionality between systems based on protocols and standards. The article covers 5 steps to perform this type of testing. They consist of:

  1. Planning/Strategy: Understand each application that will be interacting in the network
  2.  Mapping/Implementing: Each requirement should have appropriate test cases associated. All test plans and test cases are developed.
  3. Execution: Running all test cases and logging and correcting defects. Also retesting and regression testing after patches have been applied.
  4. Evaluate: Determine what the test results mean and ensure you have complete coverage of requirements.
  5. Review: Document and review the testing approach, outline all test cases and practices so further testing can improve on what has been done.

Some of the challenges that can arise with interoperability testing include the wide range of interactions that can take place between systems, testing multiple system environments can be difficult, and root causes of defects can be harder to track with multiple systems involved.

After reading this article I can definitely see the complexity in interoperability testing. Taking an iterative approach seems like it would be the best method because you can use your results each iteration to create better test cases and more coverage. Trying to tackle all the test cases in one execution would be overwhelming and it would be difficult to have close to full coverage. It seems like interoperability testing would need to take place anytime an application is updated as well to make sure the systems that interact with it are still compatible. Now that I have a general understanding of interoperability testing I am certain it will play a role in future jobs and work I do. With today’s technology, it is rare to have a complete standalone application that doesn’t interact with additional systems.

In conclusion I enjoyed this article because it was simple, to the point, and I was able to retain the information.

Advertisements

Summary of Agile Modeling

After being exposed to agile development last semester, more specifically Scrum, I thought it would be interesting to continue my learning in the topic. Seeing as I am now studying software design principles, agile modeling seems like a great place to start.

This is why I chose an article titled “An Introduction to Agile Modeling” which gives a breakdown on what Agile Modeling (AM) really is and how to apply it to software development using the best practices. Basically AM is a collection of values, principles, and practices which can be applied to any development project in an effective and lightweight manner. It is meant to be applied to base processes like Rational Unified Process or Extreme Programming and frameworks like Scrum. The idea is that AM can be tailored to any developer’s needs.

The values AM is based on:

Communication: All project stakeholders need to be able to openly converse throughout a projects life-cycle.

Simplicity: Always focus and aim for the simplest solution that meets all requirements and solves all problems.

Feedback: Get feedback often and early on the work that is done to course correct and create project transparency.

Courage: Make and stick to your decisions.

Humility: You won’t know everything, others can add value to the project.

The principles AM is based on:

The importance of assuming simplicity. The simplest solution is always best.

Embrace change when working because requirements WILL change.

Strive for rapid feedback to enable the agility of incremental changes.

Model with purpose, if you don’t why then you shouldn’t be doing it.

There’s more than one way to model and be correct. Content > Representation

Open communication is crucial for teamwork.

Always focus on the quality of work. The product owners should be proud and refactoring down the road should be easy.

After reading this article I think the above values and principles make a solid foundation when it comes to software modeling. While I sometimes think these things are obvious, it’s important to conduct yourself in accordance with a set of guidelines and code of conduct. Most of the ideas behind Agile Modeling are similar to the books I’ve read by Robert Martin aka Uncle Bob. I think the most important part of AM is the constant communication between all stakeholders. Requirements are always bound to shift and change priority so feedback and iterative changes are crucial for AM to be effective. The only thing I did not agree with in the article was that content is more important than representation. I think you could have great content but if you are not effective at representing it then what’s the point? In my opinion they are equals.

In conclusion I plan to read more into Agile Modeling and how I can apply it to my own projects. Moving forward I am going to tailor my software modeling to follow the best practices of AM as I believe it will create a strong foundation of design principles.

The following figure gives an idea of Agile Model Driven Development (AMDD).

Sprint 6 Reflection

In Sprint 6 even though we were close to fixing the issue we had assigned ourselves, we chose not to take on additional tasks due to it being the final sprint. We continued to work on APTS-296 and were able to run a fixed instance of the issue on our computers. Unfortunately, we realized that our solution was flawed. When we were ready to submit a pull request we realized that the developers were not going to accept changes we had made to the npm module directory. This was not part of the original repo and cannot be cloned from GitHub by other users. Once we knew we were going to need to some guidance we reached out to the developers on Slack.  Basically they said the property that needed to be updated was part of the schema that gets implemented when users run their npm install commands. Therefore, we were directed to reach out on JIRA and mention a particular developer to help fix the issue. Once we did this the developer implemented the change we requested and testing feedback was posted on JIRA. Within a couple of days the ticket was successfully closed out. While we may not have been able to get a pull request submitted we did directly track this issue and ensure it was solved. One lesson to take away would definitely be to ask questions early on. Instead of struggling to look for a solution and work on the issue for a whole sprint, we could have reached out to the developers and found the full solution was beyond our capabilities. If we were to have more sprints I believe we would adjust our velocity to taking on 2-3 issues in one sprint. We’ve gotten pretty comfortable navigating the code base so we would be able to track the location of issues quicker. We would also communicate with the developers more to ensure speedier solutions. From a personal perspective I don’t think I utilized the knowledge and help from the AMPATH developers enough. I saw it as bothersome to them and tried to avoid it at all cost. In reality they were quick to respond, knew exactly what to do, and usually it wasn’t all that difficult. Lesson learned; don’t be afraid to ask for help.

The Software Craftsman: Chapters 15 & 16

Chapter 15 covers the topic of pragmatic craftsmanship and what the term actually means. He starts off by remind the reader that cheap and fast code that lacks quality will always become expensive and slow to change over time. Quality is always expected at the end result and the author claims that quality does not have to be compromised by a team of software craftsmen.  By practicing Extreme Programming and Agile methods testing, integration, and deployment are done daily with working software every step of the way. The initial learning curve is what causes teams to stray from this way of development. Instead companies need to hire craftsmen so that the best quality and development environment can be achieved and passed on to junior developers. The author goes on to talk about other development staples like TDD and refactoring and implementing them correctly. He also advises that when working closely with a business the team should be able to visualize the businesses goals quickly and get feedback as to always pleasing the customer. Projects are never about an individual and code should always be kept small, testable, and easy to understand while constantly doing the job intended. Two main rules the author mentions regarding program design are to minimize duplication and maximize clarity. The author concludes with saying that a craftsman masters their practice and provides quality at a good value. Quality is always expected regardless of the situation and to master the practices to deliver quality, one must be pragmatic.

After reading chapter 15 there is definitely some good advice however the chapters are starting to become repetitive. While the main message was delivering proper valued quality, many suggestions and topics such as TDD and refactoring are being repeated. The best lesson I took away was to never have the mind set for a project of quick and cheap. Customers always expect quality and by practicing the right methodologies you can always guarantee it. Aside from that the two design principles of minimizing duplication and maximizing clarity should be kept in mind for any programmer.

Chapter 16 covers the topic of a career as a software craftsman. The author outlines what being a software craftsman really means. Above all you need passion. The world is becoming more and more reliant on software and craftsmen need to be able to solve problems and be curious aside from just writing code. The author then suggests climbing the ladder through the progression of a career. Those who switch to managerial roles have switched ladders and should view it as a career change. Taking a job as a developer should be seen as more than just an occupation and really a lifestyle commitment. Each job should align with career goals and progression. As the author says a craftsman is committed to excellence and the role they are playing in the evolution of society.

After reading chapter 16, it was mainly a motivating summary of all the lessons learned throughout the book. The only part I still don’t fully agree with is limiting your job search to only a few companies. In reality people have families to provide for and bills to pay. While I do not condone staying in a job you are unhappy with, sometimes you just can’t land the dream job and may need to settle or stay where you are for a little longer. This especially applies to junior developers who are still just trying to gain exposure and experience in the field. In conclusion I think this book was well written and provided some great guidance for a software developer at any stage in their career. That being said I did find many chapters to be repetitive and many lessons to be similar to ones in Clean Coder.

The Software Craftsman: Chapters 13 & 14

Chapter 13 covers the topic of creating a culture of learning in the workplace. The author insists the culture starts with the senior personnel who are viewed as role models. If they are excited about being at work, it will rub off on other team members. The author also advises to give developers the freedom to learn. It leads to happy developers, more innovation, and an overall better work environment. He then goes on to a lengthy list of topics developers can do to create this better work environment:

Start a book club

Have tech lunches

Organize group discussions

Switch Projects for “x” time

Conduct group code review

Encourage pet-projects

The author then goes on to give advice to developers trying to create a culture of learning. He reminds the reader that you can’t change everyone with your enthusiasm and that’s okay. If you can help other developers re-discover their passion for what they do, it will still have a positive impact on the workplace. Some of his advice is as follows:

Be an example

Focus on those who care

Don’t force participation

Avoid consensus delays

Don’t ask for authorization

Don’t complicate/Make excuses

Establish a rhythm

The author concludes by saying that the culture of learning is everyone’s job. It can also be cheap and easy as passionate developers will naturally create this kind of environment.

After reading chapter 13 I think there’s a lot of really good advice to take away. I definitely agree with the overall message that having a culture of learning is imperative to any development team. Without it, developer’s skills get outdated and team innovation will be on the decline. Software development is an ever changing field and creating a culture of learning in the workplace is one way to keep up. There were only a couple of suggestions from the author that I didn’t fully agree with. The first was encouraging pet projects in the work place. While I think it’d be okay to have a lunch discussion with a co-worker about a side project it seems a little unprofessional to me to dedicate any of the work day towards it. If it’s not a topic that directly benefits your skills at work I would especially save it for outside work. I wouldn’t want to give any impression my side work was more important than my company’s. Secondly I didn’t agree with the advice to not ask for authorization. If you’re going to conduct training in the workplace it’s always a safe bet to run it by the manager. Even if you don’t formally ask permission, maybe just invite the manager to stop by or participate. In summary, I think the author’s advice and suggestions promoting a culture of learning are really good.

Chapter 14 covers the topic of driving technical changes. More specifically how to convince skeptics to be more open to new ideas. First the author breaks down these skeptics into types that someone may encounter. They include types like “The Uninformed”, “The Irrational”, and “The Boss.” Once you’ve identified the type/s you may need to convince you need to be prepared for technical conversation and heated debates. To actually get the ball rolling towards a change you see fit the author provides an outline: establish trust, gain expertise, lead by example, choose your battles, iterate, inspect, and adapt. He also suggests not letting fear and incompetence get in the way of doing what is right to implement a positive change. As far as getting permission from the boss he says not to worry about that. They don’t care about the low level implementation, they just want solid results. As far as convincing a team to adopt a new idea, you should be proficient and able to teach the skeptics. If you don’t have a grasp on the subject it will come off as difficult and a waste of time. The author concludes with the idea that implementing changes is the responsibility of a true software craftsman. Whatever is best for the project and customer is what should be implemented. In order to adapt to these changes, a craftsman needs to know how to communicate with everyone and show the real value in the change they want to implement.

After reading chapter 14 there are definitely things to keep in mind for a future career in software development. I do think this chapter is aimed at much more experienced developers as it would be extremely difficult for a junior developer to convince a team to make a technical change without the experience to back up their reasoning. That being said it is of the upmost importance to satisfy the customers and anyone who can see a beneficial change to make that happen should try to implement it. I did not agree with the idea of not informing the boss once again of a technical decision. A good manager will care about the team and a good team will be transparent to their manager especially if a technical change is made. As I mentioned for chapter 13, I don’t see it being necessary to ask permission. Something like “We are implementing TDD because we can benefit as a team in this way” should suffice. Aside from that, the chapter was useful and reminds the reader of responsibility and accountability.

The Software Craftsman: Chapters 11 & 12

Chapter 11 covers the topic of interview anti-patterns. Basically it covers what to avoid as someone giving an interview to attract true software craftsman.  The author first suggests to avoid intimidating the candidate as well as to avoid trying to seem smarter           than them. An interviewer should be humble and treat the interview as a professional and technical conversation. Relying on brainteasers and questions irrelevant to the open position should also be avoided as it doesn’t pertain to how well they’d do the job at hand. The author also highlights other suggestions such not blocking the internet, not to code on a whiteboard, and not to conduct phone interviews. His advice is to make the interview as relevant as possible to the job; use real tools and write code on a computer. Software craftsmen are also interviewing the company and as the author says will reject offers from bad companies.

After reading chapter 11 there is a lot that I agree with but some things that I do not. First I strongly agree with avoiding brainteasers or situations that make it seem like you are trying to outsmart the candidate. It’s uncomfortable and if the interview seems stressful, one can only assume how bad the actual job would be. I also strongly agree with not blocking the internet. If someone is stuck on a question, they should be given the chance to find the answer however they see fit. As a software developer you will always have tools and resources to help you with whatever problems you come across. One thing I slightly disagree with is not writing code on a whiteboard. I think this is perfectly legitimate for base knowledge coding problems or algorithms that will pertain to the job especially for a junior level job. For more senior developers, their work and portfolio should be able to speak for themselves. I also disagree with not conducting phone interviews. The phone interview doesn’t need to be extremely technical but it’s good to make sure the company and candidate are on the same page. If this short conversation can filter people out then I see that as valuable time saved. Perhaps someone thought the job encompassed other responsibilities and were disappointed upon coming in for the interview. There’s no need to allow those kinds of situations to occur. Lastly I believe that companies spend a lot of time in creating their hiring process. Just because they may proceed through their selection process different would not make me reject an offer. Above all I look for a job I’d be excited to go to every day and people I can relate to. The selection process can be very generic for larger companies and won’t always reflect the open position. It’s up to the candidate to dig deeper and see if it’s something they truly want.

Chapter 12 covers the topic of the cost of low morale. The author touches upon how a team with low morale can bring an entire company down and just how costly it can be. The first contributor to low morale mentioned by the author is what he calls the “agile hangover.” The agile transformation that swept many companies did very little to improve developer’s technical skills. They had a new process but were still developing the old way. If anything this hurt team’s motivation even more. Another contributing factor is the employment of 9-5 developers. These are developers who don’t actually care about their job and are just there to collect a paycheck. They have no sense of urgency and do not care if they show zero results. While some people simply can’t be motivated, hiring a few craftsmen to a team can definitely turn things around according to the author. They can help fix technical issues, bring new innovations, and get a team excited again. Craftsmen can get a team to enjoy their work more which drives better results. Developers who enjoy their job will care and improve their skills.

After reading chapter 12 I agree with the ideas presented by the author. I do think he makes the situation seem a little easier than it truly is though. Not many companies can afford to hire a few craftsmen developers on to a team for motivation. I also think it would be tough even for a few craftsmen to get an entire team excited about their job. If a team and its members have dropped that low in caring then some employees probably just need to be let go. It could also be management or general company culture that has caused a development team to be so poorly motivated. Hiring some craftsmen will not fix a companywide issue.  Also if a true craftsman were to listen to the author’s hiring advice, they would most likely not take a job with a team that lacked morale. I agree that low morale can cost a company a fortune but I think the issue goes deeper than the advice offered by the author.