What is “version control”, and why should you care? Version control is a system that records changes to a file or set of files over time so that you can recall specific versions later.
Local Version Control Systems
Many people’s version-control method of choice is to copy files into another directory (perhaps a time-stamped directory, if they’re clever). This approach is very common because it is so simple, but it is also incredibly error prone. It is easy to forget which directory you’re in and accidentally write to the wrong file or copy over files you don’t mean to.
Centralized Version Control Systems
The next major issue that people encounter is that they need to collaborate with developers on other systems. To deal with this problem, Centralized Version Control Systems (CVCSs) were developed. These systems (such as CVS, Subversion, and Perforce) have a single server that contains all the versioned files, and a number of clients that check out files from that central place. For many years, this has been the standard for version control.
Git is one of the best version control tools that is available in the present market.
Provides strong support for non-linear development.
Distributed repository model.
Compatible with existing systems and protocols like HTTP, FTP, ssh.
Capable of efficiently handling small to large sized projects.
Cryptographic authentication of history.
Pluggable merge strategies.
Periodic explicit object packing.
Garbage accumulates until collected.
It is yet another most popular revision control system. CVS has been the tool of choice for a long time.
Client-server repository model.
Multiple developers might work on the same project parallelly.
CVS client will keep the working copy of the file up-to-date and requires manual intervention only when an edit conflict occurs
Keeps a historical snapshot of the project.
Anonymous read access.
‘Update’ command to keep local copies up to date.
Can uphold different branches of a project.
Excludes symbolic links to avoid a security risk.
Uses delta compression technique for efficient storage.
Tools for testing
Selenium is a testing framework to perform web application testing across various browsers and platforms like Windows, Mac, and Linux. Selenium helps the testers to write tests in various programming languages like Java, PHP, C#, Python, Groovy, Ruby, and Perl. It offers record and playback features to write tests without learning Selenium IDE.
Selenium proudly supports some of the largest, yet well known browser vendors who make sure they have Selenium as a native part of their browser. Selenium is undoubtedly the base for most of the other software testing tools in general.
TestingWhiz is a test automation tool with the code-less scripting by Cignet Infotech, a CMMi Level 3 IT solutions provider. TestingWhiz tool’s Enterprise edition offers a complete package of various automated testing solutions like web testing, software testing, database testing, API testing, mobile app testing, regression test suite maintenance, optimization, and automation, and cross-browser testing.
TestingWhiz offers various important features like:
Keyword-driven, data-driven testing, and distributed testing
Browser Extension Testing
Object Eye Internal Recorder
Integration with bug tracking tools like Jira, Mantis, TFS and FogBugz
Integration with test management tools like HP Quality Center, Zephyr, TestRail, and Microsoft VSTS
HP QuickTest Professional was renamed to HPE Unified Functional Testing. HPE UFT offers testing automation for functional and regression testing for software applications.
Visual Basic Scripting Edition scripting language is used by this tool to register the test processes and operates the various objects and controls in testing the applications.
QTP offers various features like:
Integration with Mercury Business Process Testing and Mercury Quality Center
Unique Smart Object Recognition
Error handling mechanism
Creation of parameters for objects, checkpoints, and data-driven tables
Process administration of V&V
Jira is a great software management tool that is widely used in many companies. It is very robust and offers many features that help the management of tasks and processes, and it can be integrated with other tools.
A very innovative tool that serves as a all-in-one workspace. It supports many features, for productivity, design, and of course, task management. An alternative to Jira, and great for managing the status of processes. It also supports markdown.
Only two more posts to go! So, here we go with the 5th one:
Software testing process
Types and levels of testing
Activities and roles in testing
Test Case Design techniques (open and closed views)
Process for control and management of defects in artifacts
#1: Test Strategy and Test Plan:
These artefacts describe the scope for testing for a project:
The systems that need to be tested, and any specific configurations
Features and functions that are the focus of the project
Test approach—traditional, exploratory, automation, etc.—or a mix
Key processes to follow – for defects resolution, defects triage
Tools—for logging defects, for test case scripting, for traceability
Documentation to refer, and to produce as output
Test environment requirements and setup
Risks, dependencies and contingencies
#2: Test Design
Test design as a process is an amalgamation of the Test Manager’s experience of similar projects over the years, testers’ knowledge of the system/functionality being tested and prevailing practices in testing at any given point. For instance, if you work for a company in the early stages of a new product development, your focus will be on uncovering major bugs with the alpha/beta versions of your software, and less on making the software completely bug-proof.
#3: Test Execution
You can execute tests in many different ways—as single, waterfall SIT (System Integration Test) and UAT (User Acceptance Test) phases; as part of Agile sprints; supplemented with exploratory tests; or with test-driven development. Ultimately, you need to do adequate amount of software testing to ensure your system is (relatively) bug-free.
#4: Test Closure
Right—so you have done the planning necessary, executed tests and now want to green-light your product for release. You need to consider the exit criteria for signalling completion of the test cycle and readiness for a release. Let’s look at the components of exit criteria in general:
100% requirements coverage: all business and technical requirements have to be covered by testing.
Minimum % pass rate: targeting 90% of all test cases to be passed is best practice.
All critical defects to be fixed: self-explanatory. They are critical for a reason.
QA Leader is the most important member of the testing team. While it is extremely crucial for him/her to have a clear understanding of the testing process or methodology. It is also essential for him/her to be familiar with the varied test-program concerns such as test environment and data management, trouble reporting and resolution, etc.
2. Test Lead
With a clear understanding about the applications business area and its requirements, a test lead is a person who is also familiar with the varied test-program issues such as test data management, test design, and test development.
3. Test Engineer
The role of a test engineer is to determine the best way to create a process that can enable one to test a particular product in the best possible manner. Test engineers can have different expertise based on which they are assigned a role in a company. Some of these are: – Usability Test Engineer – Manual Test Engineer – Automated Test Engineer
4. Network Test Engineer
With a high level of proficiency and expertise in a variety of technical skills such as programming languages, database technologies, and computer operating systems, network test engineers are good at product evaluation and integration skills.
5. Test Library and Configuration Specialist:
This job role requires one to have a network, database, and system administration skills along with expertise in technical skills including programming languages, database technologies, and computer operating systems.
Having a sound knowledge about various concepts involved in test designing and execution methodologies, a software tester is the one who is able to interact efficiently with the development team.
Test Case Design techniques
1. Specification-Based or Black-Box techniques
This technique leverages the external description of the software such as technical specifications, design, and client’s requirements to design test cases. The technique enables testers to develop test cases that provide full test coverage.
2. Structure-Based or White-Box techniques
The structure-based or white-box technique design test cases based on the internal structure of the software. This technique exhaustively tests the developed code. Developers who have complete information of the software code, its internal structure, and design help to design the test cases.
3. Experience-Based techniques
These techniques are highly dependent on tester’s experience to understand the most important areas of the software. The outcomes of these techniques are based on the skills, knowledge, and expertise of the people involved. The types of experience-based techniques are as follows:
In this technique, the testers anticipate errors based on their experience, availability of data and their knowledge of product failure. Error guessing is dependent on the skills, intuition, and experience of the testers.
This technique is used to test the application without any formal documentation. There is minimum time available for testing and maximum for test execution. In exploratory testing, the test design and test execution are performed concurrently.
Process for control and management of defects in artifacts
Defect Management Life Cycle
When a system gives a different output other than the actual business requirement i.e. when there is a deviation from the actual or original business requirement then we can say that there is a defect in the system/software.
When the testing team executes the test cases, they come across a situation where the actual test result is different from the expected result. This variation is termed as a Defect.
Basically, a Software Defect is a condition which does not meet the software requirement. The defect is an error or a flaw which produces an unexpected or incorrect behavior in the system.
In order to handle the projects appropriately, you need to know how to deal with the development and release, but along with that you also need to know how to handle defects.
#1) Defect Prevention:
Defect prevention is the best method to eliminate the defects in the early stage of testing instead of finding the defects in the later stage and then fixing it. This method is also cost effective as the cost required for fixing the defects found in the early stages of testing is very low.
However, it is not possible to remove all the defects but at least you can minimize the impact of the defect and cost to fix the same.
The major steps involved in Defect Prevention are as follow:
Identify Critical Risk: Identify the critical risks in the system which will impact more if occurred during testing or in the later stage.
Estimate Expected Impact: For each critical risk, calculate how much would be the financial impact if the risk actually encountered.
Minimize expected impact: Once you identify all critical risks, take the topmost risks which may be harmful to the system if encountered and try to minimize or eliminate the risk. For risks which cannot be eliminated, it reduces the probability of occurrence and its financial impact.
#2) Deliverable Baseline:
When a deliverable (system, product or document) reaches its pre-defined milestone then you can say a deliverable is a baseline. In this process, the product or the deliverable moves from one stage to another and as the deliverable moves from one stage to another, the existing defects in the system also gets carried forward to the next milestone or stage.
#3) Defect Discovery:
It is almost impossible to remove all the defects from the system and make a system as a defect-free one. But you can identify the defects early before they become costlier to the project. We can say that the defect discovered means it is formally brought to the attention of the development team and after analysis of that the defect development team also accepted it as a defect.
Steps involved in Defect Discovery are as follows:
Find a Defect: Identify defects before they become a major problem to the system.
Report Defect: As soon as the testing team finds a defect, their responsibility is to make the development team aware that there is an issue identified which needs to be analyzed and fixed.
Acknowledge Defect: Once the testing team assigns the defect to the development team, its the development team’s responsibility to acknowledge the defect and continue further to fix it if it is a valid defect.
#4) Defect Resolution:
In the above process, the testing team has identified the defect and reported to the development team. Now here the development team needs to proceed for the resolution of the defect.
The steps involved in the defect resolution are as follows:
Prioritize the risk: Development team analyzes the defect and prioritizes the fixing of the defect. If a defect has more impact on the system then they make the fixing of the defect on a high priority.
Fix the defect: Based on the priority, the development team fixes the defect, higher priority defects are resolved first and lower priority defects are fixed at the end.
Report the Resolution: Its the development team’s responsibility to ensure that the testing team is aware when the defects are going for a fix and how the defect has been fixed i.e. by changing one of the configuration files or making some code changes. This will be helpful for the testing team to understand the cause of the defect.
#5) Process Improvement:
Though in the defect resolution process the defects are prioritized and fixed, from a process perspective, it does not mean that lower priority defects are not important and are not impacting much to the system. From process improvement point of view, all defects identified are same as a critical defect.
Even these minor defects give an opportunity to learn how to improve the process and prevent the occurrences of any defect which may impact system failure in the future. Identification of a defect having a lower impact on the system may not be a big deal but the occurrences of such defect in the system itself is a big deal.
For process improvement, everyone in the project needs to look back and check from where the defect was originated. Based on that you can make changes in the validation process, base-lining document, review process which may catch the defects early in the process which are less expensive.
And for our last topic of this partial we haaaaave… sooftware review!!! *claps*
Definition and characteristics of review
Activities and roles for each review
How to review the key work products: plans, requirements, design, and code
Software review is an important part of the software life cycle, assisting engineers in validating quality, functionality and other vital features and components in the sofware. It can be seen as a systematic examination of a document by one or more individuals who try and find any mistakes in it, specially during the early stages of this cycle, some examples of this documents are “test plans” or “test cases”.
We can pinpoint the main objective of software review and it’s characteristics by understanding what is the purpose or the objectives of using this process:
Improve the productivity of the development team.
Make the testing process time and cost effective.
Finish our product with as few defects as possible, reaching the definition listed in our requirements as close as we can.
Eliminate inadequacies, garbage code and anything which is not listed as a requirement
Finally, we can say there are 3 main types of software reviews:
Software Peer Review:
Focuses on the process of assessing the technical content and quality of the product, conducted by the author of the work product along with some other developers.
Software Management Review:
Software Management Review evaluates the work status. In this section decisions regarding downstream activities are taken.
Software Audit Review:
It’s a type of external review in which one or more critics, not part of the development team, organize an independent inspection of the software product and its processes to assess their compliance with stated specifications and standards.
As for the processes and activities we usually have in software review:
Entry Evaluation:A standard check-list is used by entry criteria in order to ensure an ideal condition for a successful review.
Management Preparation:During this stage of the process, a responsible management ensures that the software review has all the required resources, which includes things like staff, time, materials, and tools.
Review Planning:To undergo a software review, an objective is identified. Based on the objective, a recognized team of resources is formed.
Preparation:The reviewers are held responsible for preparing group examination to do the reviewing task.
Examination and Exit Evaluation:In the end, the result made by each reviewer is combined all together. Before the review is finalized, verification of all activities is done that are considered necessary for an efficacious software review.
As always, let’s get to what we’re gonna be talking about in this post first:
V&V in the life cycle of software development
International standards for V&V of Software
Administration of a V&V Plan
Before everything, we shall ask our main questions.
What is verification and validation?
Just by hearing those two words, we can get a pretty basic definition, which would be verification: checking that something completes all the requirements it needs and validation: the process that we follow to verificate a product, thing or whatever you could think.
When talking about the life cycle in software, validation and verification is a step used during almost the whole process of development, so we’ll see in the following table what happens in each one, very briefly:
Validate requirements along with the client to ensure proper understanding of what’s going to be done.
Verifying that all requierements are unique and doable.
Architecture and Design
All types of design that might end up being used have to be validated with the costumer, as to meet their expectations.
We verify that all designs are meeting the non-functional requirements (like performance or usability)
For each requirement done, we have to validate with the client if that’s what they wanted.
When doing unit and integration tests, or while having peer review.
Check that all functionality meets the client expectations and that all messages are clear.
All test cases need to pass this part, as to ensure that everything is working as intended.
All software after installation should be working as intented.
Configuring environment and running smoke tests.
As to international standards, ISO has always been there to mantain a certain level needed for validating different things, including software. As to what I could say about this, is simply that by having a certain level required for stuff to be valid and verified by certain organisms, we can mantain a same procedure for developing new stuff, such as software, I’ll also leave this article here so that people can indulge in really technical stuff if they feel like it, because I dont feel like it.
Planning and administrating V&V, the real challenge
For this, we have a term that already exists and depicts pretty well what was to be done. Verification and Validations Plans. This pretty much works by going hand with hand on your normal software life cycle, but implementing everything that’s needed to make a V&V correctly:
Explaining the test and objective of the project.
Define what items you’re gonna be testing, using the required documentation.
What features need to be tested? Along with all the data you’ll need.
What DOESN’T need to be tested? This should be a small list, and you can include items that need too much time and effort to be properly tested at earlier phases.
How is your testing team gonna approach the requirements? By defining a pass/fail criteria, you can prevent later confusion on how to validate and verificate diverse stuff.
An approach for handling any mistakes and errors that could stop your testing, otherwise you’ll lose time on making all test cases needed, with their design specification and procedures.
Environmental needs (I think this one pretty much speaks for itself? Please don’t run some software on a all mighty computer that your client does NOT have).
Approval from the client for all requirements.
Operation and maintenance in case a step was missed or something went wrong.
An open space of possible upgrades or replacement.
So, this was it for Validation and Verification, if you have anything to share, like experiences, knowledge on the topic, or just a plain comment on how you dislike my blog, please share in the comments so that other people can also enjoy a different perspective!
So, here we are again! This time to talk about a one teensy weensy but ever so crucial little tiny detail in software processes! Models and standards.
(have a cookie if you got the reference in that small paragraph before seeing the image)
These are the following topics i’ll try to cover in this blog:
Capability Maturity Model Integration (CMMI), is a processes model that helps an organization promote their members so that they can have a better performance. The questions this model ask are related to how good we work, our improvement and if our processes are as good as they should be and working as necessary, so we can call this model a book of ‘whats’ and ‘hows’, giving us a hint on what to work in.
Whenever we talk about time management, personal improvement on programmers, and guidance on organizations that use a CMMI model, then we’re either talking about PSP/TSP practices, or you’re somehow in an alternate universe where things are incredibly wrong.
PSP concentrates in work practices in a more individual manner, so that we can organize our day through day activities and handle product quality. This practice can be carried with a team, called the TSP (Team Process Software), which is in turn commanded by a gestion system, and of course, a team leader that evaluates the individual progress of each member of the team.
TSP, is insted, a method of stablishing teamwork and improving it, using two basic components:
Work team formation
Work team gestion
The major problems that are solved with this, are predicting time and cost in business, lack in productivity, and software development and cycles, along with product quality.
This new norm presents us the following objectives:
It’s necessary to propose and develop an evaluation stand in software processes.
Evaluate progress using experimentation.
Promote the evaluation techonlogy to a global state.
This specific standard evaluates software life cycles and requisites and evaluating each one of the evaluation steps in the ISO standard 15288.
MOPROSOFT (in spanish, Modelo de Procesos para la Industria del Software de México) is a model for the development and maintenance of software, focused on the processes of a basic structure company, taking in mind three organization levels: High Direction, Gerency and Operation, looking to standarize all of what they do, both in effectivity and integrity.
Initiating, Diagnosing, Establishing, Acting & Learning, this model serves as a roadmap to initiate, plan, and implementation of process improvement actions. As we can see, this has five main “steps”:
Initiating: Initiate the change, lay the groundwork for the changes that WILL happen in the next phases.
Diagnosing: Where are we? Was this the place we wanted to be at this point? Analysing in this phase is essential.
Establishimg: Plan what you’re gonna do, how are you gonna reach your goal? Prioritize tasks, change implementation and establish the teams.
Acting: Do what you planned, nothing more to say for this one.
Learning: Learn from the mistakes you made, improve and adapt new techniques for the future, so that the next IDEAL cycle will be better.
And that’s all models we’re gonna see today, hope you enjoyed and learn something new (for I surely did), and if you care to answer, which one do you think is better? Or should all of them be implemented somehow? I wanna know!
Time to start with an actual mastery topic! So, in the following blogs, there are basically four sub-topics to follow:
Defining Software Quality
Focus on process
Ensuring Software Quality
The role of standards in Software Quality
What is software quality?
By definition, it’s the field of study and practice that describes the desirable aspects of software products. What do we mean by this? We can put it down as the part of software development dedicated to improving and designing all software products, trying to establish the minimum of what’s required in it.
Software Quality Assurance (SQA) ensures how we handle the quality in the processes of a software product, establishing and evaluating all of these in a “process-focused action”, so that in the end, we end up having a product completely functional, with the basic minimum quality being accomplished in all cases, and a happy user in most cases.
The challenge in ensuring quality
In this industry, even if we test an infinite amount of times, against all possible errors that we can think of, we developers can never actually declare that our software is free of defects, unlike how our counterpart, the product manufactures, can. We have some reasons as to why this happens:
Complexity, this one pretty much talks about how many possible paths we have when designing our software, if we first click this, and then that? If I use this button and then go back to click this other one? Imagine this but with a complete application that has many sections. Visibility, this one is pretty clear, manufacturers can see in their products if maybe there’s a splint in one side, or this one part isn’t reinforced enough, us, on the other side, we can’t physically see what’s wrong with what we’re doing, so we have a lot more troubles detecting errors.
Why do we have quality standards?
What happens when we need to work with people that have had a completely different way of learning development and work than we did? How are we supposed to keep a straight line of work to organize our software product and meet all standards that we know along those that the other person knows? That’s right, quality standards. By having a general rule and approach to how something should be built, we can establish a base for everyone to work in.
Hiya there! If you’re reading this, either you somehow got into this page by clicking in some weird place, or for some unknown reason you actually want to read what I’m writing in here. So, whatever the reason, welcome!.
So, might as well write some small introduction in here so you can at least know who I am. My name is Daniel Rubio, 20 years old (21 in a week, yay!), software engineer student in the ‘marvelous’ school that is Tec de Monterrey, here in Guadalajara. I’ll list a couple thing I like since that should help me go a little bit in depth about each of them:
Reading. One of the things I completely love to do. In this aspect I do have to clear a prejudice that a lot of people have, and that is that I only like to read the genders I enjoy, meaning that no, I’m not an expert in all themes or cultural stuff. For me, reading is about inmersing yourself in a whole new world (Aladdin vibes? anyone?), imagining yourself in the current place the characters are right now, feeling like you’re right next to them in whatever they’re doing, grieving for characters that have been with you throughout the entire book, but were killed just a couple pages ago. As you can maybe imagine now, my favorite gender for novels is science fiction, so I’mma throw a few recommendations for you to maybe read one of these days if you feel like it.
– Insignia (by S.J. Kincaid) – 3 books series
– The Secrets of the Immortal Nicholas Flamel (by Michael Scott) – 6 books series
– Tunnels (Roderick Gordon and Brian Williams) – 6 books series. This one is a small hidden gem, slightly slow start for the first book but it has an amazing concept.
– Percy Jackson books (Rick Riordan) – 15 books, divided in 3 series of 5 books each. This might seem like a BIG amount of books, but believe me, they are completely worth it, you can learn a lot of mythology stuff, have a good time and enjoy a lengthy plot.
If you ever read one of these because of this blog, tell me how you liked them! I always enjoy talking about books i’ve read before.
Team sports. This is kind of general, and it doesn’t include all team sports, but I can safely say that I enjoy a lot of them, included amongst those are soccer, basketball, handball and water polo. I also enjoy some other individual stuff, but that’s mostly for the times I don’t have the time to spend some time with friends doing the other ones.
Videogames. This shouldn’t be all the way down here, since it’s pretty much one of my main things, but welp, I don’t really care. For this, I’m not sure how to go on detail, but I can say that my favorite genders are rpg’s, mmo’s, survival and adventure games, and sandbox, that’s not to say that I dont enjoy other gender’s, but I’m always gonna try a game if it’s in that list. I’ll throw a few personal favorites so you can try them out and tell me if you liked them! – Borderlands franchise (1 to 3, also try the telltale one). – Subnautica, survival game in the ocean, reaaaally scary but it’s amazing!
– Modded minecraft (have you ever built a completely automated system that can create whatever item you want? It takes a lot of thinking and designing, even some small knowledge of networks! it’s amazing)
– Albion Online, mmorpg, sandbox style that lets you do anything you want, you’ll need a guild to play the game to the fullest, tho. – Terraria, kind of the step-brother of minecraft, but on a more adventure-like environment. – PERSONAL FAVORITE, Kingdom Hearts (there’s a lot of games in here, all part of the story), this one personally had me ever since I was a child, combining Disney and Final Fantasy characters doesn’t sound like a good idea, but believe me, it was a complete success. I mean, just look at how epic this looks!
– Dark Souls, hard but incredibly enjoyable. – Dont starve together, another survival. – ARK survival evolved, once again, another survival, in a dinosaur island. – Final Fantasy XIII (there’s the normal one, part 2, and part 3), all three games really good, it’s an rpg.
I could keep going, but I’ll just stick with those.
Programming. I guess this one comes a bit with the job of being a software engineering, but I mean, there IS some people that work in this industry and don’t like to do it, so there’s that. I still don’t have a lead on what I want to end up doing, but the only thing I can safely say I dislike, is web development, nope, nope and more nopes, that is not for me, i’d rather make some nice project making some sort of app or tool that helps you with something, like the car agency management that I did in Java, my videogame done in Unity with C#, a mobile app with Java and Android Studio (so far, I think the most complex project I’ve done), and some other smallish project done mostly with Java and a few tools like apex from oracle, and cisco packet tracer.
I’m kind of extending this a bit too long, so just to end it, I’ll add that I’m always happy to meet new people, so don’t hesitate to ever contact me, whatever the reason. Cheers!